AppCode Review

As is well documented on Twitter, I’ve had my share of frustrating system locking beachball of death experiences with Xcode, so it should come as no surprise that I’ve been keeping a keen eye on JetBrains’ AppCode IDE for iOS and MacOS development.

Being a user of two of JetBrains’ other IDEs, Android Studio and RubyMine, I found the on-boarding experience for AppCode to be pretty familar and was able to get up and running in just a few minutes. Overall, the keyboard shortcuts are very similar to their other IDEs and there’s a lot of value in having a similar setup on multiple IDEs.

AppCode also includes many of the refactoring tools that you’ll be familar with if you use any of JetBrains’ other IDEs and has impressilvely just about been able to keep up with Swift 2.0. However, it’s pretty clear that the AppCode team’s fighting an uphill battle to keep up with the development of Swift and is still refining how the refactoring tools deal with the langauge — the AppCode team will likely have to devote continued effort to keeping up with Swift for the forseable future.

Unfortunately, keeping up with Apple’s development of Swift seems ot have come at a cost, the integrated UI designer. As explained here, the Designer has been made a plugin that can be added after you install the main AppCode package. It’s also worth noting that the plugin doesn’t work on all interface file types and was not useable at all for three out of the four test iOS projects that I used to evaluate the Designer. On the one project that it did work with, it was pretty disappointing and not at all an acceptable replacement for the tooling provided in Xcode for user interface design.

What I and I imagine the vast majority of iOS and MacOS developers want out of AppCode is for it to be what it originally was planned to be — a full Xcode replacement, but there’s a lot of ground to cover before it can qualify there. If JetBrains is serious about AppCode, then they’re going to need to improve the user interface designer to the point where 100% of an iOS or MacOS development project can be done in AppCode. Let me know what you think on Twitter.

  • Stanislav Dombrovsky

    My name is Stanislav Dombrovsky, and I’m product manager in AppCode team in JetBrains. I saw your review in twitter and decided to answer here with some corrections.

    > the AppCode team will likely have to devote continued effort to keeping up with Swift for the forseable future.

    Sorry, but it’s not true. If you’ll take a look on our blog http://blog.jetbrains.com/objc/ – all the recent EAP builds as well as release ones are about Swift support, so for now the most of our efforts are spent on supporting various Swift features.

    >It’s also worth noting that the plugin doesn’t work on all interface file types and was not useable at all for three out of the four test iOS projects that I used to evaluate the Designer.

    This plugin was released at a time when Objective-C language become stable, there was no Swift announcement from Apple and we decided that we can cover one of the important areas for iOS developers – visual design tools, because the code editing experience at those times was rich for Objective-C and we can try to switch to other tasks. In fact, it was one of the most frequently requested and one of the most complicated features for us, so yes, the initial support was not that good. After Swift announcement we needed to decide – we could spent a lot of efforts on UI designer which is not our primary focus and we could spent the same efforts on Swift language support. Finally, based on requests from our users – we postponed UI designer development until we will support the most of Swift language features. For now this plugin is not available for new release and EAP builds – because for the moment it’s not possible to continuously improve it and support all changes in every Xcode version. Also, please, keep in mind, that in fact there is no documentation for any Apple interface format and no public api for interacting with it – so developing UI designer with same (or better) experience than the Apple one is the really huge task.

    >What I and I imagine the vast majority of iOS and MacOS developers want out of AppCode is for it to be what it originally was planned to be — a full Xcode replacement, but there’s a lot of ground to cover before it can qualify there.

    Here I would like to make the correct positioning, which is not really easy in AppCode case. AppCode is not a replacement for Xcode – for now AppCode is a great addition to Xcode. We do not compete with it. Xcode built it’s own developer community and it’s own developer infrastructure and it’s focused on supporting different platform versions, delivering better game development features, different integrations etc. In AppCode our primary focus and our primary goal is code editing experience and smart code editing features. And as we need to choose where we should spend our efforts – we spend it to deliver such things where our expertise is great. Historically, the main area is code editing and related things.

    Also, there are different reasons that prevent the completely separate IDE creation. First, to build the project, you must use xcodebuild. If you want to debug – you must use LLDB that comes with Xcode to deliver the same or better experience to your users. And there are many such cases that cannot be implemented independently. Of course, we will try to make as much as possible available directly from AppCode, so you can just download Xcode and use it as a “library”, but it’s not quick and it’s not an easy task. Finally, we have our developer community – and usually we make our decisions based on user reports. For the moment it’s clear for us that our community waits for the complete Swift support and not, for example, for UI designer integration – and as we always listen to user reports, we are focused on Swift support.

    • Thanks for the response and of course my review is just one review out of what I imagine are many.

      Having said that, for me at least the UI Designer is hugely important and DO want an Xcode replacement. Perhaps I don’t reflect your users very well?

      My point re Swift support is that Swift is likely to continue to evolve (ie we are likely having Swift 3 at some point soon) and that will likely be something that takes the team’s effort to keep up with, therefore taking time away from other tasks — again, my desire for a full UI Designer comes in here.

      It’s interesting how you position the project as somehow augmenting Xcode rather than being a full alternative. Again maybe I don’t represent your average user well.

      Thanks again for the constructive feedback!

  • Many developers keep xcode for designers and appcode for business logic. A simple Model View Presenter pattern is needed to accomplish this.

  • I’m patiently waiting for one of two things: either Apple blows me away by pulling off a JetBrains level high quality IDE, or JetBrains blows me away by rounding out AppCode into a total replacement for Xcode (as a starting point for new app developers). As of today, I feel like neither is likely to happen, so I’ll mentally prepare to accept the bitter pill of life in the developing world.

    Mr Dominick, I was glad to read this review from your perspective and I liked reading the interaction between you Stanislav Dombrovsky from the AppCode team.