May 5, 2013May 5, 2013 by Marty

A Quick Look At AppCode 2.0

JetBrains recently released version 2.0 of their fantastic Objective-C IDE, AppCode. If you aren’t using it, you should go grab a copy – you won’t regret it. Let’s have a quick look at some of the cool new stuff, and how it compares to AppCode 1.x as well as Xcode.

First Launch

Let’s get to know AppCode! It’s a little bit slow to launch, but Xcode itself is no speed demon here, so it’s hard to fault AppCode too much.

Unfortunately, opening a project for the first time still takes a while, thanks to the index building process.

Fortunately, the index building process only seems to happen once per project. Subsequent opens only take a few seconds of ‘Reading Index’. Additionally, there’s no longer a long delay when switching between configurations (iPhone simulator to iOS Device, for example). Thanks, JetBrains! That was a pretty big annoyance.

Look And Feel

AppCode looks a bit different than your typical Mac app. This is understandable, as it’s built on JetBrains’ cross-platform IDE framework – the same Java-based framework that powers products like IntelliJ IDEA and RubyMine.

Version 2.0 adds an attractive new dark theme. It’s easy on the eyes, but it’s even more of a contrast from the rest of your system.

Keyboard Shortcuts

One of the best things about AppCode is it’s keyboard shortcut support. It includes a built-in Visual Studio keybinding scheme. If you are a developer coming from the Windows world, a nearly-complete set of Visual Studio keybindings is almost worth the price of admission by itself.

In addition, AppCode supports chorded hotkeys – hotkeys with multiple steps. Instead of having to use hand-contorting shortcuts like Cmd-Shift-Option-Space-R-7, you can use much nicer multi-step hotkeys like Ctrl-R, Ctrl-V to launch the Extract Variable refactoring.

You also get a few other niceties like proper (from a Visual Studio perspective) Ctrl-Tab document switching.

Unit Testing

When you run unit tests in Xcode (and by run unit tests, I mean run all the unit tests in your project, because that’s about all Xcode lets you do by default), an instance of the iOS Simulator gets launched, and your tests are run inside of it. Want to run something other than all the tests in your project? You can either create separate targets for each set of tests you want to run, or find a third party test runner.

When you run unit tests (or a single test, or a file’s worth of tests – it’s nice to have options!) in AppCode, the simulator isn’t used at all. Whatever AppCode is doing, it’s doing it a whole lot more efficiently than Xcode.

Refactoring

Here’s a quick look at some of the refactorings offered by Xcode.

… and here’s what AppCode has to offer. Quite a difference. I won’t go into the details of all the different refactorings here, but suffice it to say, if you want to do any serious refactoring you should be using AppCode.

What’s Missing?

In general, AppCode 2.0 is a fantastic IDE. However, there are a couple of important functionality gaps to be aware of.

AppCode does not include a UI designer or storyboard editor. If you try to open up a storyboard in AppCode, it will be launched in Xcode instead. Likewise, AppCode does not include a Core Data model editor, and opening an xcdatamodel will also launch it in Xcode.

AppCode also doesn’t have the ability to submit apps to the App Store. Given the secure, proprietary nature of the App Store submission process, I’m not holding my breath for this feature to appear anytime soon.

On the bright side, the integration between the two IDEs is fairly seamless, and changes made in Xcode are picked up right away in AppCode. I look forward to the day that I no longer have to launch Xcode at all (aside from app submission), but until then, the AppCode/Xcode combo works pretty well.

In Summary

AppCode 2.0 is a great update to an already great product. If you aren’t already using it, you should definitely give it a shot. The raw editing, navigation, and refactoring capabilities are almost guaranteed to increase your productivity, especially if you aren’t a heavy user of storyboards or Core Data.

I honestly wish I had started using AppCode a long time ago; I would probably have a few more apps in the App Store by now. It’s a particularly fantastic tool for UI-less libraries like ios-queryable.

As you can tell, I’m a huge fan of AppCode. But what do you think? Are you more productive in Xcode?

March 25, 2013 by Marty

Nested push animation can result in corrupted navigation bar

While updating one of my apps a while back, I suddenly started receiving a bizzare error message:

nested push animation can result in corrupted navigation bar

Like most iOS error messages, this one doesn’t really tell you anything about what the problem is or how to fix it. Nested push animation? Huh? Am I somehow calling push from within a call to push? Does ‘can result in’ really mean ‘results in’? Why should I care?

