I’ve been a lazy blogger lately, but it doesn’t mean that I haven’t been doing anything. Actually, I’ve done quite a lot lately. I’ve started to educate myself to iOS development. Don’t get me wrong. I haven’t changed the camp from Qt development to the iOS development, but I think it’s just a sane move to do something completely different to keep mind open and to learn new things.
As I’ve mentioned in my earlier posts, I also own Mac and iPhone, so I thought that I should try code something for iPhone. This blog post is about my thoughts what it takes to start coding on iOS operating system and what it requires if you are coming from Qt world.
DISCLAIMER: This blog post might contain errors related to iOS and Objective-C because I’m really newbie in that area. Please feel free to comment if you notice any errors in the text.
The First Challenge – Objective-C
Actually the first challenge is that if you don’t own Mac, you need to buy a new computer first because iOS development can only be done on Mac. If you happen to own Mac, then you just need to install XCode with iOS SDK which can be downloaded from http://developer.apple.com.
The real first challenge is the Objective-C programming language. I’ve coded only using C, C++, QML, Java, Python, but never using Objective-C. The syntax looks really weird like [myObject doesSomething: parameter1 andDoesSomethingMore: parameter2]. I am also lazy in a sense that, if I need to learn new things, I get bored quite fast if I can’t try things in practice soon. Instead of starting to read Objective C manuals from Apple site, I googled a bit and found this useful document: From C++ to Objective-C written by Pierre Chatelier. That piece of paper was really useful to get fast into a Objective-C world and to understand that weird syntax.
Thoughts about Objective-C
After starting to understand how to use Objective-C and many of its features, I really started to like the language. It’s very object oriented and dynamic and provides an interesting alternative for inheritance. For example in C++, if you want to extend a class, you usually use inheritance. In Objective-C you can also inherit, but it’s possible to extend the class using categories. In practice, categories can be used for adding new methods to a class. This way it’s really easy to extend built-in classes e.g. by adding convenience methods.
This blog post is not about Objective-C so I’m not gonna go through Objective-C syntax much, but if you like object oriented paradigm, it’s really worth to get familiar with Objective-C. You should especially check out how properties, delegates, protocols, selectors works, but the memory management is the most important thing to understand. It might be a bit confusing because of reference counting. With a little effort, it’s definitely the must thing to understand. To understand how memory management works, read the memory management chapter From C++ to Objective-C paper.
I think, it’s also worth to mention here that Objective-C makes possible to use C and C++ quite easily. If I have understood correctly, it’s possible to include a C++ header and start to use it from Objective-C code. It’s actually not so rare case that game developers have written a game using C/C++/OpenGL ES based game engine or a scene graph. Then they implement only a thin layer of Objective-C, which is required in order to run the game on iOS. Btw, Android NDK provides tools for porting native C/C++ code to Android.
Apple has used a design pattern called “Delegate” a LOT. Delegate is an abstract interface and comparable to C++ class which has pure virtual methods. A delegate is a “Protocol”, which you need to implement and register to the “Controller” instance. In practice, when the controller wants to notify the delegate or pass data to the delegate, it calls the delegate method(s) of the registered delegate. Let’s take an example. If you want to use UIImagePickerController to pick an image from a device photo library, you need to implement delegate methods defined by UIImagePickerControllerDelegate, register your delegate to UIImagePickerController. When the image picker is displayed and you select an image from a grid, the controller calls delegate methods and passes the picked image information to the delegate.
For me, it looks like Apple has introduced pretty well working design pattern and it seems to work for most of the things done on iOS. At some cases, controller classes might grow a bit too much if you need to implement several delegates in a one controller. This might be a lack of my understanding how to build good structure for iOS/Objective-C application, but this was a one thing that I noticed to happen quite often.
The Second Challenge – XCode & iOS SDK
Documentation
iOS SDK is not an exception when it comes to learning a new SDK. Like Qt, the iOS SDK is large and provides a huge amount of functionality. The documentation is rather good, but I think that Qt documentation still beats iOS documentation in many areas. I really like the way how Qt documentation usually have many small code examples embedded to the class documentation in addition to larger demos and examples.
In iOS SDK there are few getting started documentations with walk-through explanations, but then all the other examples are pretty much functional xcode projects, which you can run on iOS device or on a simulator. I would also like to see more walk-through-documentation for using Interface Builder.

