I haven’t written any posts lately. This is because I dug into iPhone application development and this really consumed most of my spare time. As you may remember, I’ve already mentioned that I would like to start dealing with mobile platforms as a target for my OpenGL related experiments and projects.  After Android, this time I got my hands on a Mac mini and took a look at the currently most popular mobile gaming platform. Actually, these initial experiments wouldn’t take that long time if I would have to deal with just a new API and not with a brand new world with its own benefits and drawbacks.

I have a long experience in using Windows and Linux as a development platform with tons of different development environment and programming languages. Beside that, I’ve also done some Mac application development, at least if we can call a cross-platform application so that works on all of these three desktop operating systems. Taking in consideration these facts I thought that starting to develop under Mac OS X targeting the iPhone platform will be piece of cake as I just have to master one another programming language and API, namely Objective-C and Cocoa Touch. Well, it turned out that I was too optimistic and this is not that simple as it looks like (at least for me, who hardly ever used a Macintosh before).

Mac OS X LeopardThe GUI of Mac OS X Leopard

The first thing I’ve found very unusual is the user interface of the operating system. Primarily, I’m talking about the following little differences:

- The menu of the windows is at the top of the desktop, not the top of the window.

- The system buttons on the window title bar are on the left side, not on the right side.

- Double-clicking the title bar doesn’t maximize the window, it minimizes it instead.

- The most used key combinations like Copy-Paste and stuff like that are also different.

Okay, I know that these are such things that everybody know who already seen the GUI of Mac OS X, but still, it’s quite annoying that Apple is going totally against the rest of the PC world. I agree that different operating systems can define their own direction regarding to the layout of the GUI, but I wonder how I didn’t notice such huge conceptual differences when I’ve first started to work on Linux after several years of Windows user experience?

Anyway, these are just small things and it’s just a matter of time to get used to the new interface. Also, I can say that the Mac OS X user experience is excellent. I don’t say that it is any better than that of Windows or some well-made Linux distributions but it is not worse either.

The Xcode IDE

Those who heard anything about iPhone development know that the only legal possibility to write applications for this mobile platform is to do it under Mac OS X using the Xcode development environment. I know that thousands of people will blame me for what I’m going to say but I sincerely think that Xcode is the worst development environment I’ve worked with lately.

First of all, it was completely alien for me even though I worked with dozens of development environments ranging from basic text editors to full-fledged development environments with every tool integrated within them. While the most used editor features like syntax highlighting and code completion work flawless, there are huge amount of features missing from it that are common in other IDEs like a source code outline window. But this is not the only thing I can complain about…

As I mentioned it before, I dealt with many different development environments, the most noticeable ones are CodeGear RAD Studio, Visual Studio and Eclipse. What is common in these (and a lot of other Windows and Linux IDEs)  is that if you migrate from one to another you’ll most probably won’t notice too much except some minor differences in key bindings. I think actually this is the way how it should work as if I would be the head of a software development company I would invest in a development environment that can be easily learned no matter what my future employees used earlier. This reduces competence development cost and enables the programmers to work more effectively in a relatively short time-frame. Well, it seems that Apple disagrees with me as comparing the aforementioned IDEs and Xcode is like comparing an armchair with a stool.

In spite of all his faults, Xcode has also some clever solutions for some usual tasks that makes it popular even though Apple gone again against the rest of the world with this software so I don’t say that Xcode is completely useless, but what’s for sure is that it has a long way to go in order to be able to compete with the other development environments out there. I don’t even understand why didn’t they just made a simple Eclipse plugin for their purposes like all other players do?

While maybe I’ve already scared many of you from using Xcode, yet I haven’t talked about the “feature” that made me the most frustrated about my new development platform. As I already mentioned, there are big differences between the key bindings of usual PC platforms and Mac OS X. I haven’t really worried about them, because for the basic navigation it is not a huge burden to get used to it, but when it comes to code writing I’m more choosy…

It seems like in the Mac world the Home and End keys have totally different meaning, in particular they don’t control the position of the cursor in the current line instead they control it in the scope of the file. As I’m heavily using these keys during source code editing I figured out it would be a huge burden to get used to this little but important difference. Fortunately, Xcode has possibility to change the key bindings of the editor but I was already quite pessimistic about how much hassle I will have with the key binding so I thought one step further and started to google for a quasi normal key binding for Xcode. Soon, I’ve found a Visual Studio-like one here that you can download below:

Visual Studio Key Bindings for Xcode

In order to install it, you only need to unzip the file MSVC.pbxkeys, copy it to /Users/YourUserName/Library/Application Support/Xcode/Key Bindings/ (if the directory doesn’t exist, just create it), restart Xcode and select the configuration set in the key binding tab of Xcode’s preferences window.

