gavinshearer.com

« A New Vision For The Fun Forest | Main | Are The Storm Staying? »

December 21, 2007

Birth Of A Platform

Welcome to late December! Work is winding down for the year, holiday parties are being thrown, shoppers are scurrying around the malls looking for a Wii. And, for the Mac community, this is the usual time of year to pause, reflect, and begin making predictions about what will be announced at Macworld San Francisco in January.

This isn't my Macworld prediction post (I'll get to that after the holiday), but I did want to take a bit to reflect on the forthcoming iPhone software development kit (SDK).

This SDK is critically important to Apple; getting it right will transform the iPhone (and iPod Touch) from a fantastic piece of consumer electronics into a bona-fide platform, the kind of place where consumers can get a particular software itch scratched, developers can build a business, and everyone makes money. If done correctly, the iPhone SDK will become a huge strategic asset for Apple, driving sales and ancillary revenue, boosting customer satisfaction, and helping Apple ward off competing mobile platforms.

So ... what will it look like?

First, a disclaimer: while I work for Microsoft's Mac team, none of what I'm writing in here has been informed by any inside information, and certainly nothing is covered by NDA. I don't know anything special. This post is fueled by being a Gruber-reading, MacBreak Weekly-listening, Apple guy from way back in the day.

Set the wayback machine for June: roughly 15 nanoseconds after the iPhone was launched, developers were trying to crack it open and figure out how to write native applications for it. This was fiendishly difficult work, both because a) Apple wasn't supplying any documentation on how to do this, and b) Apple was going out of their way to stop people from doing it. A game of cat-and-mouse evolved - developers would find a way to crack the phone, and, once they did, Apple would release a software update to prevent their break-in from working.

Finally, in October, Steve Jobs announced that Apple would be supplying a native SDK for the iPhone in February 2008. This served two purposes - first, it took a lot of the fight out of the hacker community to keep finding new-and-novel ways of breaking in to the iPhone (I mean, what's the point? Just wait for early '08), and second, it bought Apple the time it needed to get the SDK finished and out the door.

One question on people's minds was, "why February?" I mean, it's clear that Apple has an SDK for the iPhone - otherwise, they'd never be able to create Mail, Mobile Safari, or any of the rest of the applications that come on the silly thing. Why not just make that available?

My bet is that these new, third-party iPhone applications will only work on a new version of the iPhone operating system - call it v1.5 - which will be based on Leopard. And while v1.5 wasn't ready in October, it will be by February.

Why Leopard? Well, aside from the obvious advantage of synchronizing the versions of OS X in the iPhone and on the Mac, Leopard has a number of new technologies that are great for your desktop iMac, but fantastic for mobile applications. Specifically, I expect that all iPhone applications will make use of:

• Garbage-collected Objective-C. Apple added garbage collection to their flagship development language, which is good in two ways. First, it makes it easier for developers to write code (there's one less thing to manage or worry about). And second, it reduces the likelihood that a given application will have a memory leak. Memory leaks are never good, but they're deadly on a small device like a phone, which is both resource-constrained (less RAM) and designed to never be turned off. Requiring the use of Objective-C 2.0 will mean that the iPhone - and its applications - run more reliably.
• Code signing. Code signing allows iPhone applications to be "tied" back to a particular developer or company, which gives users (and other parties) an audit/accountability trail if an application does something malicious or bad. I expect that the iPhone will require all its applications to be signed; if your application isn't signed by an authority Apple recognizes, it won't run. Again, this protects the overall iPhone experience by dramatically reducing the attack vector for malware, trojan horses, and the like.
• Sandboxing. Sandboxing is a security technique that prevents your application from doing certain things on the operating system - writing files to the disk, say, or talking to the network. In Leopard, certain Apple services and applications (Bonjour, Safari, Spotlight) are sandboxed to prevent them from compromising the rest of the system. I expect that any third-party iPhone application will also be sandboxed - developers won't be able to access the phone internals, willy-nilly, but will instead be given access to certain services and systems - and nothing else. (In this regard, it won't be too unlike Java.) Protects the system, protects user data, prevents bad things from happening.
• Core Animation. The iPhone user experience is nothing if not gratuitously flashy - this zooms, that bounces, this other thing shimmers. People love it - it's fast, it's fluid, it's fantastic. Historically, Apple has provided this kind of eye candy in its own products by employing an army of graphic artists and OpenGL gurus; in Leopard, you can simply add a few lines of code your application and the OS will make the flashy animations happen for you. It's very cool stuff, but critical for a nascent platform like the iPhone that's trying to develop its own visual language. (I mean, could you imagine an iPhone application that didn't feel as ooey-gooey fluid as the built-in stuff? Ick.)

What this means as well is that iPhone applications will be Cocoa applications. No Carbon (and certainly no Classic), no Java, no Python or PHP.

OK, so now we know how these applications will be built - the next question is, how do users get to them? Will this be like the Mac shareware market, where people just offer downloads off their Web sites? Or will this be classic commercial software, sold in a box through Amazon or the local Apple Store?

The short answer, I think, is iTunes.

Today, people get a ton of content for their phones or iPods by going to the iTunes Store. You can get music and movies, as well as podcasts, TV shows, and iPod games. And, I suspect, when Jane Developer wants to put her newly-created Widget 1.0 for iPhone in the market, she'll do so much like she would with a podcast - she'll park it on a Web server somewhere, fill out a form on the Apple site, and, within a short period of time, the product will appear in the iTunes Store for purchase. Like podcasts, Jane Developer will be able to pick a handful of categories that apply to her app ("Games", "Productivity", "Utility", etc.), write some marketing text, have a cool icon. Like everything in the iTunes Store, users will be able to rate Widget 1.0 and leave feedback for others to see. And the whole transaction will take place in the iTunes environment, with Apple collecting a cut of the proceeds.

