In The iPhone Software Revolution, I proclaimed that the iPhone was the product Apple was born to make:
But a cell phone? It’s a closed ecosystem, by definition, running on a proprietary network. By a status quo of incompetent megacorporations who wouldn’t know user friendliness or good design if it ran up behind them and bit them in the rear end of their expensive, tailored suits. All those things that bugged me about Apple’s computers are utter non-issues in the phone market. Proprietary handset? So is every other handset. Locked in to a single vendor? Everyone signs a multi-year contract. One company controlling your entire experience? That’s how it’s always been done. Nokia, Sony/Ericsson, Microsoft, RIM — these guys clearly had no idea what they were in for when Apple set their sights on the cell phone market — a market that is a nearly perfect match to Apple’s strengths.
Apple was born to make a kick-ass phone. And with the lead they have, I predict they will dominate the market for years to come.
But never mind the fact a similar reasoning could have been made of the Macintosh when it came out. What bothers me today is the realization Apple might have handled the opening of the iPhone platform like a cargo cult:
The term “cargo cult” has been used metaphorically to describe an attempt to recreate successful outcomes by replicating circumstances associated with those outcomes, although those circumstances are either unrelated to the causes of outcomes or insufficient to produce them by themselves. In the former case, this is an instance of the post hoc ergo propter hoc fallacy.
cargo cult phone by dret, on Flickr; used under the terms of the Creative Commons CC-BY-SA 2.0 license
By which I mean that Apple decided they needed to open the iPhone as a development platform, but I wonder to which extent they then did so by giving it the trappings of a platform more than the reality of a platform: third parties can sell their apps for running on it, right? So it must be a platform, right? Well… And I don’t mean the APIs are the problem either, it’s more like… everything else:
Apple has a very restrictive idea of what kind of use cases third parties are allowed to provide solutions to: everything that does not fit their idea of an app is rejected, or is impossible. For instance, installing third-party keyboards is not possible on iPhone:
But sometimes, an Apple product’s feature lands at the wrong side of the line that divides “simple” from “stripped down.” The iPhone keyboard is stripped-down.
If you don’t like how Android’s stock keyboard behaves, you can dig into Settings and change it. If you still don’t like it, you can install a third-party alternative. And if you think it’s fine as-is, then you won’t be distracted by the options. The customization panel is inside Settings, and the alternatives are over in the Google Play store.
This? It’s from Andy Ihnatko, in an article in which he explains why he switched from iPhone to Android. Andy. Ihnatko. When Mac users of 25 years start switching away from the iPhone, I’d be very worried if I were in Cupertino.
Even for these use cases third-parties are allowed to provide solutions to, they are quite restricted: when Apple added support for multitasking, in iOS 4, they more or less proclaimed they had covered for every desirable multitasking scenario, and have not added any since. This feels a tad preposterous to me that there would have been no need for even a single new multitasking scenario in the two years since.
Even when third parties can sell their wares, they do so at the pleasure of the king. Apple seems to consider iPhone developers to be contractors/authors developing solely for Apple purposes. And paid by commission. Without any advance. And without any assurance when they begin developing that their app will be accepted in the end.
Apple apps do not play by the same rules other apps do. They are not sandboxed, or not as much. They use private APIs off-limits to other apps. They get a pass on many iOS App Store restrictions. In short, Apple eats People Food, and gives its developers Dog Food:
Microsoft has known about the Dogfood rule for at least twenty years. It’s been part of their culture for a whole generation now. You don’t eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.
In the same spirit, Apple introduced iCloud, gave users the perception Apple did the hard work and that apps would merely have to opt in, sold it to developers as the best thing since sliced bread, then promptly went and not used it themselves in combination with er, the technology they have consistently recommended be used for persistent storage (while ostensibly supporting this combination), without giving the ability to audit synchronization issues either. And now it turns out, and people come to the realization, that iCloud Core Data syncing does not work. Shocker.
Apple even tried at some point to prohibit non-C programming languages for iPhone development, with a clear aim to ban a number of alternative development environments, not just Flash. But just like Apple cannot provide all the software to fulfill iPhone user needs, Apple cannot provide all the software to fulfill iPhone developer needs either. A platform is characterized not just an by ecosystem of apps, but also by an ecosystem of developer tooling and libraries behind the scenes. They ended up relenting on this, but if I were an iPhone developer, I would not be very reassured.
But wait, surely, that can’t be. Apple knows all about platforms and the value of platforms, right? VisiCalc, right? But that encouraged Apple to provide something that looks like a platform, rather than a platform. As for the iPhone not being Apple’s first platform, there is a school of thought that says Steve Jobs did not build platforms, except by accident; so according to this line of thought, the Apple II and the Mac became honest-to-God platforms not because of Apple, but in spite of Apple. And now for the first time we would get to see the kind of platform Apple creates when it actually calls the shots. It looks like a platform, sounds like a platform, has the taste of a platform, smells like a platform, walks like a
duck platform… but the jury is still out on whether it is actually a platform.
There is a case to be made for reducing your dependencies. Apple clearly is not going to let anyone hold it back; but as incredibly skilled as the people working at Apple are, is “not being held back” going to be enough to keep up when Android, propelled by being a more complete and inclusive platform, will threaten to move past Apple?
Apple can still turn this around. Indeed, the issue lies not so much in these restrictions being present at first, than in so few of them having been lifted since then. The key, of course, will be in figuring out which ones they need to lift, and how to do so. And this will require Apple to reconsider the motions it does to bring cargo, regardless of the cargo these actions have brought, and instead focus on improving their limited understanding of what it is that actually makes a platform. In order to really bring in the cargo.