Trifork Blog

AppCode: IntelliJ for Objective C!

July 6th, 2011 by

AppCode logoWhen I started writing my first iPhone app, I was quite disappointed with XCode. This is because I have been using IntelliJ for the past five years, which I love working with ever since I first started using it. XCode is the IDE you have to use in order to develop iOS and Mac apps. Until recently there weren’t any real alternatives.

Compared to IntelliJ, XCode looks very basic to me because it has no handy shortcuts, good refactoring tools or other handy features that I’m used to in IntelliJ. XCode doesn’t look like a software tool that’s developed by Apple at all. It is clear Steve Jobs was not involved creating this tool.

After I came to the conclusion I was probably just spoiled by IntelliJ, I accepted the fact that XCode wasn’t as good. Furthermore, I was learning a new language and had to accept that I’m in a different world now. Recently XCode 4 was released, which admittedly has improved a lot compared to XCode 3. But, as I found out, XCode 4 still needs to come a long way to even come close to the usability of IntelliJ.

AppCode to the rescue?

This is where AppCode comes in, it is developed by the same people as IntelliJ: JetBrains. With AppCode they basically built an IDE very similar to IntelliJ, but instead of Java it supports Objective C. Currently it is still in some kind of pre-beta stage they call EAP (Early Access Program), but already it looks very very promising.

At first I was very sceptical about AppCode, because I didn’t believe in an IDE not part of the standard iOS SDK package. Because the power of how Apple distributes new releases of the SDK is, that the tools are also updated with every release. So you will never run into compatibility issues. A third party IDE would probably have a hard time catching up to the latest iOS version every release. It will quickly fall behind.

I suspect the guys from JetBrains have also foreseen this problem and came up with a very clever solution. They basically built the entire IDE “on top” of XCode. This means:

  • AppCode doesn’t have its own project file format, but instead it opens existing XCode projects
  • It behind the scenes uses the XCode compiler to build your app
  • It leaves editing NIB files (Interface Builder) entirely up to XCode

This is very cool because this way there is no risk or effort involved using AppCode instead of XCode. Just install AppCode, open your existing XCode project and you can start using it! If you find something that really only XCode can do (for example distribute to the App Store) you can still switch back to XCode to do that task.