Organizer - Documentation
As you can see from the screenshot above, XCode provides Qt Assistant like documentation tool called Organizer, but it also includes much more such as information about development devices, repositories, projects and archives. With organizer, you can view logs from the device, take screenshots, see information about your developer and provisioning profiles etc. Also, if you start refactoring your project, XCode automatically takes a snapshot of your project in a case you happen to mess up things. You can also make a snapshot of your project any time you want.
Even though Apple has provided pretty nice tool for a documentation and for the other stuff I mentioned, I was bit surprised that the documentation didn’t reach to the level of Qt documentation. For example, the search functionality doesn’t always find the class documentation even though the class name is written correctly and in some cases it’s missing very important information related to some features. When Organizer couldn’t give me good enough explanation, then I usually use google and stackoverflow…. And I have read stackoverflow a lot, lately:)
XCode, iOS SDK and iOS Simulator
As mentioned already, the XCode and iOS SDK can be downloaded from http://developer.apple.com or you can buy XCode from App Store for 3.99€. The installation is as easy as installing any other application except it may take a little bit longer. After XCode and iOS SDK installation, you can create a new project using different project templates e.g. a window based Cocoa Touch application. Once the app template is created you can hit the Run button and XCode opens the selected simulator, which can be either iPhone or iPad simulator.

My application running on iPhone simulator
Running an application on iOS device, requires that you pay 79 euros (99USD) to Apple and after that you need to create and install provisioning profiles + certificates etc. IMHO is that it’s not such a big amount of money to get a distribution channel to millions of devices. After setting up everything (profiles and certificates) your development device is ready for running iOS applications from XCode. Only thing that you need to do, is to select your device instead of simulator.
I think, Apple has managed to make XCode and iOS SDK installation very easy. Running the first application on the simulator takes only a few seconds after you have created your first project from a template. If I have understood right, you can’t use the simulator for testing e.g. accelerometer related functionality such as shaking the device, but you can switch an orientation between portrait and landscape.
XCode 4.x
When I tried to use XCode 3.x for the first time, I was a bit shocked how crappy it was. It looked and felt really old fashioned with all the windows and it was behaving in odd way. Soon after my first experiments, Apple released XCode 4 and it was really a huge improvement. The UI looks now modern and acts pretty much in a same way than many other IDEs nowadays.

XCode Main Window
I split the XCode window for demonstration purposes on my 15″ laptop. On the left side there is a project tree, on the left middle section there is the Interface Builder view, on the right middle section there is a piece of source code to where I can drag Outlets or Actions from the Interface Builder. On the right side are components for the Interface Builder and details area. XCode let’s user to decide what she/he wants to see on the main window. I rarely use the mode seen above, but I enabled it for this screenshot.
One thing that I have noticed during the development is that, the code I write builds successfully almost always, because XCode notifies clearly of any errors in the code while writing it. The code completion is the main reason for this. Even though, I said that I have started to like Objective-C, I still think that the syntax is sometimes really confusing and ugly. Especially when using nested method calls (or sending messages) the IDE’s code completion is a great help.
XCode Tools
XCode provides great set of tools to help iOS development. Here is a brief listing what it provides
Interface Builder
Interface Builder is a tool for building iOS like UIs for you application. I think, it’s possible to build the whole UI in a code only without using Interface Builder, but Interface Builder works pretty well. To build an interface as shown in the simulator screenshot, takes only a few minutes. After the UI layout is ready, the UI components such as UITableView or buttons need to be connected to the Controller class. This connection can also be done just by dragging “a connection” from Interface Builder to the source code. The connection can be for example an instance variable for table view or an action (method) which is called when user hits a button.
Core Data Editor

Core Data Editor
Core Data Editor is a tool for designing a persistent storage (database) for you application. At least for me, the graphical visualization usually helps to understand the design better whether it is a class diagram or models a database structure. It’s quite easy to design the database and after the design is ready, hit a button and it creates corresponding classes for you. I was really surprised how easy it was to create a database and start to use it. This is really a something that Apple has designed very well in object oriented way.
UPDATE: After updating to iOS 5 SDK, the build started to fail because one of the generated classes was named as “Category”. It seems that with iOS5 that class name was reserved for internal use. The annoying things was that when generating classes from Core Data model, it doesn’t notify in anyway that you have wrongly named NSManagedObject.
Debugger, Profile and Analysis Tools
Naturally XCode provides a graphical debugger, which seems to run gdb under the hood, but in addition to debugger, there are also other tools available. You can run Profiler tool for detecting e.g. memory allocations and leaks or Core Data specific operations.

Profile Tool
In addition to this dynamic tool, it’s possible to use static analysis. Analysis tool provides nice way to check e.g. if allocated memory is released properly or if there are unused variables. I found Analysis very convenient tool to check the memory management errors.
About Application Development
I’m working on my first iOS application called FoodGarden. It uses Core Data heavily and most of the views are UITableListVIew based views. I was really amazed how easy it was to create simple list view based UI on top of Core Data. Everything just “seems-to-work” nicely, but…

