The next phase of smartphones

It’s now 7 years since the iPhone reset the phone business, and indeed the entire computing and internet businesses. But it was pretty clear at the time that the first iPhone was an MVP, and Google’s first Android… homage, the HTC G1, was even more so. It feels rather like the last 7 years have been spent adding all the things that really needed to be there to start with, both in hardware and software. For iOS and Android these have come in different orders, since their opening assumptions were very different, but they’ve ended up at much the same place in terms of the user experience and interaction model. There are small differences in how you interact, and there are always things that are on one platform before the other, but the basic user flows are very similar, and almost all the obvious gaps have been filled. 

Along these lines, my colleague Steven Sinofsky makes the point that for any new ‘thing' in computing, at the beginning everyone is doing roughly the same stuff because the stuff you need to add is pretty obvious and undifferentiated - you might deliver different things in different orders but you’ve got basically the same wish list. It’s once you’ve finished building out that stuff that things start to diverge. 

This, I think, is what we started to see at this year’s WWDC and Google IO - the end of the first 7 years and the start of a new phase, with the fundamental characters of Apple and Google asserting themselves. As Jean-Louis Gassée put it, iOS 8 is really iOS 2.0

Hence, WWDC was all about cloud as an enabler of rich native apps, while the most interesting parts of IO were about eroding the difference between apps and websites. In future versions of Android, Chrome tabs and apps appear together in the task list, search results can link directly to content within apps and Chromebooks can run Android apps - it seems that Google is trying to make ‘app versus web’ an irrelevant discussion - all content will act like part of the web, searchable and linkable by Google. Conversely for Apple, a lot of iOS 8 is about removing reasons to use the web at all, pulling more and more of the cloud into apps, while extensions create a bigger rather than smaller gap between what ‘apps’ and ‘web sites’ are, allowing apps to talk to each other and access each others’ cloud services without ever touching the web. 

Unlike the previous differences in philosophy between the platforms, which were mostly (to generalise massively) about method rather than outcome, these, especially as they evolve further over time, point to basic differences in how you do things on the two platforms, and in what it would even mean to do specific tasks on each.The user flows become different. The interaction models become different. I’ve said before that Apple’s approach is about a dumb cloud enabling rich apps while Google’s is about devices as dumb glass that are endpoints of cloud services. That’s going to lead to rather different experiences, and to ever more complex discussions within companies as to what sort of features they create across the two platforms and where they place their priorities. It also changes somewhat the character of the narrative that the generic shift of computing from local devices to the cloud is a structural problem for Apple, since what we mean, exactly, when we say ‘cloud’ on smartphones needs to be unpicked rather more. That's a subject for my next post. 

Meanwhile, this sort of divergence is why I’m a little skeptical about the other two big reveals in the last couple of months: the Fire Phone and Facebook’s mobile announcements at F8. Facebook is trying to build essential plumbing to connect the web and apps together, in particular with its deep linking project. But this is like building the plumbing for a building that’s still going up, and where you don’t know what it's going to look like. Making tools to connect apps and the web together when Apple and Google are shifting the definitions of those terms is going to be challenging. 

Amazon has a bigger problem. Most obviously, more and more of what it means to be ‘Android’ will come from the closed Google services that aren't part of AOSP and that it doesn’t have access to. If Amazon wants to free-ride on the Android app ecosystem, it will need to spend more and more time replicating the Google Android APIs that the apps it wants are using, or the apps just won’t work - presuming that Amazon even has the sorts of search-led assets to do that. But more fundamentally, AOSP is being pulled along by Google’s aims, and will change in radical and unexpected ways. This isn’t like building on Linux - it could be more like taking a fork of DOS just before Windows 3.1 came out. Are we quite sure (to speculate wildly for rhetorical effect) that we won’t be running Android apps in a sandbox on our ChromeOS phones in 5 years? Where would that leave Amazon’s fork? AOSP is not necessarily a neutral, transparent platform for Amazon to build on.