Things XCode just doesn`t do

I kept a list of the most important things I discovered in AppCode so far that XCode just doesn’t support. It’s like discovering IntelliJ’s features all over again, which is nice.

  • Realtime compiler errors without having to build first
  • Quickfixes: it even warns you when you for example have allocated an object but you didn’t release it anywhere
  • Ability to quickly override or implement methods from a superclass or protocol
  • Grays out unused code (imports, methods, classes etc)
  • Generates init methods, properties, etc.
  • Optimize imports
  • Refactoring of a method signature
  • Other kinds of refactorings like extracting a method, renaming variables, extracting protocols, putting code inline …
  • Shortkey to quickly navigate to a class, you even can use abbreviations like “MC” when you’re looking for a class named MyClass for example
  • Code formatting
  • Live templates
  • … and a lot more

Things AppCode does way better

Also a lot of features are just done better in AppCode compared to XCode. Here are the ones I most appreciate.

  • Much much better auto completion, it also does smart complete
  • Saves files automatically
  • Use of bright, more distinctive colors in code
  • Debugs code just like IntelliJ
  • Subversion/Git/Mercurial support just like IntelliJ
  • Much better, more logical shortkeys. And there’s also many more of them!
  • Easier to create new classes, protocols, etc
  • Switching between .m and .h files keeps the cursor at the same method
  • “Find usages” actually finds usages instead of simply doing a text search like XCode does
  • Doesn’t show useless compiler warnings like the one for unused local variables
  • … and again much more of course

Few things you will still need XCode for

Even though you probably want to marry AppCode after using it for a while, you can’t do a complete switch at this moment. I found out that there are still some things you will still need to go back to XCode for every once in a while.

  • Interface Builder (yes, because XCode 4 has Interface Builder built right in)
  • Deploying to iPhone (but I suspect it’s just a bug that this is not possible right now with AppCode)
  • Building AD HOC or Appstore distributions
  • Browse developer documentation
  • plist file support

In conclusion

Overall I think AppCode is a 99% replacement of XCode, offers a much better user experience and makes you more productive. You don’t need to convert anything to AppCode, it just picks up where you left off with XCode. I personally use it all the time now when I’m developing iPhone apps, but I leave XCode open as well to do the very few things AppCode can’t (yet) do. I certainly recommend AppCode to other people who are currently developing with XCode. Check out the EAP at

7 Responses

  1. July 6, 2011 at 15:13 by hristo

    Nice post! One thing I’ve been using for the docs is the Ingredients app ( So one less thing to open XCode 4.

    Also I’m not sure what XCode 4 does but at the end of the day it just eats ram for no apparent reason.

    • July 6, 2011 at 16:07 by Tom van Zummeren

      Thanks for the tip about the Ingredients app hristo! I will make sure to check it out! XCode 4 doesn’t seem to do anything strange at the end of the day on my machine. But I can imagine it is not that well implemented under the hood.

  2. July 7, 2011 at 03:32 by Nik

    XCode 4 seems to move in the right direction – version 4 can be called an IDE, even if just a basic one, whereas XCode 3 really was just a fancy text editor.

    It’s still very far removed from a good IDE like IntelliJ – I’ve used Eclipse int he past but same thing.

    I was just wasting hours of my life yesterday due to the missing “find usages” feature in XCode. I had some old, CRAP, code I need to fix up and needed to find out where things get used in order to eliminate or refactor them. I ended up using XCode’s “rename” refactoring to give variables and methods unique names, then do a text search on the unique name. It was slow, and tedious, and I found XCode doesn’t even reliably rename methods as it failed to rename some of the callers in XIB files and selectors and I got crashes. A good example of how a modern IDE instantly saves hours of development time with very basic features.

    AppCode still has bugs but I am looking forward to the day it’s as good as IntelliJ and I am going to start using it now. I’ll buy it!

  3. July 7, 2011 at 09:43 by Tom van Zummeren

    Well said Nik! Funny that you call XCode 3 a fancy text editor, but its true actually. I also remember a situation where I renamed a class and it would just “forget” to remove a few #import statements, while it did remove the rest. Refactorings in XCode just aren’t reliable.

  4. July 7, 2011 at 19:20 by Martin Pilkington

    Just to point out a few things. Firstly, Xcode does have live compiler errors without having to build and also has support for quick fixes. These were big new features in 4.0. Xcode does also offer extract method and rename variable refactorings.

    In terms of the doing better, the autocomplete is a mixed bag, as from my experience the Xcode 4 autocomplete is smarter than AppCode’s (as it is using the compiler to back it), but AppCode is more reliable as the Xcode 4 autocomplete can flake out at times. Xcode can also be set up to automatically save files whenever you build, a feature that’s been around since Xcode 1 IIRC. And it’s worth noting that many classes of compiler warning, such as unused variable warnings, can be turned off in the build settings.

    Some of the other things are also subjective and often about defaults, such as the hotkeys (which can be changed) and the colouring. Also worth noting on the colouring front that Xcode supports something no other text editor does, which is the ability to use different fonts for different parts of syntax (eg I have my comments in helvetica).

    All that said, I am incredibly happy about AppCode, as it does offer a lot of features I’ve been wanting in Xcode for a while, such as code formatting, find uses, quick fixes for unimplemented methods and refactoring that actually can be relied upon. Competition can only be a good thing and I can see many people enjoying it.

    It’s probably not enough for me to switch from Xcode though. The fact that I still need Xcode for editing Core Data models, editing build settings and phases, editing NIBs etc makes using AppCode quite a bit of a hassle. I’m also not a huge fan of the UI, which feels like a Windows app in most places, and just plain complicated in others. But for a 1.0 it’s impressive and hopefully with time they can fix the issues I have with it (they have been incredibly friendly and responsive to any suggestions). One things for sure though, it’s an exciting time to be an Obj-C developer! 😀

  5. […] seen what they can do for Java development with IntelliJ IDEA. You can also take a look at this  post about AppCode which also supports the idea that Xcode shouldn’t be the only choice for developing for Mac […]

  6. January 19, 2012 at 04:31 by Matt Bettcher

    I gotta say after just messing with AppCode for a few mins it looks like a great replacement for Xcode. I really hope that Apple can get their IDE working as well as VS. Going from VS to Xcode = tears… AppCode seems to dry most of them though!