Slightly longer version of a tweet from this morning:
Apple makes the iPhone SDK. They’re also one of (if not the) biggest contributors to WebKit.
WebKit’s capabilities continue to grow exponentially. I’m blown away by what can be done with it today. If development continues apace (and there’s no reason to believe it won’t) it seems realistic that within a reasonable amount of time it will be possible to create web apps that feel exactly like native iPhone apps.
All Apple would have to do to close the loop completely is expose a few extra things to WebKit via JavaScript. And therein lies my question.
Apple makes money from the iPhone developer program, and the sale of iPhone apps. They do not make money from WebKit apps.
As the major benefactor to both the iPhone and WebKit, does this present a conflict of interest within Apple?
To put it another way, if WebKit begins to present a serious threat of undermining the app store ecosystem, it appears to be in Apple’s financial interest to hobble WebKit development. What would you do if you were Apple?
The way the AppStore works as compared to webapps for paid applications means that it often makes more sense to sell an application on the AppStore than to try to concoct a payment scheme which achieves the same thing on the web.
I suspect the AppStore only makes sense from a financial perspective in its own right for reasonable-volume apps where Apple takes a 30% cut of something. All of those free apps are, essentially, costing Apple money. The free apps with subscription services attached are, in a way, even worse—not only do they cost Apple money, but the developer still sees direct revenues.
The overheads of running the AppStore, along with the infrastructure associated with it (including, for example, the public SDK documentation) can’t be particularly insignificant, and it’s not at all clear that $99/year/developer approaches break-even. On that basis, it makes sense for Apple to actively encourage webapps for those things which it wouldn’t make any money on. In a happy coincidence, the kinds of things which are easily implemented as webapps are the kinds of things Apple tends not to make any money on.
If, at some point in the future, webapp developers got together and produced a system for webapp purchase which worked in a similar fashion to AppStore (with comparable levels of convenience for the user), then Apple might start to get worried. Similarly, if significant numbers of applications which could be sold as one-off-purchases on the AppStore moved to a subscription webapp model, Apple would have cause for concern, but neither appears to be on the immediate horizon.
It’s also worth bearing in mind that webapps are to an extent “open source” (in the strictest sense), and some developers aren’t happy about people being able to easily poke too deeply into the innards of their application, which is another win for the AppStore. Although there are a minority of users who hack around with AppStore apps, for the vast majority of iPhone OS users, it’s just far too much hassle for very little gain.
Webapps show a lot of promise on the platform—and on others, too (which is potentially a point in their favour for a well-structured client/server app). I maintain that the biggest factor preventing developers from producing native-feeling web-based applications for the iPhone isn’t the state of WebKit so much as skill and knowledge: not only do you need to be well-versed in HTML, CSS, JavaScript (and the latest HTML5 features), but you also need to have a good eye for the iPhone UI. Effectively, you have to reverse-engineer many of the commonly-used UI components to ensure consistent behaviour.
It’s certainly true that Apple could make this easier—some additional special CSS constructs for common iPhone UI elements, for example—but it’s not absolutely necessary.
Either way, I think the future’s bright for webapps for foreseeable future. A lot of models would have to change before it becomes anything but a benefit for Apple to support.
