The Story Behind iPhone Apps

Four months later, Jobs recanted in an open letter on Apple's website: proper third-party apps would be allowed after all. And on 6 March 2008, the dream came true: the iPhone SDK (software development kit) for Mac OS X was made available for download.

Reaction to the SDK release has been largely positive ever since its release. "The iPhone SDK is wonderful - much more than I expected," says Craig Hockenberry, principal and engineer at Iconfactory. It's a view echoed by equinux CEO Till Schadde. "Apple's SDK solution is well designed. It offers an easy way for the existing community to develop simple apps for the iPhone. The tool chain is complete and simple, and all necessary tools are available." Schadde's point about it being easy for existing Mac developers to create iPhone apps is important. Because the iPhone is built on the same foundations as the Mac's operating system, the development tools used to create apps for the iPhone are essentially identical. The core program is Xcode, which enables you to write your iPhone app's key functionality. Xcode ties into Interface Builder, which enables you to create your app user interface and link visual controls to the functions you've written. You can then open the app in iPhone Simulator, which emulates the iPhone operating system on a Mac for basic testing, or transfer your app to a real iPhone for live testing. Another application, Instruments, enables you to performance-test more complex apps so that you can make your software run as efficiently as possible. (The knock-on effect, of course, is that the shared development suite also enables new developers to discover how easy it is to develop software for the Mac as well.) "We're very happy to see that our expectations were met," says Marco Piovanelli. "Developing for the iPhone involves the same tool chain, the same programming language, and mostly the same frameworks modern Mac OS X developers know and love. That means we can leverage our long-standing experience to get a head start over the developers flocking to the iPhone from other platforms."

Not everyone has been happy with the iPhone SDK, however. "The SDK also comes with many legal restrictions as part of the agreement," says Paul Kafasis, CEO of Rogue Amoeba. "These restrictions are onerous, and we've talked publicly about how we believe they'll stifle innovation unnecessarily. There will be hundreds of good apps for the iPhone, but it will also be missing plenty of apps it could have had, because the SDK agreement prevents developers from making them."

For iPhone users, the App Store is a one-stop outlet for buying and downloading apps from the huge choice available. It's simple and convenient. For the developer, the App Store is the only option they have if they want to distribute their work to the public. That means that iPhone developers have no choice but to accept the conditions Apple sets to gain admission to the App Store.

For example, Apple takes a 30 per cent cut from each sale. While this may sound high, Mac developer Chris Wilson believes the deal is fair. "[High Street] retailers make the price whatever they want, so profits range from 10 to 200 per cent. With Apple's model, there's a constant understanding of the costs, and developers can account for Apple's withholdings when determining the price of their application."

Piovanelli agrees: "The 30/70 deal sounds sweet to us, especially considering that Apple will be shouldering the entire cost of the distribution infrastructure - hosting, bandwidth, payment processing, automatic updates - and even part of the marketing expenses." Rogue Amoeba's Kafasis points out that the revenue split is potentially the least contentious part of the App Store.

"I think 30% is a bit high, but it's within reason. People are overplaying the supposed exposure they get through the App Store, but it's still a good thing. It streamlines the process of getting software to users, and I think it will encourage many people who wouldn't otherwise buy software to do so.

"However, I view having the App Store be the exclusive way of getting software as a distinct negative. The only argument I've seen in favor of this
is that it will enable Apple to better control the software. The idea that Apple can provide true quality control or security isn't realistic. They don't do this on the Mac; users would have a fit if they tried.

"This one limitation also means that we're stuck with everything else in the SDK agreement. If users could load our software on to the device on their own, we wouldn't need to worry about appeasing Apple. However, because we need to be approved for the App Store, we have to follow requirements."

Apple is justifiably keen to keep the iPhone clean and stable; any instabilities or crashes that the user experiences are as likely to be blamed on Apple rather than on the developer. It has publicly stated that it will not allow apps on the App Store that are illegal, malicious, pornographic, hog bandwidth, compromise privacy or fall under the worryingly vague description of 'unforeseen'. Apple can enforce these because its App Store is the gatekeeper; the only legal and, as far as the average punter is concerned, possible way to install apps.

There's huge potential for the iPhone as a platform - its meaty processor, accelerometer, location-awareness and innovative Multi-Touch interface opens it up to some original programs - but developers should understand all the implications of writing iPhone apps before taking the plunge.