recursion

I have recently had the opportunity to do a small iOS project professionally. Previously, I had very little experience with Objective-C, Cocoa, and iOS (I took a class on iOS when the SDK came out, and have read some books on Cocoa) so this was a big learning opportunity for me. The app is targeting iOS 4.3, so I didn’t get to use the fancy new ARC feature. Maybe this makes me the last of the old-school iOS developers?

At the beginning I felt like this:

Often, I still feel that way, but I have become a lot more comfortable.

The best thing about iOS development is (after jumping through Apple’s many hoops) you get to see you app run on the device. That is super-cool.

Objective-C the language is…strange. As a mixture of Smalltalk and C, with some other features thrown in (dot-notation properties), how could it not be? But you get used to it.

Cocoa and UIKit are HUGE. There’s a gigantic learning curve there.

The learning curve made me miss the REPL terribly. Having a REPL is one of the most attractive things about RubyMotion.

Xcode is a decent editor. I like the inline help and warnings it gives you about missing properties It really requires a big monitor. I ended up using two windows. One for coding, and one for running the app with a full-screen log.

However, Xcode crashes. A lot. And it warns you. “I’m going to crash. Do you want me to crash, or not?” Um, thanks.

Xcode 4 has git integration. But it’s not very good. And if you use git outside Xcode (for example, to change a branch) it doesn’t like all the files changing underneath it, and will crash.

Xcode uses a gigantic XML file for managing the project settings. This falls down if you falls down with changing the developer signing the app, for example. If you’ve got multiple signing profiles, it’s quite hard to tell them apart. This is not a problem for corporate developers, but consultants are switching between multiple clients all the time.

It’s technically possible to write iOS apps without Xcode but not very many people do so you’d really be fighting against the curve.

The last time I did GUI development was with Java Swing. With Swing, someone would use a GUI builder, and then you’d fight against its auto-generated code for the rest of the project. From that perspective, Interface Builder is awesome. It actually can make layouts and keep them separated from your code.

However complicated layouts are still hard. I quickly understood why some developers eschew Interface Builder. Take this example:

You’ve got a greeting, a person’s name (which is variable) in bold, then a date in a smaller, italicized font.

In the web, this would be pretty easy. You’d end up with something like this (plus some CSS):

<div class="greeting">
Hello <strong>Name</strong> <span>Tuesday, June 1</span>
</div>

However, UIKit doesn’t have a way to have variable font styles in a UILabel. So this needs to be three UILabels (one for the greeting, one for the name, and one for the date). And since the name is variable, you can’t fix the width of it in Interface Builder. So you have to calculate where it will be, what its max X is, and add the width of a space to figure out where to put the date.

You end up with a lot of code like this:

CGFloat spaceWidth = [@" " sizeWithFont:self.nameLabel.font].width;
    
self.nameLabel.frame = CGRectOffset(self.greetingLabel.frame, 
                                    greetingLabel.size.width + spaceWidth,
                                    0.0);
CGRect nameFrame = self.nameLabel.frame;
nameFrame.size = [self.nameLabel.text sizeWithFont:self.nameLabel.font];
self.nameLabel.frame = nameFrame;
    
self.dateLabel.frame = CGRectOffset(self.nameLabel.frame,
                                    nameSize.width + spaceWidth,
                                    0.0);
CGRect dateLabelFrame = self.dateLabel.frame;
dateLabelFrame.size = [self.dateLabel.text sizeWithFont:self.dateLabel.font];
self.dateLabel.frame = createdAtFrame;

This uses CGRectOffset to move the frames around. You can also use CGRectGetMaxX to build the CGRect for the frame, or you can assign to frame.center to move it around.

Dynamic vertical space is also hard, because you have to calculate how tall your content is, then adjust everything below it based on that.

It made me miss web development and the box model and CSS!

In iOS, laying out the UI is very much the programmer’s job. You can’t hand off a functional iOS app to a “front-end” developer for styling. That person has to know Cocoa and Objective-C. So it might as well be you. There’s a lot of squinting at UI elements to figure out if it matches the design. No? Edit code, recompile, launch the simulator, then navigate back to that screen. There’s no “reload the page”, unfortunately.

A Web Inspector-type tool for UIKit would be an amazing help here.

Additionally, making custom UI elements is pretty finicky. Apple’s provided elements work great and you can change their appearance somewhat, but when you deviate off the golden path, you’re own your own. Usually, I used a custom background image behind the label, then tweaked the background image and the field itself until it looked right with the background image.

That’s first impression of iOS development. These are the insights of a newb, so I will probably learn better ways around some of these problems. Or you can tell me: look@recursion.org.