The general reaction to Amazon's Fire Phone has been a puzzled shrug. It's a good but unexceptional device with entirely conventional high-end and high-margin pricing - a move as out of character for Amazon as the purchase of Beats was for Apple (and probably driven in part by the way the US pricing structure makes even $400 phones ’free’). There's an interesting quasi-3D UI feature and a big flashing BUY button, in line with Amazon's role as the Sears Roebuck of the 21st century, but little that really changes anything or couldn’t be done on any other smartphone anyway. And that leaves people wondering why Amazon bothered. The most productive line of thought, I think, is to look at Prime, Amazon's whale service, and the role that the Fire Phone plays in securing that relationship.
To me, though, the interesting thing is less the phone than the platform and what it it represents - that is to say, the first real attempt to sell phone that forks Android outside China*.
Android itself is open source, and anyone is free to take the code (AOSP) and build whatever they want. Android is the new Linux, in this sense. But AOSP doesn't give you Google's own smartphone apps and it doesn’t give you all the system services Google has built. So if you make an Android device without reference to Google, and change a bunch of things ('fork Android') your device won’t have the app store and the maps, and it won’t have the Google services APIs that lots of third-party apps need, most obviously push notifications, in-app payments, location and embedded maps. There are lots of other things Google makes as well, but those are both the important and the hard parts.
Without this Google layer you really only have a featurephone, and to get Google's layer you need to submit to Google's control over what you make, which amongst other things means that you have to use Google's interface and you have to take the whole package - whatever Google wants on the phone goes on the phone. (The core mechanic here is that you have to pass the compatibility test). Hence, Google uses access to its apps and services as a lever to control Android. This is pretty similar to the way that Microsoft used Office and Windows: selling an Android phone without Google's services is like selling a Windows PC that doesn't have Office and can't run it.
In China all of this works differently. Google services are either blocked or weak or both (the Chinese unaccountably didn't let Google send its mapping cars down every road in the country), while the Chinese internet giants Baidu, Alibaba and Tencent ('BAT') and scores of others have built lots of great Android services of their own. So the vast majority of Android phones sold in China (even from Samsung or Motorola) come with no Google apps and integrate these instead.
Outside China, though, if you want to use Android as a platform but do something different, you need to build or buy those core functions yourself, and that’s what Amazon has tried to do. It has licensed Nokia’s HERE mapping platform, it has built an app store for Android, and it has built its own versions of the key enabling APIS - location, push notifications etc.
The problem is that the maps and the app store are not commodities. Adding them is not just a matter of spending the money. Google's Maps platform is very good and HERE, at least in western markets, is not as good. As with Apple Maps, it works, mostly, but the gap is clear and there is no roadmap that points to that gap closing. For apps, though an app store itself is perhaps a commodity, Amazon has only persuaded a minority of Android developers to load their apps into its store, partly since this means they have to swap out Google’s APIs (for maps etc) for Amazon’s, and that is not necessarily trivial. Amazon has done just about as good a job as one could expect anyone to do at this stage, and there are very few other companies that could get this far - perhaps only Microsoft. But it hasn’t, remotely, reached parity with Google.
And so Amazon is testing the proposition that you have to have Play (or iTunes) and Google Maps to sell a smartphone outside China - or, rather, it is testing just how good the app store and maps have to be. How many of the latest cutting-edge apps do you have to have, if you cover the basics? How close do you have to get to Google Maps’ coverage? We know Windows Phone does not have enough apps, but can the Amazon store get there?
These same questions apply to any Android OEM that might be thinking of asserting greater independence from Google (such as Samsung), with a further complication. Google’s agreements with OEMs have been leaked several times, and they include clauses that prevent you from having a foot in both camps: you cannot sell a forked device and carry on selling official Google Android devices. So you can’t experiment on the margins (Samsung can't sell a phone running Amazon's Fire software) - you have to walk away from Google entirely, or not at all. That's really no choice at all at the moment.
All of this takes us to the elemental question - why, exactly, are you forking Android? What important problem do you solve that’s worth reinventing the wheel, while taking on the risk of building on someone else’s platform, open-source or not? Why are you asking people to buy a phone with second-rate maps and a second-rate app store? Are you offering them something you couldn’t otherwise do in return, or just addressing your own strategic concerns? Are you solving a user problem or your own problem?
Both Xiaomi and Cyanogenmod (an a16z portfolio company) have built their own very custom versions of Android that do none the less pass the compatibility test. And though Xiaomi differentiates on software, Xiaomi phones outside of China ship with Google Apps. Hugo Barra called it 'a compatible fork'. After all, it’s not as though you’re not allowed to change Android at all. Google describes the compatibility test as follows:
"Enable device manufacturers to differentiate while being compatible. The Android compatibility program focuses on the aspects of Android relevant to running third-party applications, which allows device manufacturers the flexibility to create unique devices that are nonetheless compatible."
Generally, Android OEMs have been no better at differentiating on software than were PC OEMs, even though Google allows you to change more than Microsoft did. But it doesn’t follow that you can’t make Android visibly better without forking it if you bring the right skills and culture - Xiaomi and Cyanogenmod (and a number of other Chinese companies) show that.
Hence, it seems to me that the forking question really flows not from a specific feature that you want to implement but the fundamental principle of controlling your destiny - you want a platform that’s 'yours'.
That is, a central strategic problem for both Amazon and Facebook, amongst others, is that their businesses have moved from the essentially neutral platform of the web browser, where there has been no real change in the user interaction model in 20 years, to the much messier, mediated and fast-changing platform of smartphones, where the web is just one icon and platform owners are continually adding new ways for users to discover and engage with content, such as iBeacon or Google Now. They didn’t need to make browsers because browsers had become transparent commodities, but smartphones aren’t. This of course is why Google itself made (or rather bought) Android - to make sure that it would not be shut out in this new environment. Making an entire new OS is not an sensible option for Amazon or Facebook at this stage, but building on top of a free, open-source one is worth at least thinking about. But, again, in doing that you need to solve the users' problems, not just your own.
Facebook is also poking away at this issue (such as with the abortive Home), but as Mark Zuckerberg pointed out, even a really successful Facebook Phone would only be used by 5% or 10% of Facebook’s users, so would really just be a distraction. Instead, faced with a very different set of competitive dynamics on mobile, Facebook is exploring the unbundling of its product with a 'constellation' of different apps. That is, Facebook is embracing this new and more complex environment. With the Fire Phone Amazon is going the other way - greater bundling rather than less.
I do wonder what might appear if Facebook's strategy was applied to Amazon's product - if there were half-a-dozen different interesting and useful Amazon apps for finding and buying products. But Amazon has never been a user experience company in that sense - it thinks about user experience the way Fedex does, as something to focus on ruthlessly, but not as a playground for new experiences. That means it's going to be very interesting to see how it can enchant and delight people who buy its phone.
*Note: when I wrote this on a Sunday evening the fact that Nokia (and hence now Microsoft) has been selling a forked Android phone for the last 6 months passed completely out of my mind, even though I played with one at MWC and rather liked it. It's done rather well in emerging markets, apparently, and is on sale in parts of Europe) but isn't even for sale in the USA. The main driver is that Windows Phone doesn't fit well into the hardware required of that price. The points in the blog post all remain, though.
The Reuters Institute for the Study of Journalism has a fascinating report out looking into how people consume news on digital devices. Lots of data to ponder, but I posted these charts as the most immediately interesting. Click to zoom.
I’ve spent the last couple of days sifting through the announcements at WWDC. Apple claims 4000 new APIs, and it certainly feels like it. Apple has been busy. But setting aside all the normal incremental improvements, there are a couple of interesting strands.
First, Apple is continuing the steady process of removing restrictions on what developers can do - but doing so in a very specific way. Almost all of these restrictions are necessarily trade-offs - on a smartphone more flexibility is ipso facto less security and less battery life. So multi-tasking was permitted only once Apple had created a way to do it while preserving control. The same now comes with Extensions. Apple has a model to allow apps to connect to each other and add functionality to other apps - but with clearly defined attach points and a clear control model. Like multitasking, the idea is to gain most benefits of being open while preserving most benefits of being closed. Rather than giving any app system access, you open up specific use cases - a new keyboard, for example, while controlling it tightly (no network access for that keyboard without permission) and dismissing other use cases entirely (no third party SMS apps). The same applies to the fingerprint scanner - apps can now ask for authentication but don’t get the print data - they only get a ‘yes/no’ response back from the system. It’s sandboxes all the way down. In addition, Apple is backing off the ‘no documents’ rule, which seems to have been a vision of a simpler and easier to use approach that was just too forward-thinking. Hence Cloud Drive, which is amongst other things an argument that DropBox really is just a feature (and in the new MacOS there are APIs specifically for file syncing services, addressing some of the heavy lifting OS hacking that Dropbox or Box have had to build themselves). The practical effect of these moves is that a lot of the specific use cases that might draw high-end users to Android (custom keyboards, say) get sliced off.
The second theme, and a very interesting one, is cloud, the big Apple weakness. The whole of WWDC is full of cloud. A very large proportion of the new user-facing features touch the cloud in some way, as a conduit or as storage. And the ones that don’t use what you might call the personal cloud - the Bluetooth LE/Wifi mesh around you (such as HealthKit or HomeKit). So edit a photo and the edits are on all your devices, run out of room and your photos stay on the cloud but all but the previews are cleared off your phone, tap a phone number on a web page on your Mac and your phone dials it. But none of this says ‘CLOUD™’ and none of it is done in a web browser. Web browsers are for web pages, not for apps. Hence one could suggest that Apple loves the cloud, just not the web (or, not URLs). This is obviously a contrast with Google, which has pretty much the opposite approach. For Google, devices are dumb glass and the intelligence is in the cloud, but for Apple the cloud is just dumb storage and the device is the place for intelligence. And it’s built a whole new set of APIs, CloudKit, to enable this for developers, which it is (for the first time, I believe) dogfooding, building the photos product on it.
There’s a release cycle question in here. A phone that’s refreshed every year or replaced every two can iterate and innovate much faster than a TV, car (or fridge, or, perhaps thermostat) that may be replaced only every five or ten years. So it seems like the place for the intelligence should be in the phone rather than the TV. But the extension of this is that a cloud product can iterate every day. This is the killer advantage of enterprise SaaS over on-premises software - you can improve things all the time. And Apple updates its OS once a year and, so far, the same is true for the cloud products it builds for developers, where Google can update all of its products every week.
You can see this dynamic clearly in smartphones: for the last couple of years, Apple has done an annual release (of both hardware and software) and taken the lead for 6-9m months, and then Android (Google and the OEMs collectively) catches up and overtakes for 3-6 months until the the next Apple release. It’s a game of leapfrog. Is this a disadvantage for Apple? Again, there’s a tradeoff, embodied in Facebook’s old internal slogan, ‘Move fast and break things”. If you’re Google and your products are mostly black boxes to the outside world then iterating fast is fine, but if you have millions of developers building on those APIs, changing things every week isn’t necessarily a great idea. That is, there’s an optimum API refresh frequency. (One could also point out that though Google refreshes Android frequently, the average Android user gets a new version of Android only every two years, when they replace their phone, where the average iOS user gets the new version once a year as it is released).
Going back to this ‘Apple view of the cloud’, though, there’s a deeper and older dynamic starting to come into play now. Apple invented the smartphone as we know it 7 years ago and since then the concept has been built out. All the stuff that really should have been there has been added step by step by both Apple and Google, and the pace at which essential improvements are made is starting to flatten out. But as that happens, the two platforms start to converge. Copy & paste is copy & paste, but iBeacon is a very Apple sort of idea, just as Google Now is a very Google product. That is, as the core features are built out and commoditised, the changes are coming more and more in ways that reflect the very different characters of Apple and Google. I’ve described this before by saying that Apple is moving innovation down the stack into hardware/software integration, where it’s hard for Google to follow, and Google is moving innovation up the stack into cloud-based AI & machine learning services, where it's hard for Apple to follow. This isn’t a tactical ‘this’ll screw those guys’ approach - it reflects the fundamental characters of the two companies. Google thinks about improving UX by reducing page load times, Apple thinks about UX by making it easier to scroll that page.
One effect of this is that it might get harder to make essentially the same app on both platforms. If a core, valuable thing you can do on one platform has no analogue at all on the other, what do you do? Ignore the stuff that isn’t on both, and get a lowest common denominator product? Or dive into those tools, but end up having quite different experiences on iOS and Android? Things like Metal and Swift only accelerate this issue.
Another aspect of this issue is the stuff that Facebook announced at F8, especially deep linking. Facebook would clearly like, on some level, to put together a sort of meta-OS that sits on top of both iOS and Android, driving connections and engagement between apps and acting as a social plumbing layer. But it’s not clear that that’s its place in the stack. Apple’s Extensions offer another and very compelling way to drive people between iOS apps. And in addition, Apple has quietly announced, as part of Cloudkit, its own identity layer. You can sign a user into your app using their iCloud account, and (with permission) use iCloud to see which of their friends are using the same app. And that would use the fingerprint scanner. Looking at the address book is a major driver of growth bethink many social apps on smartphones - Apple is trying to co-opt that, with less friction but also with total user privacy built in. And privacy was a very, very common theme throughout all the developer sessions. You could build an entire multi-player game in Cloudkit, and possibly even a social messaging app. So 'cloud' things become iOS things. But only for iOS.
And yet, on the other hand, all of the new extensions give Google and Facebook new places to embed their services within iOS.
This brings me to the macro point: Everything Apple does is about selling devices. Definitely iOS devices, and possibly an Apple TV or a wearable of its own. But for now, the device is the centre point. And that’s a $600 device. Apple has a lock on the majority of this super-premium segment, with Android’s attempts to break into it plateauing at about a third of the segment. This means that Apple sells about 10% of all the phones on earth and Android takes the next 50% or so, and that gives Apple perhaps a third of run-rate app downloads and the majority of the actual value. This is a now pretty stable situation, unless a premium alternative to Samsung emerges or the subsidy environment changes radically. But the only way for Apple to break out of that segment and sell 20% or 30% of the phones sold on earth is a cheaper phone. Until then the annual leapfrogging with Android will continue.
Apple's Beats deal is a Rorschach Blot: people's reactions slot into their existing view of whether Apple still has 'it'. If you think Apple's lost it, the Beats deal is confirmation. If you don't, it's… perplexing. This is a very out-of character move for Apple (though having everyone puzzled is in character). I've seen plenty of suggestions, but few really convincing rationales that make this company worth $3bn to Apple.
That said, one thing that is clear is that Apple doesn't rule digital music anymore. Streaming and YouTube ended that, along with smartphones. Instead of a library of tracks you’ve bought and paid for, locked to a single platform by proprietary DRM, you can now listen to any track you want on any device you want, and can switch between different music services with little friction. And the iPhone’s multi-touch screen itself broke the iPod’s monopoly on good user experience - now anyone can make a decent music player experience on any device, in code.
Hence, the iPod was a lovely business but it's now pretty much over. Apple has sold 392m iPods since launch (including something over 100m iPod Touches, though) for around $66.6bn, (plus of course the revenue from selling music, which is a more complex issue). There's not much more to come.
This reflects a broader change: content isn't king anymore.
Music has gone from being a key strategic lever in the tech industry to an afterthought. The same applies to movie and TV libraries - media has gone from being a choke-point to a check-box, commodity feature than every platform has to offer but where none has any particular advantage. Books have evolved slightly differently, but with Kindle on any device you might possibly want to read on, books are not a platform lock-in either (except possible for Amazon, but that remains to be seen). So for a platform owner or device maker, the content you can offer is no longer a strategic asset. Content doesn't sell devices, because they all have the same content.
In parallel, of course, the actual value of content - music in particular - is dwarfed by the value of the smartphone explosion. The iPhone alone generated $26bn in revenue last quarter - the entire recorded music industry brought in about $17bn in 2013, and the last three quarters of iPhone sales brought in more hardware revenue than the iPod in its entire history. And though 391m iPods have been sold since 2001, there are over 1.5bn smartphones on earth right now, and close to 300m are sold every quarter.
The amount of money involved, never that large in the context of the consumer technology industry, is such now a small percentage of Apple or Google's revenues that they might almost offer it at cost, just to have the feature. This was one reason why, before the iPhone even launched, Jeff Zucker, then CEO at NBCU, suggested that he should get a cut of iPod hardware revenue. He was mocked in the tech industry but was making a perfectly legitimate point: the money in digital video was in the devices, not the video. At that point the content he was putting on iTunes still gave Apple leverage - not anymore. This is what the people behind Beats Music may have caught on to - the money is in headphones, not the tracks they play.
The one remaining place where content is king, of course, is TV, at least in the key US market. If someone tells you they’re going to disrupt mobile, ask them ‘with what spectrum?’, and if they say they’re going to disrupt TV then ask ‘with what content?’ Here, again, there's no differentiation: every device has the same music, movies and books and doesn't have the same TV.
Hence, the one remaining place for Apple to work its magic is in the TV market. I wrote a post here talking about all the reasons why the US TV market in particular is rigid and also so brittle: there is still scope here for a technology company or other to put together a totally unique offer, with content as the key leverage point. But I'm not sure there's any such scope in music.
My grandfather could probably have told you how many electric motors he owned. There was one in the car, one in the fridge, one in his drill and so on.
My father, when I was a child, might have struggled to list all the motors he owned (how many, exactly, are in a car?) but could have told you how many devices were in the house that had a chip in.
Today, I have no idea how many devices I own with a chip, but I could tell you how many have a network connection. And I doubt my children will know that, in their turn.
At each of these stages, the things that this new technology would be used for were hard to predict, and many would seem absurd. (A little motor in the wing mirror to adjust it for you? Really?) But the trend is inevitable. Sensors and signals and connections in our lives will proliferate in ways we can’t predict, and in ways that would probably seem pointless if described to us. The cost of a network-connected sensor will be tiny (partly driven by the smartphone supply chain) and the battery will last years (and with solar or energy-harvesting it may never need to be charged), so uses will be found that will seem as natural to our grandchildren as a blender (“Really? You can’t chop by yourself?").
So I’m a big believer in the ‘internet of things’ at a macro level. The question is how we get there and what it might look like.
One vision is that, ‘of course’ (always a danger sign), all these devices will work on common, open standards, and talk to each other and interact in clever ways. And so, if you walk into the house with someone your security camera doesn’t recognise and your calendar mentions ‘date', some sort of unified learning-based system will dim the lights, turn up the thermostat and start playing Barry White.
I’m a little skeptical about that. The implied sense of a seamlessly linked and intelligent co-ordinated system isn’t much like the actual internet we have today at all. Rather, it reminds me of Sleeper, or one of those 1960s World Fair ‘house of the future’ mockups in which everything was made by GE or Westinghouse. And it also isn’t what happened with those electric motors or chips. People didn’t buy two dozen electric motors in various shapes and sizes and take them home and build labour-saving devices - they bought fridges and washing machines and blenders and microwave ovens as individual use cases, one by one, over a period of years (or decades). Equally, it seems like the route into IoT is specific services - Nest, Sonos, Fibit, Apple TV/ Chromecast and so on. This is, one might say, a little more like apps than like the web - with Home Depot as the app store.
Another question is where the value sits - which really means where the ‘smart’ part sits. There’s no one answer here. In some cases it seems pretty clear that the connected thing itself is just the end-point for a siloed cloud service - a diagnostics module in a boiler, or a smart meter, for example. You might even have no actual end-user interaction at all. A Nest is somewhere in between - how much comes from the stand-alone device and how much from the cloud? A Chromecast or Apple TV adds ‘smart’ to a TV, relegating it to dumb glass, but it’s really the smartphone or tablet that has all the intelligence to drive it, with the cloud playing the part of ‘dumb storage'. The same may well happen to cars. Many wearables also feel like they should be satellites for a smartphone (to the extent they're not just subsumed into smartphones anyway), either as a remote sensor or a remote display, but the value again comes from the cloud-based analytics: is it more useful to know how many hours you slept or to get big-data based suggestions as to when you should go to sleep and when you should set your alarm? iBeacon is another fascinating part of this dynamic, because iBeacons themselves are not connected to anything, but again, they add intelligence to the physical world. So every wall or retail display or suitcase or package can become a piece of data.
That is, sometimes the device is dumb glass (or a dumb sensor), driven by the cloud. And sometime the cloud is dumb storage, driven by the device.
There’s an interesting Apple/Google dynamic here, of course - if most of these 'things' are some combination of smartphone satellite and cloud end-point, where is the value and control? Apple’s hardware/software integration means it’s best-placed to make things work well (especially with BTLE) but Google is better placed to do much of the cloud stuff. (Of course any device that runs an actual OS will probably use Android, but that doesn’t mean Google will know anything about it). This is the Apple/Google ‘frenemy’ issue all over - if you use Gmail on an iPhone, but only use Gmail and only buy iPhones, both companies win, but both feel insecure.
Back to the Barry White problem, though: there are clearly interconnections that would make sense, from connecting your Nest to your smart meter to connecting it to your alarm system ("turn the heat down, there’s no-one home”). But if the ‘thing’ is basically a dumb sensor and radio and the clever part is in the cloud then maybe any interconnection should probably be in the cloud too? This is part of the story of IFTTT (an a16z investment) - making ‘recipes’ for connecting discrete services. Or it may be a proprietary BD deal, something like Mint - ‘this services connects to all 26 different smart widgets’. And then there’s the Nest story: put a hub into the home with one clear use case and then build outwards - smoke detectors first, then, say, door locks, alarms, garage doors, lights and so on.
But equally, there will probably be lots of ‘internet things’ that never speak to each other. A connected TV and a alarm system can probably work just fine without ever knowing about each other. If you install a burglar alarm (for Americans, burglarizerer alarm) today, it will probably use wireless sensors connected over an IEEE standard to a control box that connects over VPN on a mobile data network to the alarm company’s NOC. It will use IP. So lots of proprietary technology has dropped out and the smartphone war dividend has been reaped, but it’s not in any meaningful sense on ‘the internet’ as we normally use the term. So half the ‘internet of things’ devices in your ‘connected home' won’t be on the internet or be connected to anything else.
A small but important observation, this: we tend to think about tech use cases in terms of our own experience, but that isn't necessarily the mass-market experience. In particular, the globe-trotting, internationalist experience of many people in tech creates problems and concerns that are not necessarily universal. Most people do not fly every month, and most people do not make many international calls (indeed, a lot of people do not even know anyone in another country). This data from Ofcom in the UK gives a little perspective.
Game Oven's post on Android gyroscope support is a nice illustration of a general issue (another good illustration here): Android fragmentation is both massively overstated and massively understated, depending on what you want to do.
On one hand, Google has been quite successful in reducing the impact of Android version fragmentation. Around three quarters of the Android devices that hit Google Play are running 4.X, but more importantly, Google has moved its own key services (maps, payment, notifications etc) out of the OS itself and into a software layer, 'Google Play Services'. By putting key platform APIs into a software layer that can be updated in that background over the air, Google has reduced its dependance on OEMs to produce firmware updates - it can update its own tools any time it wants, across the great majority of phones. When Google announces new APIs for Maps or notifications at this year's IO, they'll be available on devices running year-old and two-year-old versions of Android. There is no more fragmentation if you're using Google's cloud.
On the other hand, hardware fragmentation is if anything accelerating. This chart from OpenSignal, from last summer, is a nice visualization of the market dynamic.
Android fragmentation isn't of itself a bad thing - it's inherent in the choices that Google made. This is what 'open' and 'choice' look like. And I doubt if it's possible to have an 'un-fragmented' device landscape that includes both $600 devices and $50 devices: some scattering in capability is part of the deal. If you want to have thousands (literally) of OEMs, and a huge range of choice and price points, well, you're going to have different devices with different capabilities.
This is only interesting, then, to the degree that it has broader consequences. The consequence of Apple's approach is that pretty much everything behaves in predictable ways, but you have a very narrow range of devices at a narrow range of prices (and screen sizes), and that severely restricts the addressable market. More people can afford $50 phones than can afford $600 phones. The consequence of the Android approach is that you have a much wide range of devices and prices, and a much larger market, but anything on the bleeding edge doesn't work predictably at all. This doesn't just apply to the gyroscope - it also applies to varying degrees to almost anything trying to do clever things with the hardware. This is also true even if the API does actually work as advertised - there's not much point trying to do a mass-market Android NFC deployment when you have no idea how many of your users even have NFC Androids (and the users themselves don't know).
One result of this, as I've said before, is that Apple and Google are focusing their innovation in different areas. Apple is moving down the stack with integrated hardware/software experiences (iBeacon, fingerprints, M7 etc) that are hard for Android to match, and Google is moving Android up the stack with Google Play Services, the cloud and machine learning, which is hard for Apple to match.
The paradox for developers, meanwhile is that the more open and extensible platform can actually be harder to hack on. When you buy two Samsung phones of the same model and brand in two different countries and find they have different camera drivers and your app will crash on one or the other (or both), where do you focus your seed funding? You have limited resources and limited time and you need to hit milestones to get your next round, after all. Plus, the users who want to install your cool new apps are still concentrated on the iPhone. Again, this is a paradox: Android is the platform best for early adopters and iOS the one best for late adopters who just want something that works, but the market adoption is the other way around. That's one of the reasons this chart is both unfair but relevant.
Which type of innovation is crucial to a platform? With the current dynamics, people like Game Oven are going to keep doing iOS first and Android second (if at all), and that keeps the majority of the best users on iOS and Apple's machine turning over - the classic ecosystem virtuous cycle. But if, as many people suggest (Fred Wilson most recently) the most interesting and important innovation will happen in the cloud, then Google's tradeoff might win over Apple's trade-off - Google's comfort zone beats Apple's.
There's another paradox here, though: if all the best stuff is happening in the cloud, then you'll buy the device based not on apps and developer support but on design, quality, fit and finish... that is, all the things Apple always leads on. The web saved Apple 20 years ago, because with the web you could choose the best hardware and UX regardless of the ecosystem - you could buy an iMac and not worry about the software. So if everything goes to the cloud again, is that really an existential problem for Apple?
(As an aside, note this post I wrote a year ago about the different issues facing iPhone and Android.)