iOS. It’s a beast.

When I started out developing an app a few months ago, all I could think was,

“This is not going well.”

iOS, Xcode, Objective-C, whichever you choose to associate with app development, is a very ugly beast. Not ugly in the sense of it being a bad programming language, the learning curve is simply much more difficult than it might be for other languages. Objective-C, unlike web languages (e.g. PHP and ColdFusion), is derived directly from the C language, one of the older and more powerful languages. With a lot of recent languages, there exists a long history of derivation. From C arose C++, from C++ arose Java, from Java arose Javascript. Javascript is used heavily in web development, and it has eliminated some of the leftover programming restrictions of C, such as reference counting. Objective-C however, derives directly from C, and so there are many programming restrictions still remaining from C, which would have been eliminated with other languages.

For instance, in a language like PHP, you can create an object with very little code:


use Die;
$die = new Die();

As long as “Die()” is a class that has the proper class declarations. With Objective-C however, the process is much busier:


#import "Die.h";
Die d = [[Die alloc] init];

Words like “alloc” and “init” are frequently used, and with less abstraction, there is typically more legwork in Objective-C.

I found that during my time in Objective-C, the learning process was quite a bit longer than for other languages. This is mainly due to the fact that Objective-C is full of rules, most of which are very difficult to discern unless quite a bit of memorization has occurred. This meant that for the longest time, I had code that didn’t do anything, either because I forgot an “alloc,” tried to add the wrong kind of type to an “NSMutableArray,” or declared a reference to a variable incorrectly.

Method implementation, in particular, is a little tricky. Objective-C handles method names, return types, and parameters in its own way (which, if I had to guess, would be restrictions left over from C):


-(NSString *)createSubstring:(NSString *)str fromIndex:(NSInteger *)start toIndex:(NSInteger *)end
{
NSString *firstString = [str substringFromIndex:*start];
NSString *secondString = [str substringToIndex:*end];
NSString *newString = [firstString stringByAppendingString:secondString];
return newString;
}

In this example, we have a method that takes a String and two ints, which then creates a substring of that String given the between the range of those two ints. This is tricky to do, and if things aren’t exactly the way Objective-C wants them, it won’t work.

Xcode tries to make up for this in many ways. For most default apps built in Xcode, the legwork of implementing a main method, importing classes, and creating variables is done for you. In particular, creating getters and setters for Objective-C’s version of variables (which are actually references to addresses in memory), is relatively simple. There are many helper classes available in Xcode to help speed up the development process, such as reference counting (for keeping track of the number of times a reference has been used), and Interface Builder.

Interface Builder in particular can come in handy, especially for creating simple things like buttons, text areas, and tables. One thing that bugs me to this day however, is the very little crossover between Interface Builder and code. Typically when one develops a web page, and is using an IDE like Dreamweaver, they can see the code being added when they change something on the design side (Dreamweaver’s equivalent to Interface Builder). With Xcode however, no code is written when one adds things to a section in Interface Builder. If you go through the steps, you can connect things to the code, but generally you either build apps either in Interface Builder or programmatically. I prefer writing the code myself, but at this point I’m still not sure how code I write would correspond to its Interface Builder equivalent, and I imagine the opposite for someone choosing not to develop programmatically is true as well.

The nice thing about Xcode is that it is a powerful language. I implemented tables into my app using a class called “CollectionView” to organize my information, and I was blown away by how Xcode was able to keep track of such large volumes of information so neatly.

All in all, Xcode/Objective-C is a pretty heavy beast to master, but a powerful one once done so.