> The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around. Assuming AppCode's refactoring support ends up

> The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around. Assuming AppCode's refactoring support ends up being even as good as Xcode 3's hit-or-miss heuristics, which remains to be seen. "AppCode is from JetBrains and ReSharper/IntelliJ IDEA have great refactoring, so AppCode will too" isn't a valid line of reasoning, because the limiting factor here isn't the author of the tool, it's how much a priori reasoning you can actually do about the target language in question. C# and Java are both, by design, highly amenable to the kinds of static analysis that make refactoring support simple. Objective-C, by design, is not. Xcode 3 and below did a lot of pattern matching to try to make a decent go of autocompletion and refactoring, and it fell down a lot of the time. With Xcode 4, Apple has turned the new compiler, LLVM, into a shared library and hooked into it for refactoring and autocompletion, so they're working with the same parse trees the compiler is, and they have as much information to reason with at compile time as can be hoped for in an extremely late binding, weakly typed language like Objective-C. How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't. In short, I'm extremely skeptical of the claim that AppCode is going to be leaps and bounds better at statically analyzing Objective-C than Xcode 4, given the constraints of the target language.