A couple of weeks back, Apple released the fourth beta of Xcode 7.2. However, that was not the only big news in November related to integrated development environments (IDEs) for the iOS platform – with the latest iteration of the Java-based AppCode (version 3.3.1) also coming out a week earlier. While Xcode is, of course, a must-have tool for iOS app development, many developers feel that AppCode has the tools to emerge as a more-than-worthy competitor. We will, in what follows, perform a Xcode vs AppCode comparative study, and try to find out which one is more developer-friendly:

1. Coding for apps – Writing the codes for iPhone apps is fairly easy with either IDE, although the superior code completion features of AppCode (much like other JetBrains tools) would put it at a slight edge. Variables and code blocks that are not in use get automatically grayed out/disabled in the IntelliJ IDEA platform IDE, while creating ternary expressions with ‘if-then’ blocks is a convenient option. What’s more, AppCode prompts developers whenever they write out code blocks that are never going to be hit. Xcode is also fairly neat, and is probably a touch more accurate than AppCode – but the extra features of the latter do make a difference.
2. Interdependence – AppCode requires Xcode, but the opposite is not true. To put it differently, a mobile app developer needs to have Xcode installed on his/her system, before even thinking about using AppCode. On OX 10.11 El Capitan, AppCode 3 requires Xcode 7.1 or higher (Xcode 6.4 is the minimum requirement for OS X 10.10 systems). AppCode is an IDE that is meant to SUPPLANT Xcode, and not REPLACE it altogether. You can work with AppCode, but while developing iOS apps, you cannot ever fully ditch Xcode.
3. Refactoring tasks – This round is a huge #win for Appcode. On Xcode, the ‘Rename…’ command has to be used for renaming the names of classes globally – and the process is uncertain, slow, and can cause other unnecessary changes as well. The built-in tool for method signature refactoring is nothing to write home about either (many developers have reported about its unreliability). AppCode does away with all such chances of refactoring mistakes and associated delays. All that the Obj-C programmers for iOS have to do is hit ‘Shift-F6’ → (type the new name) → Enter, and continue typing without any interruptions. For playing around with method signatures, AppCode has three different values (0, Null and No) that can be passed through parameters. From enums and variables, to classes, constants, files and practically every other section of app codes – AppCode provides much easier and faster renaming options than what Xcode does.
4. Navigating through code files – Nothing to pick between the two here. The two IDEs offer entirely different file navigation systems for Apple developers – and both are equally developer-friendly. On AppCode, there are four different file finders, while Xcode has its own method for fuzzy finding files and classes. The number of file finders in AppCode might be more, but locating and accessing specific files in Xcode is not at all problematic either.
5. Personalization options – Hardly any comparison here. Most iPhone app development experts who have ‘switched’ to AppCode feel that enhanced, all-round customization is the greatest single advantage that AppCode holds over Xcode. The default theme of the former (taken from Xcode) can be adjusted to reduce the look and feel of a Java environment. Developers can tweak around the font colours and styles, coding methods, and even the menu structure (both the appearance as well as the order in which items appear). Customization in Xcode is, at best, mediocre – and it’s not surprising that many developers are prepared to spend those extra few minutes to set up AppCode just like they want.
6. Storyboarding – And we arrive at the biggest advantage that Xcode still holds over the IntelliJ IDEA AppCode. Most high-end iPhone apps involve extensive use of storyboards, and the support for them on AppCode is fairly sub-standard. There are stability issues, while tasks that are simple in Xcode (like modification of properties, or addition/deletion of autolayout constraints) are impossible in AppCode. It does not even support the Xcode 6 size classes. If you are working with storyboards, AppCode ain’t your friend, Xcode is.
7. Class creation – We have already touched upon the greater ease of writing codes using AppCode. In particular, it is a whole lot more developer-friendly – when it comes to creating and declaring new classes. With Xcode, iOS developers have to go the whole hog of making the class, finding the folder in which it should be stored, finding and declaring a suitable method name and removing the auto-implementation. A small mistake here can lead the entire program to crash. In Appcode, new classes can be created even while testing is going on, and there is a single command to indicate where the new file is to be stored. Extra parameters can be added or removed with ease, and the method signature can also be changed. It’s easy to see why so many dedicated programmers prefer coding in AppCode rather than Xcode.
8. Code testing – For debugging codes for iOS applications in Xcode, the miniscule icons at the breakpoint spaces have to be clicked, and the code has to be executed line-by-line. It is neither very convenient and certainly not a quick process. There are shortcuts available, but trying to work with multiple other unit tests in the same module can be very confusing. Code block testing is a whole lot easier and more accurate in AppCode, since the latter can correctly specify the line on which a block is being executed every single time (something where Xcode can falter frequently). The bigger advantage of AppCode over Xcode in the context of mobile app testing, of course, is the ability of the Java-based IDE to reveal property values (including that of hidden properties).
9. UI features and settings – This round would go to Xcode. AppCode has a long way to go to match the efficient, easy-to-work UI that has always been a feature of Apple’s very own IDE. Including app entitlements (something that is not possible in AppCode) is a matter of minutes in Xcode. The build settings featureset of Xcode is better as well. On Appcode, when you edit the build settings, only a long line of objects get edited. With Xcode, developers can do so much more.
10. Code moving and syntax highlighting – Moving code snippets from one location to another for overall improvement is possible in both Xcode and Appcode. However, those who make iOS apps have to finish writing the entire program, before making such changes. The same task becomes much simpler in AppCode – thanks to the contextual menus (for suggesting improvements) next to every code selection. The run-time suggestions (for instance, for moving a method to private) can come in really handy at times – and it certainly does away with the need for app coders to remember all the changes that have to be done. The syntax highlighting support feature (right in the Podfile) of AppCode also makes it a more user-friendly IDE for coding Cocoa projects. The graphic user interface (GUI) is well-designed, and there is a dedicated ‘Update’ button to upgrade the ‘Cocoapods’. The Xcode interface is nice and simple, but when several changes have to be made and the code itself is lengthy, it can be found wanting.
11. Likely glitches while coding – Chances of unexpected technical problems cropping up during iPhone app development projects in Xcode are minimal. The same, unfortunately, can’t be said for AppCode. There have been reports from developers about problems in code scrolling, due to recurring flashes in the application screen of AppCode. The entire system (OS X) can also get locked up, while working with the JetBrains IDE – and the only way to get out of the mess is killing the process. Xcode-users hardly ever face such problems.
12. The cost factor – There is a reason why indie app developers (most of whom have to work on a budget) stay with Xcode. It is a free IDE, unlike Appcode. JetBrains offers a free 30-day trial period, and after that – the cost for using AppCode is $89 for the first year and $71 for the following year ($199 and $159 for mobile app companies). The best idea for new iOS developers would be to learn Xcode thoroughly, check out AppCode in for free in the trial period, and then take a call on whether it would be worth going for the paid subscription.

Appcode 3.3 has been launched with full support for Swift 2 and Xcode 7 (on OS X 10.11, the support for Xcode 6.x has been discontinued). Code inspection can be done in a special LIVE mode – which adds to the advantage of AppCode. There are several other native scripts in AppCode that make it an absolute breeze to work with for iOS app developers.

So, which of the IDEs is better? As we have pointed out, Xcode has its fair share of shortcomings, and JetBrains’ alternative does a good job of doing the same tasks in a much easier manner. However, it too has its rough edges (the hardly-there support for storyboarding, for instance), all coding related to core data has to be done in Xcode – and of course, there are expenses involved in using AppCode on a continuous basis. Both IDEs have certain definite advantages – it’s only that the ones of AppCode (refactoring, code writing, etc.) matter more to actual developers.

Xcode or AppCode – which one do you prefer using?