FoodGarden Startup View
Everything works pretty well, if you go in between the lines, which Apple has set. If you want to step out of those lines, then you end up doing different kind of hacks. Good example is that if I want my list view to be sorted based on sections you can do that easily just defining that the sort criteria is a “string” such as section name and the order (ascending/descending). That suits for most of the cases, but when you want to have a custom order for sections then you need a hack.
Also when it comes to Core Data, I think it suits for most cases very well, but when you want to do little bit more complicated things, then you sort of start to miss SQL. But as stated earlier, Core Data suits most of cases perfectly. It’s a very object oriented way to interact with a database and it takes care of how data is handled in the background. This naturally requires that developer has designed the database structure and relationships correctly.
When coming from Qt world, I have used to of creating re-usable components when ever that’s possible. At least for me, it was sort of quite difficult to gain that using iOS SDK and Objective-C. Somehow, I felt that very tight coupling between xib (User Interface Files) and Controller code made that more difficult. Most likely the reason for failing in this area, is probably caused by my lack of experience of Objective-C and iOS development.
Another thing that I really miss from Qt side is, that in Qt, it’s quite easy to hide or show UI components. For example in edit mode, the UI/View might want to disable some of the functionalities related to that view. In the Qt world I could say the obj->hide() or obj->show(). Usually the “objects” that I wanted to hide or show in edit mode are components on a toolbar. The problem with hide/show approach here is that you can’t call anything like that for UIToolbarItems. Instead you need to either add or remove them from the toolbar, which requires way too much work to do such a simple thing.
Well the good thing about going to iOS from Qt, is that I think many of the concepts and ideas in iOS are quite close of the concepts in Qt side. Both are very object oriented toolkits and once you have learned the Objective-C language, you can create cool looking applications fast.
Summa Summarum
This blog post is already way too long so therefore I want to end it here. As a conclusion, I can say that, I don’t wonder anymore why there are so many applications in Apple’s AppStore. Actually, it doesn’t require much skills or previous programming experience to provide something like simple TODO-list, fart machine or some brain dead applications. Naturally, there are also top quality applications, but most of the apps in the store are more or less crap. You may disagree, but this is my opinion.
For me, iOS programming have been a refreshing experience and I think the environment itself is quite nice. As mentioned earlier, if you follow the path that Steve has defined, you can manage quite well and things usually just works. Going to the side track may cause you problems. If you end up having problems, other developers have most likely already solved the problems so you can easily find answers from Stack Overflow or other sites.
Even though I also mentioned that I’ve started to like Objective-C, it’s mostly because it’s very object oriented. I still can’t say that I love its syntax, which often looks ugly. Sometimes it’s also hard to catch some problems because compiler doesn’t stop or give error, but you’ll end up having a crash on run-time.
The documentation was sort of surprise for me. With this I mean, that I would have expected at least the same level documentation as Qt has, but iOS/XCode didn’t reach to that level. Makes me wonder why the “search” didn’t find all the classed I searched? Also I would like to see more Qt like walk-through-examples there.
I’ve worked on FoodGarden application few months now and I’m already missing Qt development. I will write another blog post about FoodGarden soon, but after I’ve released it, I will continue QuickFlickr development for N9(50) as soon as I’ll get it to my hands.
Thanks for reading my blog and sorry about the length of this blog post:) I’ll try to make it shorter next time.
This was indeed a good read and perfect experience, which happen to be a similar experience to mine.
I am a Qt developer at heart but I also happen to write for both Symbian and Android devices as well (I am still new to iOS and I have completed 4 Android apps) and I find here my experience esspecially with the documentation part.
Also one more thing to note for other Qt developers that was missing here is that on iOS 5 there is a new concept for making memory management easier that is called ARC (Automatic Reference Counting) which short description can be found here: http://developer.apple.com/technologies/ios5
Now retains and releases are a compiler job and not human job which is very useful for programmers, though Qt handles this in a very good way (by instanciating main wi(dget)ndow on stack and running the event loop then when event loop returns the main wi(dget)ndow will delete itself (because main function returns) and all other objects that are instanciated in the heap and have this main wi(dget)ndow as parent will be deleted.
Hope to see more blog posts like this man!
Cheers!
@milot Hey thanks for your comments! I need to check the link you provided. It’s something that is definitely worth to read.
It’s also worth keeping in mind that iOS API enforces the design guidelines (http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html) whenever possible.
This means trying to code stuff that violates the design rules can hit a dead end, forcing the stubborn towards hacky solutions. One example of this is that the toolbar at the bottom, when used, is supposed to be a static element, having same content across all screens and acting as the main navigation method (see e.g. the iOS’s native music player). Thus, dynamic changing of toolbar content is against the rules.