It turns out that the problem was quite simple, and was indeed my own fault. I had a segue hooked up in my storyboard… but I happened to have added some code that was manually calling pushViewController. Removing the old segue from the storyboard solved the problem.

Whoops!

February 10, 2013 by Marty

Undefined Symbol “_OBJC_CLASS_$_NSManagedObject”

I stumbled across this compilation error while adding Core Data support to my latest app-in-progress.

Undefined symbols for architecture i386:

“_OBJC_CLASS_$_NSManagedObject”, referenced from:

_OBJC_CLASS_$_Show in Show.o

“_OBJC_METACLASS_$_NSManagedObject”, referenced from:

_OBJC_METACLASS_$_Show in Show.o

Fortunately, it’s an easy fix – my project was missing the Core Data framework. After adding it and rebuilding, everything was fine.

The ridiculous part, though, is that despite adding a new Core Data model to my project, creating an entity, and generating an NSManagedObject subclass, Xcode wasn’t smart enough to actually add the Core Data framework for me.

I’m gonna let you in on a little secret, Apple. If someone adds a new Core Data model to their project, and then adds an entity, and then generates NSManagedObject subclasses, it’s probably because, you know, they want to use Core Data. So just add the add the stupid framework automatically and save us all some headaches.

By comparison, Visual Studio does it right, and automatically adds the necessary Entity Framework references for you when you add a new Entity Data Model. There is no reason Xcode shouldn’t do it too (aside from Apple’s general apathy towards their developer tools, that is).

November 30, 2012 by Marty

I hate it when a header file “has been modified since the precompiled header was built”

One of my favourite blog topics is poking fun at Xcode and all of the bizzare problems I encounter with it. The most recent one was a compiler error that looked like this:
fatal error: file '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform /Developer/SDKs/iPhoneSimulator6.0.sdk/usr/include/Availability.h' has been modified since the precompiled header was built
Strange, right? Fortunately, it was an easy fix – all I had to do was a Clean. After that, it compiled correctly.

What boggles my mind is that Xcode knew exactly what was wrong, but wasn’t smart enough to fix the problem itself. Maybe I am being unrealistic here, but it seems to me that a file included in the precompiled header has changed, the correct behavior would be to, you know, recompile the precompiled header?

Then again, it’s Xcode. So I guess not.

October 12, 2012January 22, 2013 by Marty

iOS Quick Tip – “Storyboards are unavailable on iOS 4.3 and prior”

Another day, another bizzare Xcode error.

While working on my newest app, Gym Calculator, I came across a very strange problem. I had initially set my Deployment Target to iOS 4.3. since I didn’t need any fancy new iOS 6 features. However, I couldn’t build, because my project was using Storyboards, which 4.3 doesn’t support. Xcode helpfully gave me the error message

Storyboards are unavailable on iOS 4.3 and prior

Right, no problem then! I’ll just switch to iOS 5 instead. And… same error. Ok, how about a clean and rebuild? Same error. Restart Xcode? Same error.

After some frustration and head-scratching, I stumbled across a long StackOverflow question discussing the problem. The answer that worked for me – hidden in a sea of less useful answers – was C Fraire’s:

The solution that worked for me was just to delete the 
~/Library/Developer/Xcode/DerivedData directory for my project.

So in case anybody else runs into this problem, here’s your solution! (Or at least one potential solution that did the trick for me)

October 5, 2012 by Marty

Xcode 4.5 and ‘file is universal (2 slices) but does not contain a(n) armv7s slice’

After firing up Xcode 4.5 for the first time, adding 4″ iPhone support to 20 Rep Squats, and attempting to run it on my device, Xcode gave me a bizzare error:

file is universal (2 slices) but does not contain a(n) armv7s slice: /Users/Marty/Desktop/Projects/20 Rep Squats/libCorePlot-CocoaTouch.a for architecture armv7s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

So, what gives?

It turns out that Xcode 4.5 adds support for the armv7s architecture, as opposed to the standard armv7 architecture. If you are using a library that has not been compiled for armv7s, and your project is set to armv7s, you will get the above error. In my case, it’s the Core Plot library that is throwing the error.

Fixing the problem is simple. You just need to remove armv7s from the list of valid architectures.

-Select your project from the Project Navigator