Adam Houghton: Visiting Aspen: A Trip Through the iPhone SDK

Currently writing about GWT, Ajax, Leopard, iPhone Development, and Java.

Visiting Aspen: A Trip Through the iPhone SDK

Saturday, March 08, 2008

The real iPhone SDK has arrived. While I enjoyed developing iPhone web apps (and have another one in the works), software developers like myself were waiting for something beefier, and Apple delivered a heifer. The previous web-only "human interface guidelines" weighed in at a measy 54 pages. The new guidelines are double that size, and serve as an addendum to the 200 page iPhone OS Programming Guide. I've been plowing through the docs and tools to learn about the new SDK and v1.2 of the iPhone software, codenamed Aspen. It's been a fun trip.

The Good
Apple delivered an architecture familiar to any OS X developer: Objective-C, Cocoa, and lots of Core* frameworks. Built on top of a Mach kernel, the iPhone OS contains all the basics like threading, networking, and file-system access. The gaming industry will be happy with support for OpenGL ES (embedded systems), 3D audio, and access to the accelerometer. For business software developers, the exciting technologies are SQLite (a lightweight, embedded database that is taking over the world) and XML parsing via libXML2 and libxslt.

But in my mind, the real All-Stars of the SDK are:

Full access to multi-touch events via the Cocoa touch framework
Location-based services (triangulation and bonjour)
System-wide access to address book contacts and photo albums

These features show off the power of a mobile device, while providing consistent, unified services to make it a mobile platform.

The Bad
The biggest letdown is that Apple didn't expand this mobile platform far enough. While the shared address book contacts and photo albums are great, there are a few glaring things that developers can't access:

appointments from the Calendar app
music or videos from the iPod app
phone or SMS functionality

Calendar integration seems like a no-brainer. There should be a way to schedule and share appointments between applications. iPod media support is probably restricted due to DRM issues. The iPhone supports video and audio playback, but only from remote servers or local files within the app's sandbox. Phone and SMS restrictions are likely due to the carriers & security concerns. Phone calls can be initiated via "tel:" links, but this is the same, limited action currently available to web pages: the phone app launches and prompts the user to confirm the call. There's no way to integrate with voicemail, access call history, or initiate a text message. Given the potential for abuse, this is probably a wise restriction. However, when Apple brags that 3rd party developers use the same tools and access the same APIs as engineers in Cupertino, this is only partially true. Indy developers writing the next great Weather app are on a level playing field, but there's no way to design the next great iPod interface* or replace the telephony apps.

For an entirely different reason, there's no way to compete with Apple's iPhone Mail app. Applications can register custom URLs to launch their application. For example, my Flickr viewing app could register "flickr". If a user clicked on the URL "flickr:user123" from another app, my Flickr app would launch and display photos from user123. According to the iPhone OS Programming Guide, URL conflicts between 3rd party apps are undefined: so if two apps register "flickr", there's no guarantee who wins. However, if a 3rd party application tries to register a URL identical to one defined by Apple (like "mail" or "tel"), the Apple-provided application always wins. Here's hoping the rumors are right about Apple improving the Mail app, since there's no getting rid of it.

* Technically you could design a new iPod app with all the media enclosed in its sandbox, but without iTunes integration you'd be DOA.

The Controversial
The iPhone SDK's first big, public firestorm arose over AppStore and Apple's cut. Native iPhone applications can only be distributed by Apple, and they take 30% of the revenue for their efforts. I'm reserving judgment on this one: when John Siracusa and John Carmack take opposing sides of an issue, I'll wait on the sidelines to see how it plays out.

However, my immediate concern with AppStore is not with the 30% cut, but with the iPhone Developer Program. In order to deploy and test an application on an iPhone, you have to become a member of the iPhone Developer Program and pay $99. Like the thousands of developers hammering the ADC site on Thursday, I signed up for the program and gladly offered to pay. But alas, I just got a message thanking me for my application and promising to get back to me in the future. The fine print says the program "will initially be available to a limited number of developers in the U.S. and will expand to other countries in the coming months." Until my membership gets approved, I can only test my iPhone applications via the software emulator, not on my actual iPhone. I'm sure they're deluged with applications and I don't mind waiting in line with everyone else, but I hope it gets processed in weeks, not months. Please Apple, take my money! (They're usually so good at that...)

As we get closer to the official SDK launch in June, it will be interesting to see how long it takes from developer submission to AppStore appearance. What will the screening and approval process be like? When Microsoft started the XBox Arcade service, they were deluged with ideas and submissions from independent developers. It took them months to work through the backlog, with the bigger companies usually getting preferred treatment. I anticipate a similar deluge from indy iPhone developers, and I hope Apple has the resources to handle it when June rolls around. If not, expect another round of controversy

The Apple Polish
Setting aside these concerns, I'm very impressed by the iPhone SDK. It builds on the strong foundation of OS X, while integrating with the multi-touch and mobile capabilities of the iPhone. You can tell a great deal of work went into preserving the Mac experience on a device lacking in memory & computing horsepower.

My favorite nugget is that developers can include an application launch image in their distribution. Quoting from the programming guide, this image "should closely resemble the application’s initial user interface; the system displays the launch image before an application is ready to display its user interface, giving the impression of a quick launch." Even when it's computationally impossible, Apple found a way to make apps feel snappy.

Labels: Apple, Cocoa, iPhone, Leopard, Mac

posted by Adam Houghton / Permanent Link

Comments:

You imply that Siracusa and Carmack disagree. I would say the Carmack post is clearly pro-iPhone SDK, not con. Why do you think they disagree?

# posted by

Ken Mankoff : March 9, 2008 8:44 PM

Siracusa & Carmack are definitely both pro-iPhone SDK. My comment was in reference to the AppStore as the only distribution model, and Apple taking a 30% cut of developer revenue as the gatekeeper. Carmack likes that model: "a 70% royalty deal for apps over iTunes is quite good" and "the iTunes distribution model is really a more important aspect than a lot of people understand."

Siracusa sounds a much more cautionary note about AppStore and Apple following the closed garden model of the game console business. His "initial indication is to agree wholeheartedly" with the BusinessWeek pundit who criticized the model. Although he thinks it could be an initial win for developers, he brings up the short life expectancy of indy game companies and asks developers to look 5 years down the line and what type of environment it'll be. I wouldn't say Siracusa is anti-AppStore, as he thinks it's a good way to jump-start the market today, but he definitely brings up some valid points of concern about the long-term effects of the model on small developers.

# posted by

Adam Houghton : March 9, 2008 10:50 PM