My Troubled Relationship With Objective-C and iOS Development

Wed, Jan 2, 2013 6-minute read

New Year, new programming language! No, I was kidding. In 2013 I’ll go on experimenting with Haskell and Scala, I’ll try new languages (Do you have any recommandation?) and, as with this post, I’ll share some experiences I had in 2012 before I started this blog.

Last year I got involved in the development of a small iPad app for museums (It’s still on development. You’ll get more details when it’s ready) and since then Gabriele keeps asking me my feelings about Objective-C and iOS development, his favourite programming language and platform.

I say that my relationship with them is troubled because I really love the things you can build and the maker me is just happy to produce something beautiful, but the coder me sometimes feels that there is something wrong.

As a general disclaimer, it could be that the bad feeling is just due to my inexperience. Please feel free to leave a comment with the right way of doing things.

The language

Oftentimes people who see Objective-C code for the first time complain about square brackets. Trust me, it is not an issue, it’s just a matter of habit. After a while Objective-C conventions, especially the way parameters are handled in messages, make the code pretty clear to read.

Read the following line of code and you’ll immediately know what id does, even if it is the first line of Objective-C you have ever seen.

[anArray insertObject:anObject atIndex:0];

As soon as you get used to the square brackets you’ll notice that the syntax looks suspiciously too similar to C. In fact it is a superset of C (oh-my) adding object-orientation in a Smalltalk-like message passing fashion.

To me this means that you can do all the bad things that you can write in C, even when there are cleaner ways to do it. It is true that it is up to the programmer to choose how to implement a feature, but the language does nothing to prevent him to just cut and paste some old C code.

Just to be clear, I am not against polyglot programming. Not at all. If you think that C is the right tool for your job or if you need to use some libary that is written in C, you can use both Objective-C and C code in your application. What you must avoid is to write Objective-C code littered with low level operations, pointer arithmetics and other things that you can do just because the language is a superset of C.

Moving to some Objective-C specific features, I like the separation of interface and implementation code, but why should I declare instance variables in the interface? In my opinion instance variables should be implementation details, not part of the interface of the class. I know that C++ does this too and I keep thinking that both the languages are doing it wrong.

Objective-C memory management, with Automatic Reference Counting, is a huge improvement over the C/C++ way. As always when there is something that the compiler can do something in my place I feel that this solution is pretty good. You don’t have to deal with manual memory management nor you have the performance penalties and impredicatability related to garbage collection. And you don’t have to write any line of code to do that. Can you ask for something better?

Another thing I like a lot is the @synthesize keyword that let the compiler write for you the code to deal with attributes.

I prefer statically typed languages and I still have to decide whether I like or not the Objective-C type system. I am not sure that the:

Look, I know what I’m doing. Just trust me and everything will work out just fine.

is the right approach. But this is more a matter of taste and a philosophical choice than a specific advantage or disadvantage of Objective-C. I simply happen to trust more the compiler than my fellow programmers.

Another thing I don’t like is the very hard to debug behavior associated with a messages sent to NIL. In other languages you have a NullPointerException, in Objective-C it does nothing. I prefer code that fails early, in a very clear way, to code that silently tries to go on as everything was ok.

I am sure I missed to talk about some good part of the language. It may be because I still don’t know them, so please write a comment with the Objective-C features you like the most.

Packages and libraries

Every time I looked for a library to do something not implemented in Cocoa Touch or a particular user interface control I was about to cry. I missed a build and dependency mangagement system like maven or SBT. I missed them a lot.

My sub-optimal workflow was to Google what I needed. Usually what I got was a list of packages, sometimes written in plain old C. The bad thing about the Objective-C packages are their names. They have the very same name but the first two letters that represents the initials of their author. Is this the best we can do in 2013 to avoid name clashes? Really?

At this point I had to pick one of them, choosing between the one with the best screenshots and the one with an author with the most reassuring name, and find a way to integrate it with my project. Unfortunately even the latter step is far from being flawless and it should be improved. I remember having troubles integrating a library not using automatic reference counting in a project using it.

Please, tell me I was doing it wrong. I can’t believe real coders work in that way.

Tools

To conclude this post I have to spend some words on Xcode, the IDE you are going to use if you want to write Objective-C code, and on the iOS simulator.

Xcode crashes too often. Apart from that (very bad) downside it is a decent IDE with a very good tool to design user interfaces.

The simulator does its job well, at least for the very simple application I worked on. It is well integrated with Xcode and you can debug your application running in the simulator. Unfortunately I used it only for the very basic tasks so I cannot write something more detailed.

The impression I had was that the tool are good enough but far away from excellence.