The Apple Developer Program

While the new key configuration already solved most of my problems that prevented me to efficiently start working on my first iPhone application, soon I realized how much of hassle an iPhone developer has to deal with on a daily basis…

As soon as I mastered the very basics of developing for the iPhone OS, I registered myself for the Apple Developer Program. It costs you $99 per year but it most probably worths its price as beside the fact that they deal with the publishing and marketing of your application, according to other developers I know, they also give adequate support for the money. The registration itself was very straightforward. I just had to fill and fax an application form and next day my developer program was already active. What made me outrageous at the end is the amount of administrative work that is required from the iPhone developers in order to solve the most simple tasks.

If you just want to play with the iPhone Simulator, the basic configuration of Xcode and the iPhone SDK is adequate, but as soon as you would like to try out your application on a real device, things get more complicated. As an example, I wrote my first cube rotating OpenGL app and wanted to test it on the iPhone of my friend. First, I thought that this will need only three things: connect the iPhone to the Mac, select the real device as target in Xcode and then press the Build&Go button. Well, it turned out that it is much much more complicated.

First, you have to create a certificate on your Mac that you have to upload in the Apple Provisioning Portal and then download it from there, install on your Mac, then connect the iPhone to the Mac, open the Organizer in Xcode, copy the device identifier of the iPhone, go back to the Portal, add the device, then go back to Xcode and copy the reverse URI of your application and then add the application in the Portal, create a provisioning profile with the device-application pair on the Portal, download it and add to Xcode and now you can select the device as target and press the Build&Go. This would be even acceptable if you would have to do it only once, as a preparation for development, but this is not the case. You have to create an individual provisioning profile for each and every device-application pair that you want to test. This is simply too much, especially in the early phases of development as you may start with several different test projects.

iPhone SDK and Mac OS X Leopard

You may think that after these steps I’ve already had my box rotating app running on the iPhone. Well, if it is so, then you’re wrong. Things got just more annoying after this… After investing money into a Mac mini and paying $99 to Apple for entering the Developer Program I though that I can startup with my first real project but I was wrong as well.

I bought the Mac mini from the brother-in-law of one of my friends. As he already developed some iPhone applications on the Mac earlier, I’ve already had Xcode and iPhone SDK 3.0 installed on it. The problem I’ve encountered is that just the day before my friend, Imi brought his iPhone to my place in order to test the application he had to update the firmware of the phone to iPhone OS 3.1.3. You may wonder, but Xcode with iPhone SDK 3.0 doesn’t work with an iPhone device that has the version 3.1.3 of OS installed on it.

Well, I thought I will just download the latest version of the SDK from Apple’s website, but I faced some further surprises… Actually there is a free download of Xcode 3.2 and iPhone SDK 3.2 at the site what you can freely download. The problem with this is that it works only on Mac OS X Snow Leopard but not on Leopard.

At this point I was thinking about that I’ve already invested a huge amount of money and now I have to pay another $29 for the OS update just to run my box rotating app on a real device. Anyway, I’ve chosen to invest this remaining amount as I really want to develop some games for iPhone. Unfortunately, I figured it out soon that you can order the OS update only inside US and there is no any way to grab a downloadable version for your money (at least as far as I can tell because I was already too pissed off to spend more time on Apple’s site to look around for a solution).

Our next idea was to downgrade the operating system of the phone to match the SDK what we have but Imi informed me that the oldest OS what you can downgrade for is 3.1.2. This was the time when I gone mad. I really found it ridiculous that someone buys a developer machine that was earlier capable for the purpose and afterwards, due to some stupid decision at Apple, it is simply not capable for it anymore, unless you pay more money to them for the OS upgrade. Anyway, at this time I would have been already satisfied if I can pay that $29 for the upgrade just to run the app.

It was actually pure luck that I didn’t give it up and started to google for people who met the same problem lately. Fortunately, I’ve found a guy struggling with the same problem and he posted a download link for the SDK 3.1.3 that works also on Leopard. He really saved the day! If you are having the same problem just grab the SDK from the following address:

Download iPhone SDK 3.1.3 and Xcode 3.1.4

Conclusion

Without the intension to blame the guys at Apple or anybody else, I can say that becoming an iPhone developer involves much more trouble that I have ever thought it could. Anyway, now I managed to get to the point where I can actually start to be productive so I won’t give it up now…

I planned to talk also about implementation related issues and tips in this article that you are most probably more interested in, but it seems that this topic is left for a future article as I had so much things to share now that it simply didn’t fit into the time-box. Anyway, I will recap on the topic in the near future.