A first look at appCode, and the future of Cocoa IDEs?

It’s been almost a full rotation of this great rock about its axis since JetBrains announced the start of its appCode Early Access Program.

appCode is an Integrated Development Environment, just the same as Xcode. Just like Xcode, appCode works with Objective-C projects on Mac and iOS: in fact, under the hood it’s using xcodebuild, llvm and all of the same tools that Xcode uses.

Unlike Xcode, appCode was written by JetBrains, the company who make the IntelliJ IDEA environment for Java. Now I’ve never used IntelliJ, but I have used Eclipse and NetBeans (and even Xcode!) for Java development, and that’s kindof the point. There’s a lot of competition in the Java world for IDEs, so they all have a boatload of features timesaving devices that are missing from Xcode.

Now, before we get too far into details, let’s get this out of the way. appCode—though not itself a cross-platform app—is a Java app based on the same framework as IntelliJ. It therefore doesn’t look like a Cocoa app, it looks like this:

Screen shot 2011 04 06 at 16 53 22

That’s enough to put some of you off, I’m sure. As people who know that user experience is the first most important factor of any app, it’s easy to be distracted by an obviously alien user interface.

Maybe it’s partly because I’ve used so many cross-platform IDEs, but I’ve become inured to the look of the products. I don’t mind (or at least, can deal with) a nonstandard interface if it provides a better experience. It’s quite pleasing that in some cases, appCode does indeed come through.

What does it do that Xcode doesn’t?

One feature that every other IDE I’ve used has which is missing from Xcode is the ability to automatically stub out methods defined in the class interface (or the superclass interface, or a category, or a protocol…) in the implementation. This is a great feature for saving a boatload of typing (or even flipping between multiple views with copy and paste). Design your class’s header, then use the Override Methods, Implement Methods and Generate… items in appCode’s Code menu to automatically fill in the boilerplate bits in the implementation.

Another improvement appCode brings over Xcode is in its refactoring support. Xcode has long had a refactoring capability that only has a little more syntax awareness than sed, and I’ve previously talked about tops as a command-line equivalent. But what about when you want to change a method signature?

Xcode’s refactoring tools can’t support that, although I want to do it fairly frequently: in fact the last time was this morning. I wanted to change the return type and add a new parameter to an existing method, effectively going from -(void)frobulate: to -(BOOL)frobulate:error:. Well, it turns out that in appCode, you can do that:

Screen shot 2011 04 06 at 17 19 32

So I should be using appCode, then?

Well, that’s not my decision to make, but I definitely wouldn’t recommend using it for production yet. It’s got some bugs (yes, I have filed bug reports) particularly with managing Xcode projects and integrating with the underlying SDKs and tools. You probably don’t want to touch production code with appCode yet.

Some particular issues I’ve found are with the default keyboard shortcuts conflicting with Mac OS X’s default keyboard shortcuts, it doesn’t offer a way to run the static analyzer, and I’ve had a problem where it removed a file from the definition of a project’s target. I was able to address both of the last two problems by going back into Xcode, but of course it would be preferable if I didn’t need to. Another big deal for me is that there isn’t (yet?) any integration with the API documentation.

That said, it is just an early preview, so definitely download it and have a motor around. You’ll probably find some things you do when you’re coding that are easier in appCode, and other things that are easier in Xcode.

What’s all this about the future of Cocoa IDEs?

I sincerely hope that JetBrains take this product to release and that people start adopting it. Based on the current preview, I would expect developers coming to iOS from Java development to be the majority of appCode users, because they’ll be the people most comfortable with its way of working.

My biggest hope is that developers in Apple (both inside the Xcode team and beyond) pick up appCode and take a look at it. What we Cocoa developers need is some competition among IDE producers—particularly now that we need to pay for Xcode— to drive development of the tools we use for our day-to-day work. Xcode is to 2010s Objective-C IDEs as Internet Explorer was to 1990s browsers: it basically works, and you don’t get a choice of what you use so be thankful for whatever features you get from On High.

It’d be great for someone to come along with the Firefox of Objective-C IDEs: a product that reminds users and vendors alike that there’s more than one way to do an IDE and that people are open to trying the other ways.

