Different IDE for Cocoa development
AppCode is JetBrains’ alternative to Xcode. It was introduced in 2011 and became quite popular among Apple developers. There is no public data about Xcode vs AppCode downloads, but I assume the number of people who tried and use non-Apple software for iOS and Mac development is comparatively small.
I personally launched the trial of AppCode 1.5 only once, then later bought a discounted license for 2.0 because of too many recommendations in Twitter. Unfortunately, it always “looked like Java” and felt like something from 2000s surrounded by the modern interface of OS X. I tried to get used to it some times with no luck.
However, AppCode gets better with each release and acquires more and more fans in our community, so in 2014 I decided to give it a serious try before my yearly subscription license expires. Surprisingly, this resulted in full-time switching to the new IDE for coding in Objective-C.
I am still newbie but would like to share some things which were not obvious for me from the very beginning, demystify the hype, and maybe convince you to give another chance to this awesome development tool.
1. The same project can be open in AppCode and Xcode simultaneously
There is no need to abandon Apple’s IDE when you “switch” to AppCode. I have Xcode running on the “home” OS X space and use it for debugging, creating new classes and editing project settings. In the second full-screen space I have the same Xcode project open in AppCode and use it purely for writing Objective-C code, for making changes to existing classes and sometimes for committing to the git repository.
2. You can totally customize AppCode to “dim” the look and feel of Java
For me, the default theme copied from Xcode looked horrible and heavy. However, everything can be customized to remove the distractions. For instance, I changed the code editor font, added line numbers, removed the code folding icons, hid the 100 characters gutter from the code editor, and disabled yellow highlighting on the “current” line.
Also, after the very first launch, you would better to close all utility windows, so that code editor feels like TextMate. After using AppCode for a while, you will meet each utility window in the right and neccessary context to understand and appreciate it. With time, all panels become “invisible” and non-distracting.
3. Renaming vars and methods in Objective-C code feels like magic
Xcode is great for refactoring, especially when you use
Control-Command-E to rename the local variable or the local file method. But every time you call the command
Rename… to change the class name globally, you become frustrated. You always fear the worst and relax only after everything ends up as expected. Then you double-check each change in the project and bless Xcode that it did not screw up anything. Right?
Renaming experience with AppCode is totally different. I mean it. You press
Shift-F6, type the new name, press
Enter, and immediately continue to type new code. Most of the times there is no single thought about incorrect changes that might happen. Mainly, because you don’t see the modal sheet re-asking if you really want to start refactoring.
4. Contextual code “moving” commands make refactoring a pleasure
There is always code that can be improved by moving things around, and there is always a reason to do this later. But in AppCode, moving code within and even between classes is so easy that you never skip this mini-refactoring “till later”.
For any code selection, there is always a contextual menu with commands which will try to improve your code. For example, if you keep the cursor on the method declaration in the public interface for a second, the small lightbulb may advise you to move the method into the private category.
You can select some methods and move them into the new class which makes the process of code decoupling much faster and easier. You can extract selected lines into the new method, function or block etc. These operations are performed in a simple and intuitive interface.
5. Code Inspection tool will make you sure that your code is clean
JetBrains’ IDE analyzes your code in LIVE mode to highlight unneccessary
#import lines, unused public methods, to find unreachable code lines and other things that can be fixed to polish your Objective-C, C and C++ code.
Because of using the same llvm clang compiler, such code analysis is available in Xcode, but all warnings appear only after compilation. This feels okay only until you try AppCode.
I am not going to post the famous tweet with a screenshot where AppCode hints about the Apple’s
goto fail; okay?
6. You can use advanced live templates to speed up coding
@protocol for the class delegate,
dispatch_async and other snippets are useful in Xcode, but their implementation in AppCode is smarter and somehow more intuitive.
There are many examples of native and user-made scripts that you will like because of smart variables. And the more you use them, the more you want to expriment and play with your own collection i.e.
7. AppCode has a number of ways to autocomplete the whole methods
In Xcode, you have to type first letters of the new overriden method i.e.
-tabl, then select from the huge list of names by scrolling to finally insert the right signature. In AppCode, you hit the command
Implement…, select two or three methods at once and press
Continue. Boom, and you have got 3-4 new methods with default implementation.
By the way, you can type a method which does not yet exist, then hit the command
Create Method and confirm parameters to insert the new signature into the class implementation. How many times have you missed this in Xcode?
Overall, it seems like JetBrains tend to implement all the features you miss in Xcode even if they are not neccessary. Sometimes, it feels like a bad design and definitely not the Apple way to build things, but if you consider AppCode as Xcode complement, this is cool.
8. Integration with CocoaPods and syntax highlighting for Podfile
No comments. AppCode supports the syntax highlighting in Podfile. There is a hint when the local gem
cocoapods must be updated to the latest new version together with a button
Update. You have the primitive interface to avoid Terminal, and the simple GUI makes you feel in full control of submodules.
9. Advanced version control with terrific layout for merging
I like the simplicity of committing in Xcode, but it is not very convenient for overview after massive changes. AppCode’s interface looks not that good, but its advanced features like merging in three panes are very helping.
Conclusion that I needed three years to come up with
AppCode is not a replacemenet for Xcode. Consider it as one of many tools that you can use to improve your Cocoa development process.
Go to the official website, download the free trial, start using it, and do your best to keep up with minor annoyances for one week. You won’t regret.
P.S. AppCode has got problems. Yes, it is not perfect. But the Team rocks. I mean it. They fix bugs and implement many features fairly quick for the most part. Their official Twitter account gives prompt and humane responses to any requests. Give it a try :)