Events have conspired against me and I find myself writing an iOS app. Off the back of some relatively complete android work, I was interested to see how the platform compared.

First steps

After the gigantic pain of upgrading a dual boot Leopard/Ubuntu macbook to Mountain Lion, installing XCode was relatively trivial (albeit I had to enter my password roughly five or six hundred more times than I’d hoped). I dived straight in hoping I would soon emerge with some useful knowledge; you will have to be the judge. Onward!

Objective C isn’t actually that weird

Once you figure out that Objective-C is seriously old (possibly even as old as C++ !), some of its idiosyncrasies start to seem a little less odd.

Boolean is YES | NO

One assumes because originally, this was a macro based implementation (C doesn’t have a boolean type; or, at least, it didn’t until C99, where a standard macro implementation appeared, I think). This stackoverflow answer adds some colour.

There are no constructors 🙁

…and this has lead to a great disturbance in the force, with two idiomatic initialization methods.

• alloc then init

[[NDHSomeType alloc] initWithParams:params]

which is tidy, but bad luck if you forget the init.

• class methods that wrap this up for you

+(NDHSomeType *) initWithParams:(NDHParams *)params

which is tidier still, but cannot actually prevent someone still doing

[NDHSomeType alloc] 🙁

This is very annoying as it hampers our ability to create truly immutable objects.

There are no namespaces

As such, XCode forces you to pick a three letter prefix for all of your class names. For shame.

Implementation hiding is a feature

This is probably my favourite thing so far. Given a Foo.h that contains

@interface Foo
@property NSString * bar;
@end

One can, in the implementation file, Foo.m , add further functions and properties as necessary, which are hidden from calling clients, thus:

@interface Foo()
@property NSString * hiddenFromClientsButVisibleInFoo
@end

This reminds me of the well used C++ pImpl idiom (see this post for a simple example), which I’m a big fan of; as such I’m pleased this exists in objective C too!

id

This appears to be the objective C equivalent of void * . Objective C is not that type friendly – collections are not generic, and calling any method you like on an id is only a compiler warning, not an error.

That said, one can, in a function definition, suggest that the actual object that is eventually passed adhere to one or more “protocols”, thus:

@protocol NDHStringListener
-(void) onString:(NSString *) someString
@end

@interface NDHStringTransmitter
-(void) transmitString:(NSString *) someString
        toListener:(id<NDHStringListener>) listener;
@end

Now we just need a class that adheres to this protocol:

@interface NDHStringDisplayer : NSObject<NDHStringListener>
@end

Passing instances of NDHStringDisplayer to NDHStringTransmitter is now fine. Annoyingly, passing instances of objects that don’t declare protocol adherence is still only a warning; although I assume one can configure the build process to make it an error.

Blocks

This is how objective C deals with anonymous functions. The documentation covers how this works, but essentially, things aren’t too bad; blocks are not too dissimilar from C++11’s lambda.

int (^addOne)(int someInt) = ^{
    return 1 + someInt;
};

int five = addOne(4);

a block named addOne , and an invocation of it.

One slight annoyance – I think all blocks are passed to other functions as id ; there’s no way to say that you expect a block that takes an int and returns another, say.

Available APIs

Asynchronous execution

This is probably the most important part of the platform from my perspective – the app I want to write does a lot of I/O, so making sure this happens away from the UI thread is important.

iOS 4 introduced grand central dispatch (gcd), which seems highly sensible. It rather provokes the question “What the hell did people do before?”, but there you go. The abstractions on top of this don’t seem as rich as android’s AsyncTask framework, but that may be because the presence of blocks makes writing your own abstraction much simpler.

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), 
^{
    NDHResult * result = [fn call];
    dispatch_async(dispatch_get_main_queue(),
    ^{
        [result passTo:receiver];
    });
});

An example of ‘dispatching’ a block to be executed in the background. On completion, a further block is ‘dispatched’ back to the main (UI) thread.

UI framework

The storyboarding provided in XCode makes it, I would guess, much easier for a lay person to get going in creating a layout. Android does have tools for this, but they are considerably more rudimentary, and any serious app will require some fiddling with the underlying XML.

Interestingly, storyboards seem to be relatively new, with many of the older iOS code examples still using a disparate collection of ‘xib’ files to create single views that are then linked together programmatically. As a beginner coming to the platform, this is somewhat confusing; which way is the right way?

I want to write quite a rich app, and I am finding that the storyboard is a bit of a crutch; I’m much happier with android’s HTML like layout model where I don’t really need to learn a complicated GUI tool in order to create a GUI! I suspect I may end up switching to the old style of xibs and doing the work the storyboard is doing in a more obvious fashion.

HTTP

Well, the provided framework is…quite low level; it feels quite like Java‘s HttpURLConnection (HUC), in that all it really wants to do is fling a byte array response at you with a few extra pieces of response metadata. This is, in fact, absolutely fine, as the included json library is perfectly capable of consuming that.

Predominantly, it also wants to behave asynchronously; I’d be interested to know if it’s powered by NIO underneath or a real blocking thread. (I am being evil and doing things synchronously on a background thread anyway, mwahaha.)

One huge upside is the lack of exceptions – each interaction may call you back with an NSError * or the resulting NSData * depending on success (synchronous methods ask for an output parameter in the form of an NSError ** ). This is way better than the clusterfuck of IOException sprinkled all over the Java equivalent.

Side note: one could compare the iOS HTTP library to Apache HttpClient, but that would be somewhat unfair, given the complete mess that android has made of deploying it, and their recommendation to use the HUC API for new apps.

Documentation and process

In general the API documentation is good – one can click through to see the provided header files and a brief google gets you to the equivalent web pages.

Some areas where Android is ahead:

• StackOverflow answers are much better

• Available examples tend to be richer, and more up to date …I suspect this is mostly because the “right” way of doing things has moved quite a long way on the Apple side, so it’s less clear what the idiomatic way of doing things is to the community at large.

• Getting the app on to a real device is trivial for Android, where on iPhone, it’s a nine step marathon that you have to pay them $99 to participate in; this is not at all developer friendly and reminds me precisely why I don’t use iOS devices more generally.

XCode

All I will say is this: within half an hour I was googling to see if IntelliJ supported iOS projects yet. I shall have to give AppCode a try.