I have tried switching from Xcode to AppCode for iOS programming

Here are some of my findings when trying to switch from Xcode to AppCode for writing Swift code.

Tools come in all shapes and sizes

The Xcode situation

In my recent “6 things I learned by publishing an app on the App Store” article, I briefly talked about some gripes I have with Xcode. Xcode is a great tool and it shines when it comes to features like Instruments that make profiling your app a breeze. Unfortunately, for typing code, many things are missing compared to other IDEs such as IntelliJ or Visual Studio. If you want some basic text editing functionalities like duplicating or simply deleting a line of code with a keyboard shortcut, you have to rely on 3rd party plugins or hack your way into a plist file. The autocomplete feature of Xcode is also not a glorious example of stability. As for refactoring helpers, they are practically non-existent in Xcode land.

JetBrains to the rescue

You may have heard about JetBrains. They are a great company specializing in making IDEs for a variety of languages. PhpStorm for PHP, DataGrip for SQL, IntelliJ IDEA for Java, PyCharm for Python, WebStorm for JavaScript, … you name it. They are also the guys behind ReSharper, the Visual Studio plugin that I’m using every day at work and that enhances the experience of coding in Visual Studio to no end. I would also like to note that they are exceptionally nice people. Back in the day, when my open-source Ruby project was gaining some traction, they offered me a license for RubyMine worth $159.

JetBrains also produces AppCode. In their own words, AppCode is a Smart IDE for iOS/macOS development. Obviously, this piqued my interest. With a $199 per year price tag, I was happy to see that there’s a 30-day trial version available.

Initial feeling

Maybe Xcode is frustrating and often feels like an unfinished product but one thing you have to hand to Apple is that Xcode looks good. In pure Apple tradition, its UI is delightfully designed and the UX is great. You are not bombarded with a truckload of menus when looking at Xcode. For Appcode, it is a different story.

The UI of AppCode looks like it has been put together by some Soviet-era car designer. Although not the ugliest piece of software on my Mac, it certainly competes for the title with everything it’s got. This is something to consider if you plan to spend a non-trivial amount of hours per day using it.

A UI that can’t be compared to Xcode sleek design

By tweaking it a little bit, you can make the UI bearable, though.

No interface designer

One thing you need to be aware of right from the start is that AppCode doesn’t feature a replacement for Xcode Interface Builder. That is, you can’t edit your storyboards using AppCode. When you try to open a .storyboard file, it will launch Xcode. Minor annoyance: it will not open the storyboard in Xcode automatically, only your project. You then have to manually select your storyboard.

Know that if you go for AppCode as your main code editor, you will always have Xcode opened as well.

Setting up: Ok

Before even starting to write one line of code with AppCode, I spent about two hours setting it up. Most of what I’ve done is not needed for being productive with AppCode (or any other JetBrains IDE) but I like to have all my ducks in a row before starting to concentrate on writing code. Configuring the levels of inspection, the code style, pointing to the correct Ruby interpreter that should be used with CocoaPods, keyboard shortcuts, and so on. This way, I don’t have to fiddle with the settings in the middle of writing a function.

Although the process was painless, I still found some menus and sub-menus and sub-sub-menus convoluted. As this is not something that’s needed to be done on a frequent basis and since you can export your settings once you are happy with them, I’ll file this under not important.

Let’s write some code

Note that everything I tried applies to Swift. I haven’t attempted to write Objective-C with AppCode as I live in the present and I like it just like that.

At first, the autocomplete feature seems great. Especially when coming from Xcode. But, more on that later. A feature I particularly enjoy is that AppCode is smart enough to provide you with a default implementation of required methods upon applying a protocol on a class. That’s really cool and saves you from having to browse the documentation. A real time saver that I’ve grown accustomed to by using Visual Studio and was really surprised not to find in Xcode.

Just to get my feet wet, I tried to do the following:

1. Have a UITextView on the initial ViewController.
2. Add my PieceOfKit framework using CocoaPods.
3. Load a bunch of words from an embedded text file.
4. Display these words within the UITextView and use the .length String extension from PieceOfKit to display the number of characters.

Nothing fancy, just smoke testing AppCode before going any further and investing too much time (of which I have very little) in it.

Creating the UI: Not applicable

As said before, AppCode doesn’t deal with UI stuff. So, I set my storyboard in Xcode and dragged the IBOutlet to my code. No AppCode involved for this part.

Source control management: Nice

Much like with other JetBrains IDEs, Git management from AppCode is great. Xcode provides too little in terms of features to be used exclusively for Git operations. On the other hand, I feel confident I could use only AppCode without having to use the terminal nor something like SourceTree for my standard source control workflow.

Adding CocoaPods: Fail

Even though AppCode asks if you want to edit your Podfile, it will open an empty file if you didn’t run pod init already. That’s what I did and then issued pod install as well as restart AppCode and Xcode (switching to the xcworkspace) for good measure.

Sadly, AppCode reports that it “cannot load underlying module” when trying to import the framework. Oddly enough, the methods within the framework are available on autocomplete. This red wiggly line as well as the error shown in the margin bugs me. I checked in Xcode and everything seems to be fine, no error reported.

Overriding a method: Fail

In Xcode, when you want to override a function, you start typing its name and autocompletion (when it works) will propose it to you. That’s not how it works in AppCode. Merely typing the method name, even if you prefix it with override func won’t trigger autocompletion:

Instead, you have to use a keyboard shortcut to “Select a member to override” and then pick it from a list:

Maybe I’m doing something wrong here but intuitively, this is not efficient.

Type inference on Optional unwrapping: Fail

This may be an edge case, I don’t know, but it’s hardly a difficult piece of code. When using a try? with a method returning a String in an if .. let statement, AppCode can’t infer the type of the constant. Check the “Unknown” type in the screenshot below:

It will also underline your absolutely valid constant with the red wiggly line of doom. And autocompletion will not work either. If you don’t remember the exact syntax of the method you are trying to call on the constant, you are in for a trip to the documentation… …or opening the file in Xcode which has no problems whatsoever dealing with this.

Not really useful, is it?

Refactoring by extracting to a method: Fail

One of the huge advantage provided by the JetBrains family of IDEs is the capability to effortlessly refactor complex code. Things like “extract to a method” are features I use multiple times a day with Visual Studio and ReSharper.

So, what happened here? I can’t explain the following behavior:

When selecting the self-containing lines of code within my viewDidLoad, there’s no possibility to extract these lines into a method. To AppCode credits, it is also not doable with Xcode.

Maybe one day but not today

As I didn’t have more time to spend delving deeper into AppCode, I decided to stop my trial here and remove AppCode from my Mac. Swift is not an old language and it evolutes pretty quickly. I understand that JetBrains will improve AppCode as they are catching up with Swift. They will eventually reach the same quality they have with their other lines of product.

For the time being, I don’t see AppCode as a time saver nor worth the investment. Still, I will keep an eye open for the next releases and report back on my future findings. Or, who knows, maybe Apple will get its act together and make Xcode the IDE it deserves to be!

If you are interested in learning how to code and get certified by one of the world’s top universities, visit exts.epfl.ch.