Frustrations of a Web Developer Learning iOS

I decided to use the somewhat enforced period of free time to learn something that’s been on the back burner for a while, iOS development. Along with learning new things I’ve also been making it back to the gym more frequently and decided to marry the two and build an application to track my workouts.

I could have easily made it a web application, but decided to force myself to build a native iOS app, something that I haven’t done since late 2008. I’m about 30% done, but just needed to vent a little about the frustrations I’ve encountered.

The Really Good

First the good stuff. The SDK and interface tools have vastly improved. Storyboards make so much sense and provide a very easy way to lay out the entire flow of the application, at least for a simple app.

The six years of engineers learning how to use the SDK has made being a novice much easier. There’s lots of good information out there on how to accomplish things, something that I found very frustrating in my first few forays into the world of iOS development. However, with the rapid pace of development in the SDK, one has to be careful to check the timestamps on any advice.

The way that tints work is awesome. I love being able to change the color scheme on the fly without having to redo all my icons.

The Personal Challenges

My first hurdle to overcome was in thinking about the views. In the web world, the construction of the view is completely independent of the actions of the view. Storyboards remove most view creation from code, but they don’t expose everything that can be done to an interface widget and some configuration must still be done in Objective-C code. Trying to remap my mental model of separation and structure wasn’t trivial for me.

Unlike traditional web development, building for the iPhone encompasses very specific form factors. For me, that meant that all the thought cycles I spent trying to figure out how to make sure something looks decent on different browser sizes got replaced with making sure that all layouts were exact.

While I haven’t gotten very deep into it yet, Core Data seems somewhat bizarre. The following snippet makes Java and hibernate look concise.

NSManagedObjectContext *moc = [self managedObjectContext];
NSEntityDescription *entityDescription = [NSEntityDescription
    entityForName:@"Employee" inManagedObjectContext:moc];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:entityDescription];
 
// Set example predicate and sort orderings...
NSNumber *minimumSalary = ...;
NSPredicate *predicate = [NSPredicate predicateWithFormat:
    @"(lastName LIKE[c] 'Worsley') AND (salary > %@)", minimumSalary];
[request setPredicate:predicate];
 
NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc]
    initWithKey:@"firstName" ascending:YES];
[request setSortDescriptors:@[sortDescriptor]];
 
NSError *error;
NSArray *array = [moc executeFetchRequest:request error:&error];
if (array == nil)
{
    // Deal with error...
}

Of course, learning new approaches and ways of thinking is part of the fun of working with a new technology. These aspects are learning, but there are pieces of the iOS world that are just broken.

The Bad

The web development world is full of great stacks. There are the simple language and simple tools stacks like Ruby on Rails. There are the clunky language but amazing tools stacks like Java. I think the joy that could be iOS programming is severely hampered by the one-two punch of X-Code and Objective-C. There are other IDE’s out there, such as AppCode, but they will also lag behind due to Apple’s secrecy surrounding new language features.

X-Code resides in the horrible middle ground between the “fast, but stupid” and “slower, but brain-reading” IDE’s. It offers just enough language features to be a better option than using Sublime Text and it’s ilk, but is slow and doesn’t do anywhere near the things that Intellij does for Java users. It’s also frustratingly buggy in odd ways that question your sanity, such as when it suddenly decides to stop letting the programmer connect fields.

Objective-C would be much better if it adhered to it’s Smalltalk roots more often. Instead, C shows it’s head far to often and it becomes a chore to remember which language paradigms are supposed to be used where. This gets especially frustrating when a receiver expects both C and Objective-C arguments:

[self.button removeTarget:nil action:NULL forControlEvents:UIControlEventTouchUpInside];

That call includes both C and Objective-C values for null. This is broken. These are not two paradigms that really go well together.

Why I’m Excited About Swift

These views on X-Code and Objective-C have gotten me in trouble with my more Apple development centric friends, but the reaction to Swift is indication that iOS developers have been suffering from Stockholm syndrome all this time.

The iPhone is a pretty powerful device and there’s no reason why programming for it should be hard. Apple creating a ECMA Script style language for development will remove one of the biggest barriers for entry for developers of iPhone application and hopefully spare the users from crappy apps built on quasi-cross platform solutions like Phonegap.

The language makes use of the concepts that have won out over the course of the last 25 years to be something that looks a lot more like the tools that web developers have been using for a while. Since the language is simpler, it should also be easier to use tools other than X-Code, should it still remain a cumbersome beast.

For me, Swift also means that it won’t be six years before I try and write an iPhone app again.

Related Posts: