When I complain about this or that inadequacy in Xcode, there’s always a small but persistent chorus singing the praises of JetBrains’s Cocoa IDE AppCode.1
I’m planning on trying it2, but before I do, I figured I’d lay down some “claim chowder”<tm Gruber> explaining my doubts.
Heinz 57
The trouble with any company attempting to insert itself in another company’s value chain is that they’re playing a constant, unsuccessful game of catchup. GnuStep, anyone? Mono? Every new version is a chance for things to break, every new feature is something else to fall behind on.
My guess is that AppCode won’t support a lot of the things that are built in to Xcode, from minor editing conveniences to essential features. I already know you can’t edit xibs in it, though their promo page claims that refactoring will work in xibs and storyboards, which would be impressive.
I suspect there will be at least one dealbreaker in this category. And by “dealbreaker” I mean, something I have to go back to Xcode for often enough that I might as well just keep using Xcode.
Foreign Exchange
While the screenshot on their promo page doesn’t look that bad, I wonder if I won’t be able to stand their non-native UI. (One thing that Xcode has going for it now is that at least it looks good.) I’m assuming AppCode, like their Java IDE IntelliJ IDEA, is written in Java, not native Objective-C, and that’s why it doesn’t use standard controls; its UI drawing is meant to be cross-platform. So there may also be UI behaviors that feel alien and throw me off.
If the UI doesn’t do the trick, speed issues might. The Java runtime on the Mac was never known for its speed. On the other hand, Xcode itself can be slow and laggy at times, so it will be interesting to see where AppCode lands in comparison. I won’t be trying it with any massive projects, so that’s good (might work better) and bad (won’t be able to judge how it handles them).
THIS One Goes There, THAT One Goes There
I’m also worried about integration. Much of the reason Xcode used to be so bad was that it couldn’t link against gcc directly. Clang is now deeply integrated into Xcode, including its index and its code editor. Does AppCode have to do double the work to get the same result? Or does it try to parse the source code in its own, not-quite-matching way, leading to weird inconsistencies? Will builds be as fast? Will there be cryptic errors when I try something nobody thought of to integrate properly? Can I really trust it to edit project and workspace files (whose formats are undocumented)?
To some degree, this is unfair. Xcode itself it full of weird bugs; expecting AppCode to be perfect is holding it to a different standard.
But I’d rather not have bugs on top of my bugs.
One Is the Loneliest Number
My final concern is that, even if I get everything working properly, even if my productivity skyrockets, I’m still going to be off doing something different than 99.9% of the Cocoa engineers out there. It’s going to take its toll mentally. It’s ironic that I would say this for a platform whose motto once was “Think Different”, but there you go.
But if I start now, at least I’ll have something to talk about for the podcast next week!
1. Still requires Xcode to be installed, because it uses the Xcode command line tool xcodebuild to build.
Weaponized Fluff 
First, sorry for the long answer.
Your blog post interestingly synthesizes the fears of many hardcore Cocoa developers who view anything non-Cocoa as evil.
I used to be this type – Dismissing applications on the way they don’t look like typical Mac apps, don’t feel like typical Mac apps. But, think about it, is there anything like a typical Mac app nowadays? So the first thing if you really want to think different is, get past the initial rejection for non-Mac look.
I got to use AppCode because of one feature. Not the fantastic refactoring, but the Code Inspections. It initially found issues with my code that no other tool found, and this immediately gave AppCode credit in my mind. I decided to give it a go. Here is what I found:
– It’s not slower than Xcode
Really. In many cases it’s even much faster. The text editor is blazingly fast. Completion works wonders. Navigating your code is as fast or faster than in Xcode.Indeed, AppCode capitalizes on 10 years of IDE engineering by JetBrains and this shows. Performance-wise, and it really surprised me, it’s nothing like the typical Java app you’ve been used to.
– It’s way less buggy than Xcode
Number of crash I got since the beginning of this year? One. In the Java VM. When AppCode has an internal exception in the IDE, it’s very well contained and there’s a built-in mechanism that reports its to JetBrains if you want. Issues are typically fixed very quickly. AppCode has a frequent release cycle, and these guys are working their ass off to give you the best product for the money.
– The tools are much better than in Xcode
I honestly don’t know how AppCode parses C, C++ and Objective-C. It may use clang, or a built-in parser, I don’t know. What I know is that it works damn well, up to the point where I 100% trust the IDE to know everything about my code. The refactoring tools are simply incredible. They get everything right most of the time, they give you much freedom in what you want the IDE to do or skip. Inspections are downright fantastic. Like in Xcode, they suggest fixes and can automatically apply them. I found that it has more suggestions and options to offer in many cases. Additionally, there are tools to automate tedious stuff in the code (of course, templates, but also the very useful contextual “Surround With” tool). Everything is keymaped, you can completely navigate without using the mouse. The templating system is way more powerful than Xcode’s. Code generations works a treat, and completely obsoletes third party tools like Accessorizer.
– The IDE is extremely customizable
Besides very detailed code colorization and code formatting options, pretty much everything in the IDE can be customized to match the way you work. There are many tools in the IDE that you’ll want to use, and many others you may not need. You can tone down everything you don’t need. Since AppCode 1.5, the IDE UI itself looks better, even though not like a “real” Mac app yet. But what you lose in Chrome, the IDE makes it up ten times in usefulness. Function over form, that’s the choice they made.
– Compability is very good
For the last 6 months, I’ve only been using Xcode to produce release builds (upload to AppStore, generate AdHoc archives, etc). Granted, I don’t need Interface Builder in the type of product I’m working on. Still, I’ve never had an issue where the file format couldn’t be read, and actually the only project corruption cases I’ve seen occurred when I was changing build settings in Xcode.
– Tons of additional tools
Integration with several source code control tools and bug trackers (with built-in diff viewer as good as Xcode’s), support for plugins with a documented API (in fact the IDE source code itself is open, how cool is that?) and a ton of plugins available, AppCode offers all the cool stuff that’s available with other JetBrains IDEs.
– Quick evolution
Did I mention that AppCode grows fast? Seeing the issues you report and the requests you make not falling into a black hole is a whole experience in itself. Bonus, interacting with the developers is possible.
To summarize: if you’re the type of developer always on the lookout for better tools, you want to give AppCode a serious try. And I mean it – don’t just launch it for a couple hours. Work with it for a week. Make sure you check out the Help > Productivity Guide menu which will teach you a number of things about the tools you may not be aware of. Spend time exploring, the IDE is very deep and rich. It bases upon a solid lineage of developer tools, and even though it’s not a “Mac app” and made by Apple, it’s in my view much better than what Apple offers on this front.
There’s not a single day using AppCode without a smile because of the smartness I see in this IDE.
AppCode is not perfect, but it is really really good. I never though I’d write this about a Java product. JetBrains definitely kicks ass.