About Graham

I make it faster and easier for you to create high-quality code.
This entry was posted in code-level, tool-support. Bookmark the permalink.

8 Responses to A first look at appCode, and the future of Cocoa IDEs?

  1. Alexey says:

    Ctrl+J should show you a Documentation popup window for the Class or Selector under cursor.

  2. Graham says:

    Cool, thanks Alexey. I must admit I am far from discovering all of appCode’s keyboard shortcuts yet.

  3. obiwahn says:

    Thank you very much for this nice overview.

  4. Seriously says:

    Are you talking about XCode 3, or XCode 4?

    It may not be a generation ahead of anyone else, but XCode 4 is certainly up-to-date and clearly superior to AppCode is numerous ways (e.g. Analyze, Drag-And-Drop UI wiring).

    Before XCode 4 AppCode might have made sense, but now it seems that it’s main reason for existing is to be easier for people who already like IntelliJ.

    Sadly that ‘s probably going to do them a disservice, as XCode will always be more up-to-date as Apple makes platform transitions.

  5. Rolf says:

    Coming from years of eclipse development, having seen IntelliJ, Netbeans and others, XCode 4 may look cool, but when working with it it feels 20 years old. It is definetely NOT intelligent and requires quite a lot of typing compared to doing the same thing in Java.

    I am also missing:
    – Smart code completion (automatically fill in method parameters with most recently used fitting instances
    – automatic setter generation (type set ctrl-space and get a list of setters that can be created)
    – automatic stubbing (create a method in the .h file and automatically add a stub in the .m file
    – refactoring (*anything* beyond “create accessor”)
    – Automatic imports (type “UiLabel” and the ide inserts an import to UIKit.h, is that really that hard?)
    – on-the-fly building (save a file and immediately build the project)
    – partial compilation (run/debug projects even with blocking compilation problems in them)

    What I would really be impressed with, is getting rid of the .h files all together, and change the compiler so that the order in which methods are defined are no longer important. But that would require more than changing the IDE I guess.

    XCode needs a competitor, and maybe Cocoa needs a competitor as well. People are doing great things in XCode, and it’s UI Editor is really great, but compared to the Java IDE world XCode certainly has some room for improvement.

    I’d be interested to compare Java/Eclipse development speed of a newhire compared to a trained XCode developer. Java looses in graphical UI Editting department, but the businesslogic coding/debugging is not up to modern standards.

  6. Graham says:

    Rolf, thanks for that comment, there are some really thoughtful points in it. Basically, I agree. I see two possible routes for “competition”: in the Mac world, there’s MacRuby, which is standard Ruby layered on top of the ObjC runtime so it can access Cocoa APIs and third party ObjC objects without a bridge. Ruby addresses some of your issues (no .h files, no matter what order methods come in) and of course there are third party Ruby IDEs (including RubyMine).

    The second is Mono and Monotouch. I probably need say no more, but decent development environments on the Mac are limited. MonoDevelop is not quite it.

    Of course, if any of these (or appCode) are actually going to compete with Xcode and Cocoa, they actually need to attract developers…so far that hasn’t happened in any meaningful quantity.

  7. Mitch says:

    Once you are exposed to the power and ease of Java development under Eclipse, you really can’t go backwards with out a lot of whining. All I can think is developers of XCode at Apple have never used Eclipse or Visual Studio? It blows my mind how lame the source intelligence is in XCode (and yes that includes XCode 4). I’m not new to XCode/Obj-c development either. I have done it every working day for the past 2 years. Opening up Eclipse and coding in Java is still such a breath of fresh air. Um, why do we need .h files? Nice comment @Rolf.

    All I want in this life is objective-c source formatting and some code generation beyond basic file templates. AppCode seems to do some of this. This is my first day trying it and I’m liking their general approach so far. Good job guys.

  8. Bumpkin says:

    Mitch + 1, after Eclipse it’s always a KILL ME NOW feeling when you have to work with XCode4. Fortunately the AppCode is brilliant!! It works like magic! I love you Jetbrains!!

Comments are closed.