Well, Apple made for a lively Thursday this week by announcing the software roadmap (although not the hardware roadmap) for the iPhone. There was a lot to take in, and it took forever to download the SDK (ok, in reality, it took only a few hours, but Apple clearly wasn't prepared for the demand), but I now have some initial impressions on what I've seen and played with and what the announcements appear to hold in store.

There has been a lot of positive and negative feedback about Apple's announcements this week. Not surprisingly (considering I'm considered a bit of an Apple fanboy amongst my friends), I'm pretty happy with what I've seen, on balance. There are some interesting choices and some interesting opportunities, but as it stands, it looks like Apple's well positioned to shake things up on the iPhone.

Distribution

A lot of discussion has focussed on Apple's distribution mechanisms for applications on the iPhone. For those not watching the lengthy Apple SDK event, the summary is that distribution of applications will be by an Apple-run AppStore that serves up free and paid-for applications with Apple providing payment processing, hosting, and some minor marketing (top seller lists, reviews, etc), in exchange for 30% of the price the developer sets for the application.

On phones running stock iPhone OS (in other words, ones that haven't been jailbroken), only applications delivered this way will run on the phone. It remains to be seen what kind of restrictions Apple will actually place on the distribution of applications and what kind of testing they will do. However, the use of cryptographically signed binaries where the certificate comes from Apple leaves open a very, very interesting prospect...

Revocation

I haven't seen anyone else talk about this, but one of the first things to cross my mind was that in a ecosystem where Apple controls the certificates, they also control what is called the CRL (Certificate Revocation List). The CRL is used in certificate systems to disable certificates that have already been put into service if they are believed to be compromised. As such, it appears that Apple will be able to retroactively stop installed programs from running on any iPhone anywhere in the world. Now, the current Registered iPhone Developer Terms and Conditions do not explicitly discuss anything about the certificates, but if I were Apple, I'd be seriously considering using this as a key way to remove abusive programs. If you assume that most developers who are willing to put up the token $99 are actually representative of "real" people (as opposed to bad actors using credit cards absconded with via botnets), and you assume that they're mostly good folks, you can default to a very permissive architecture. Especially if you have the ability to turn off malicious code once it's on the computer... ahem, iPhone.

Now, this is total speculation on my part, but not only does it provide a deadman switch for malicious code that makes it through the developer-vetting process, but it also provides a rather large stick against developers who stray from the license agreement. You see, we don't know if there are going to be separate certificates for each application, or for each developer, but if I were designing this system, I would create separate certs for each developer for them to use explicitly for testing (these would be allowed to run on the developer's iPhone only and each iPhone could only have one of these certs installed on it at a time), and for published material, I would issue a separate certificate for each application. If a developer acts up, just revoke each of their applications and you suddenly have a bunch of annoyed users with much safer phones.

Clearly, this is a bit of a threat to development if it's not handled well, but it's certainly a faster way to get content onto the phone than requiring that each application be tested and vetted by Apple. Also, it's good to note that this is a pretty lightweight way for Apple to allow thousands of applications... since the CRL only contains the ids of the certificates that have been revoked, and thus can maintain a very small size assuming there aren't a lot of malicious applications out there.

Enough of my rampant speculation about Apple's certificate structure, but one last note to think about on the Registered iPhone Developer Program.... when you sign up (which, by the way, explicitly allows parents to sign up for children that are 13 and older), they apparently do some kind of qualification process, as it is not an immediate approval and the sign-up process indicates that they will be performing some kind of vetting with an outside agency.

The SDK itself

Contrary to the "surprise" in some circles about the developer kit being Macintosh-host-only, there was really little surprising about the SDK. Apple continues to push Cocoa (a C-derived, object-oriented system) for development, this time with "Cocoa Touch", the branded system for the iPhone and iPod Touch. The development system is XCode (hence the Mac-only requirement). It is, also not surprisingly, free. This is in contrast to Microsoft, which also doesn't offer a Macintosh- based development kit for Windows Mobile (and I'm not surprised about that nearly as much as people seem surprised that Apple's not offering one for the iPhone on Windows), but developing for Mobile requires Microsoft Visual Studio which costs at least $299, although preferably $799 for the Pro version, and that's not counting the subscription to their developer program (Apple's is free).

There were two surprising bits about the SDK announcement for me. Neither was shocking in retrospect, but both are really nice for developers: the iPhone Simulator, which provides you with a way to test your applications without having to take your precious iPhone into the danger zone; and the availability of remote debugging an performance tools, providing you a way to monitor and debug your applications either in the simulator or in a real iPhone with relative ease. Of course, Apple's been using these to test their internal applications, so it's not surprising that they made these available internally and now to developers.

Oh, and then there's Interface Builder for the iPhone. A consistent complaint amongst the folks who are doing applications in the unofficial way right now is that they have to deal with programmatically creating all the graphical elements, such as views. Apple has now announced that future versions of the SDK will have access to the Interface Builder application that makes development of Macintosh applications so easy and consistent. I have little doubt that they didn't think this was necessary when they were not making the SDK available to others... if you only have 10 or 12 applications, it hardly seems worth it to create a development team and do testing on a piece of software like that. But, with the world opening up, Apple needs to do this, lest we see a lot of pretty crappy applications for the iPhone.

Enterprise Announcements

Possibly one of the most surprising elements to me was the broad set of announcements for the Enterprise space. It's not clear how dependent some of these are going to be on Microsoft Exchange (for example, the "remote wipe" feature might require an Exchange Server to use), but for big organizations, there's an awful lot of Exchange out there. And, it's also clear that they're aiming directly at RIM (Research In Motion, the Canadian company that completely dominates enterprise telephony and messaging with their line of BlackBerry products). The shots taken by Schiller were clearly aimed at RIM, when he suggested that direct-to-device was much more effective than going through a NOC clearinghouse (a clear reference to multiple, painful outages during this year on RIM's network).

It was interesting to see Apple's adoption of ActiveSync (Microsoft's synchronization platform between Exchange Server, desktop machines, and mobile devices), but neither shocking, nor disturbing. However, I do hope that Apple provides a way to just as easily use OS X Server as the platform of choice. For me, this means supporting push calendar using iCal Server, which right now cannot be used for remote sync at all; address book integration with OS X Server's global address book, and some form of remote wipe administered using OS X Server. All of these should be doable, but I'm guessing that they'll be in a follow-on release, because that would be more about making OS X Server a viable small enterprise platform than it is about making the iPhone a serious enterprise platform.

So, take away what you will, but this is some exciting stuff... now to wait for general availability in June.