For users, this is about the slickest thing ever. It extends the iPod shopping metaphor they're used to, and lets them use their current payment preferences (via their Apple ID) to just ... buy more stuff. I'd even wager that iTunes gift cards will be applicable toward third-party software, as well.

If I'm right about this, there's a lot of goodness here for prospective iPhone developers. Because the phone is based on OS X, they get a modern, object-oriented codebase, a lot of world-class system services and features, and a high-quality desktop development environment. They also get a simple hardware target (for today, at least, the iPhone is the iPhone is the iPhone), which dramatically reduces the complexity of testing. Small developers will love the fact that iTunes handles marketing, payment, distribution and installation.

In fact, this approach neatly solves a lot of long-standing problems in the mobile phone market.

Consider the plight of a smartphone developer today. Let's say Jane Developer wants to write Widget 1.0 for Symbian or Windows Mobile - great. Here's her problem - her prospective user base is highly fragmented:

• Some (most!) phones have a traditional 12-key keypad; others have full keyboards.
• Some phones have touchscreens; others will not.
• Some phones have WiFi or Bluetooth; others don't.
• Some phones have data plans associated with them; many do not.
• Some phones have cameras. Some have video cameras. Some have neither.

And so on. Now layer on a little more complexity - different installation techniques for phones. Some carriers (such as AT&T) want you to buy software "over the air" from them (paying data fees, of course) and install it in your phone that way. Others might want you to download programs off the Web (hello, Palm!) and "sideload" the installation.

And so Jane, poor developer that she is, is stuck writing lowest-common-denominator products for the widest possible audience, or is going to have to pick a relatively scoped market (e.g., PalmOS machines with color screens) for a higher-end application.

Marketing Jane's software might be difficult, too - she's got to build herself a Web site, come up with a payment-processing system, and then fight to get the attention of prospective buyers by using search-engine optimization techniques, buying AdSense ads, or both.

In short: being a small software developer is hard; being a small software developer for a mobile platform is hellish.

The iPhone turns a lot of this on its head.

In many ways, the business model for iPhone development has more in common with video game consoles - the XBox 360, PlayStation 3, or Wii - than it does with the traditional PC. For developers, the value proposition of a game console is simplicity - an Xbox 360 is an Xbox 360 is an Xbox 360. Each 360 has the same processor, the same video card, the same amount of memory. If you can write a game for one 360, it'll run on all of 'em. And because developers know what kind of hardware their prospective customers are working with, they can push it - really make the most of the platform they're on. It's one reason that second-gen video games for a given platform always look so much better than first-gen games - the developers have figured out how to tweak and push the hardware in new ways, get more out of it.

The iPhone is very much like this. Every iPhone has a fantastic color screen, WiFi, Bluetooth, a data plan, 8 GB of memory, a camera, and is linked to a PC or Mac with great desktop software called iTunes. This means that developers will go crazy making the most of this hardware/software combination, pushing the phone to do things that other phones simply can't do - or, at least, can't do in sufficient numbers to be interesting, market-wise, especially when the iPhone is already outselling all Windows Mobile devices combined.

(And yes, future iPhones will undoubtedly bring more capabilities - more storage, 3G data connections, etc. - but I believe the basic form factor is unlikely to change for quite some time.)

In short - the iPhone platform is going to bring the trifecta of 1) a stable, known hardware platform, 2) desktop-class development tools and technologies, and 3) dead-bang easy software marketing, distribution and installation to a fragmented market. And, I predict, it will be the dominant mobile development platform in less than 24 months.

I certainly wouldn't want to be Palm or Nokia right about now.

On a final note, I'm intensely curious to see what the success of the iPhone platform will mean for Mac users. Apple has stated that they plan to sell 10M iPhones by the end of 2008; based on current sales trajectories, I see no reason they won't hit it. That represents roughly 10% of the 100M-unit smartphone market; as Apple attempts to convert the majority of their 110M+ iPod customers to iPhone customers, it's eminently reasonable to assume they'll have 30M phones in circulation by the end of 2010.

Read that again: 30M phones. As a point of contrast, that's roughly the size of the Mac installed base (!).

Remember that iPhone developers are actually OS X developers, and remember that iPhone developers are using many of the same tools and APIs that you would use to develop for the Mac. Suddenly, as the iPhone attracts talented developers, many of those developers will find themselves with a lot of knowledge about how to create great Mac applications, too.

I predict that the iPhone developer community will be a steroid for Mac development in general, and we are going to have a flood of new Mac applications hitting the market after the next year or two. New products, new ideas, new companies - all made possible because the delta between iPhone development and Mac development is much smaller than, say, the delta between Palm development and writing for Windows. (And, if you're a Mac rock star like Cabel Sasser or Wil Shipley, the iPhone is a win-the-lottery kind of new-market opportunity.)

This flood of Mac apps isn't the point of the iPhone; rather, it's the spoils of victory. If Apple really manages to harmonize its developer story across its devices and desktops, really manages to crack the marketing, distribution and commerce problems, and really delivers a viable, vibrant market by selling the hell out of its product - then they've got it.

One way or the other, it'll be fascinating to watch.

(And frankly, I think they're going to pull it off.)

Posted by Gavin Shearer at December 21, 2007 11:21 AM. Posted to Apple.

Trackback Pings

TrackBack URL for this entry:
http://www.gavinshearer.com/weblog/mt-tb.cgi/138

Comments

Posted by: purple at January 1, 2008 9:56 AM

Post a comment

« A New Vision For The Fun Forest | Main | Are The Storm Staying? »