Dilemma meets opportunity: iPhone beta SDKs in review
Will you tread the Cupertino path?
iPhone SDKs are like buses these days, the appear so frequently. Since my introductory piece on iPhone development, Apple has rolled out an initial SDK preview, a second iteration of the SDK (Beta 2) while a third beta followed not long behind. The second beta included the much-anticipated Interface Builder application but Beta 3 actually makes it work.
So what are you getting from Apple? Turns out an interesting bag of technology that comes with some philosophical choices for developers over whether they work with Apple or follow their own path, independent of the company, building iPhone applications.
First, the good news: the iPhone SDK is free to download and is essentially a set of add-in tools and libraries for the existing Xcode development system.
The bottom line is that, with the SDK installed, you can choose whether you want to create iPhone or "regular" Mac applications, all with the same development tools. This is obviously a lot more convenient than using a Cygwin-based toolchain under Windows, which is what I alluded to in my earlier piece.
The SDK includes a cute, on-screen iPhone simulator that you can use to test and debug many iPhone applications directly from Xcode without deploying to an iPhone. Opinions differ about whether it's a simulator or emulator but I'd go with the former.
Xcode generates an x86 application for the simulator that is itself an Intel executable and uses a set of frameworks that provide the same API as the actual ARM executables in the device. In other words, no ARM code is involved during a simulator run.
The new firmware is notionally version 1.2, although it will be rechristened 2.0 when it officially hits the iPhone. At the moment, you can only run 1.2 on the simulator. At least, officially.
Now some bad news. As mentioned, Beta 2 included Interface Builder and offered the ability to visually lay out the various elements of an iPhone application. Sadly, Interface Builder wasn't as well integrated with Xcode as it should have been. If you're still working with Beta 2 and can't figure out how to make things work, look here. But ideally, you should already have upgraded to Beta 3, in which case you'll find that Xcode obligingly adds a MainMenu.xib file to a new project, and double clicking it launches Interface Builder, just as a Cocoa developer would expect.
Another issue you might run into - I did - is that if you've previously downloaded the sample iPhone applications, they will no longer work after you install a new beta.
This happened to me when I went from Beta 1 to Beta 2, and again when I went to Beta 3. This is primarily due to API changes. The solution is to simply re-download the updated samples from the Apple web site. You can find an official list of API changes between Beta 2 and Beta 3 by clicking here. The previous delta document - Beta 1 to Beta 2 - has disappeared, so if you've written a lot of Beta 1 code that no longer compiles, you're on your own.
Apps in store
Technical gotcha's aside, the commercial and legal limitations are much more interesting. As you'll no doubt have heard by now, Apple is introducing the App Store with the release of the 2.0 firmware.
Think of it as iTunes for applications. From their iPhone, users will theoretically be able to browse, purchase and download third-party applications with (presumably) a mechanism for alerting the user when an updated version of an application becomes available.
Apple will get 30 per cent of the cash made on a sale, with the remainder going to the developer. That's not too unreasonable when you consider that a small developer can forget about the hidden costs of web hosting, publicity and credit card fees - everything is done through App Store.
To be able to sell applications in this way, you have to register as an iPhone developer, which costs $99. Crucially, if you don't register as a developer, you won't even be able to deploy an application to a phone running the 2.0 firmware. This is because a registered developer receives a special key that the compiler uses to digitally sign applications. If the firmware doesn't find a valid signature within the application, then it won't run.
As you'd expect, this sort of restriction is like a red rag to a bull as far as the open source community is concerned. Allegedly, the key needed to get the firmware to give the thumbs up has already been posted on the net, but as far as I can see, it's just a decryption key for IPSW firmware updates, which is quite different. One thing's for sure: Apple will change the key before the official release in a couple of months' time, so it doesn't much matter either way.
I believe that the upshot of all this will be fragmentation. On the one hand, we'll have the official developers selling their Apple-approved products through App Store. These programs won't be able to fully leverage the power of the platform because Apple won't let them. One of the bits of small print in the iPhone developer agreement is that you can't use undocumented APIs, which immediately gives Apple a big advantage over third-party developers.
On the other hand, we're going to see the so-called "Open Source tool chain" - again, see my previous article - becoming increasingly popular in the shareware community.
Unlike the official route, this approach will give you access to all the available APIs (read that as more efficient and more capable applications) and a more traditional business model: marketing your software from your choice of web site rather than being forced to go through Apple's App Store.
Of course, this begs the question of whether or not the hacker community will be able to crack Apple's digital-signing mechanism, creating applications that are accepted by the 1.2/2.0 firmware. Based on previous track record, I really don't see this as a big deal. The necessary sleight of hand was online within a couple of days of the official firmware release.
And there are other advantages in going the unofficial route. Apple bans third-party developers from creating background applications - processes that lurk doing stuff while another application is in the foreground.
There are some solid justifications for this approach in terms of security, reliability and battery life. But for applications that really, really must operate in the background, and are intelligently written enough not to kill the device's battery life, then the unofficial approach is probably the only way forward.
Just to muddy the waters a little further, a number of enterprising individuals have figured out how to massage the official SDK tools so as to work with previous versions of the firmware. Point your browser here, and you'll find a series of steps describing how to get Xcode and the simulator to work seamlessly with firmware 1.1.4 - the latest, official firmware at time of writing. This gives you the convenience of the SDK, and the power of the full 1.1.4 firmware, undocumented goodies and all.
The bottom line is that there is still a lot left to fall out of the iWars between Apple and third-party developers who don't wish to go the official route.
I can't help wonder how much simpler life might have been if Apple had planned to open up the iPhone from the beginning. This is either something that - in my opinion - Apple decided against from the start, a possibility given the company's track record on closed environments, or it realized the financial benefits of keeping the iPhone a closed and controlled platform later into the product's development cycle.
Either way, if Apple had welcomed third-party development from the start, then we might have a secure sandbox for non-Apple applications, a scaled down hacking war with the developer community, and maybe less neurosis at Apple. Hindsight is a wonderful thing.®