When Apple announced the iPhone, there were no provisions whatsoever for third party applications. If you wanted to use the iPhone, you used Apple’s applications. People (myself included) went nuts over it, and Apple responded by telling developers to write Web apps.
Many people strongly suspected that Apple had plans for more than that from the beginning, but nobody really knew what those plans were or when they would be announced. Last October, Apple promised to announce support iPhone-native applications in February, and yesterday we saw what the landscape for those applications would look like.
In terms of ease of development and ease of deployment, the iPhone looks great. The development tools are free to use, and it only costs $99 to register as an iPhone developer, which enables you to distribute your applications through the store application that will be installed on every iPhone as of June. The catch is that there are a number of restrictions on what developers are allowed to do, and that deployment to the iPhone is tightly controlled by Apple. The only way to get your app onto the phone is with iTunes or the phone’s store application, and you have to pay Apple 30% of your licensing fee for the privilege.
It’s the classic walled garden scenario. Apple’s garden looks very nice, but they are intent on remaining the sole gatekeepers when it comes to controlling the iPhone (and iPod Touch). Clearly Apple still has not surrendered to the idea that iPhone is a general purpose computing device that users can tinker with as they wish.
John Siracusa has some interesting musings on whether this walled garden approach can really work, and on what the implications are for independent developers. As he points out, the trend in the computer industry and the mobile device industry is toward open platforms, and you have to wonder successful Apple can be resisting that trend.
Will Apple’s strategy still work five years from now, if Android takes off among handset providers and independent developers? I doubt that Apple is willing to find out. It’s a lot easier to surrender control than it is to reassert control once surrendered. It seems to me that Apple is being very conservative with the iPhone, but at the same time, that they’re listening to customers and relinquishing control at their own pace. At the same time, they have people doing massive amounts of market research for them by jailbreaking and augmenting their phones. I’m certain that the team working on the iPhone SDK was keeping track of what the pain points were for the people writing unauthorized software when they were designing the SDK.
I think it’s a mistake to assume that the business model for iPhone developers will be the same two years from now as it will be in June when iPhone 2.0 launches, and I think it’s a mistake to assume that the API restrictions imposed on developers then will be the same as they are now, as well. Smart analysts will be trying to figure out why Apple is imposing those restrictions. Once they’ve cracked that case, they’ll probably have a good idea of what has to happen for those restrictions to be lifted.
The physics of control
When Apple announced the iPhone, there were no provisions whatsoever for third party applications. If you wanted to use the iPhone, you used Apple’s applications. People (myself included) went nuts over it, and Apple responded by telling developers to write Web apps.
Many people strongly suspected that Apple had plans for more than that from the beginning, but nobody really knew what those plans were or when they would be announced. Last October, Apple promised to announce support iPhone-native applications in February, and yesterday we saw what the landscape for those applications would look like.
In terms of ease of development and ease of deployment, the iPhone looks great. The development tools are free to use, and it only costs $99 to register as an iPhone developer, which enables you to distribute your applications through the store application that will be installed on every iPhone as of June. The catch is that there are a number of restrictions on what developers are allowed to do, and that deployment to the iPhone is tightly controlled by Apple. The only way to get your app onto the phone is with iTunes or the phone’s store application, and you have to pay Apple 30% of your licensing fee for the privilege.
It’s the classic walled garden scenario. Apple’s garden looks very nice, but they are intent on remaining the sole gatekeepers when it comes to controlling the iPhone (and iPod Touch). Clearly Apple still has not surrendered to the idea that iPhone is a general purpose computing device that users can tinker with as they wish.
John Siracusa has some interesting musings on whether this walled garden approach can really work, and on what the implications are for independent developers. As he points out, the trend in the computer industry and the mobile device industry is toward open platforms, and you have to wonder successful Apple can be resisting that trend.
Will Apple’s strategy still work five years from now, if Android takes off among handset providers and independent developers? I doubt that Apple is willing to find out. It’s a lot easier to surrender control than it is to reassert control once surrendered. It seems to me that Apple is being very conservative with the iPhone, but at the same time, that they’re listening to customers and relinquishing control at their own pace. At the same time, they have people doing massive amounts of market research for them by jailbreaking and augmenting their phones. I’m certain that the team working on the iPhone SDK was keeping track of what the pain points were for the people writing unauthorized software when they were designing the SDK.
I think it’s a mistake to assume that the business model for iPhone developers will be the same two years from now as it will be in June when iPhone 2.0 launches, and I think it’s a mistake to assume that the API restrictions imposed on developers then will be the same as they are now, as well. Smart analysts will be trying to figure out why Apple is imposing those restrictions. Once they’ve cracked that case, they’ll probably have a good idea of what has to happen for those restrictions to be lifted.