Why? That is the first question that comes to mind when someone brings up AppCode. Xcode is so deeply ingrained into the Apple eco-system that it seems strange to even consider a competing IDE. And that is where the good people from JetBrains would beg to differ. Let’s see what AppCode is all about. The version we are reviewing is AppCode 2017.1.
Xcode has always supported external text editors and many people have been using editors like BBEdit for ages. JetBrains makes code editors and does very well with their lineup, specifically in the web editor world. And they correctly identified Xcode as a potential target for a premium replacement product. After all they already had more than enough code in the bank to offer better refactoring and syntax coloring support than Xcode does and the rest of the IDE’s functionality was all out in the open. All that was needed were a bunch of hooks into the different processes and an app could be slapped together in Java without anyone even having to get their hands dirty with macOS. An initial effort of 2 – 3 people for a couple of months and then the resulting app could be maintained on part-time basis by just one developer. In order to keep up with OS upgrades, implement minor new features and such. Et voilà – ecce AppCode.
Visually AppCode looks exactly like JetBrain’s other apps. There is a LOT of code sharing. It immediately feels kind of off on a Mac with its Java parentage as this is not a native app. Window resizing is sort of imitated and typing feels off as well. But developers work with many non-native apps, so this is not that big a detriment as long as some of the reported OS incompatibilities don’t befall us.
A first worry when working with an Xcode substitute is of course that it might corrupt existing projects and after some testing it appears that that is not the case. AppCode seems to work off its own copy internally and leave things well enough alone. So that’s a good thing. In order to save a little developer time JetBrains opted to use the same keyboard shortcuts that they use in other non-macOS products. The run command for example now requires two hands as it moves from cmd-r to cmd-F9. This function key usage is very common in the Windows world but we Mac users can always go ahead and change all commands to things we are used to from Xcode. A handy keymap editor is provided for just that purpose. Shouldn’t take too long, but one wonders.
The JetBrains source tree view – as we have seen it in their other products – is adequate but no improvement over Xcode. We can’t for example right-click a compiled product to locate it in the Finder. A context menu item for this purpose exists, but is broken. We do have a main menu command, however, to show the build folder which is just as well. I do mention this particular item here, because there are a number of these silently failing UI instances.
The most important part of AppCode is of course the code editor and it is not a native macOS text editor, but very well done. It feels a bit like a graphics view with its weird left-right scrolling which is not incremented by letter space but rather by pre-calculated view width. Syntax highlighting is very subtle and easy on the eyes and editors can be tabbed like in JetBrains’ other code editors. And that is pretty much it for the main window. Since Java does not support native macOS toolbars we have none but there is a slim tool strip located under the window bar which comes in handy. A note here for MacBook users. AppCode does not support the MacBook’s Touch Bar and since it uses many function keys as is common in the Windows world, it might be a good idea to adjust the keyboard preferences for this app.
Creating new projects with AppCode is tricky. It creates templates from the same scripts that Xcode uses, but of course it doesn’t have Xcode’s capabilities. So we can get into trouble. Again AppCode fails silently here. We were able to create a cross-platform SpriteKit game with an extremely weird Finder window which was based wrongly on an ‘open panel’ dialog instead of ‘save panel’. A subtlety that doesn’t translate to Russian it seems. Anyway – we end up with a project file with zero bytes. Unusable of course. AppCode doesn’t support SpriteKit and cannot create projects with it, but goes ahead anyway. That points to serious flaws in JetBrains’ QA and leads us to some other things that AppCode can’t do.
For starters there is no support for storyboards. So if you need to hook up some outlets or design an app you need to go to Xcode for that. AppCode is nice enough to open Xcode for you if you double-click an existing storyboard in its editor. Talking of app creation, an entire slew of related issues like code signing, app validation, app submission and so forth is not supported. Of the 7 tabs we get in Xcode’s project editor AppCode supports the General and Build Settings tabs partially. No support for Run Scripts, etc. Notably AppCode also has no support for playgrounds which should not have been that big a deal for their programmer. We also have no Assistant editor and no access to Instruments. Plists as well as several other document formats are only shown in XML and as mentioned before we have no support for SpriteKit. Much more is missing, but we get the picture.
So what’s the deal? It seems that the idea of AppCode being an IDE or even an Xcode substitute – wherever that came from – is not supportable. Not even close. You simply can’t make iOS or macOS apps exclusively with AppCode. JetBrains shot themselves in the foot to a degree when they came up with that vision and implementation plan. It is the nature of the beast that they will never catch up to Xcode. Not with the equivalent in progress of one part-time developer’s efforts. Even if they pushed the app with a 2-3 person team full-time it would be rough going. Xamarin was able to implement storyboards and overall a much closer experience on Windows but they have allocated serious resources and commitment to the effort.
So what’s left is AppCode as an adjunct. And a pricey one at that. There is hardly any reason for anyone to ever use AppCode in place of Xcode and especially beginners should avoid it at all cost until they can handle Xcode in their sleep. Yet there is a place for AppCode that has recently come to mind, because it excels at exactly one particular thing – refactoring. If one has a huge code base to refactor – maybe from Objective-C to Swift – the price and slight learning curve might pay off in the end.
Finally the good folks at JetBrains have made AppCode available for a free 30 day test drive to anybody interested which is a nice gesture, because AppCode comes with a hefty subscription price of $ 199.00 per year which by itself moves it out of range for many. So go and give it a whirl to see what it does for you.