When platform vendors attack

Apple announced a whole slew of new features for iOS 5 and OS X Lion today, and some of them step on the toes of popular third party applications. The New York Times has a helpful list of threatened applications. To gauge the reaction, check out the results of a Twitter search for “sherlocked.”

Platform vendors build in functionality that’s already being provided by third party applications all the time, and this has always been the case. It’s also always been the subject of some controversy. I’m old enough to remember when Dave Winer was feuding with Apple because AppleScript competed with Frontier. And of course, Microsoft’s decision to bundle a Web browser with Windows rather than ceding that turf to third-party developers like Netscape got them into trouble for abusing their monopoly on desktop operating systems.

Of course, today nobody can imagine operating systems without scripting languages or Web browsers. They’re fundamental features and both platform vendors and users benefit from the fact that they’re always available.

When deciding whether or not to add a third party feature to their platform, vendors have to do the math. Competing directly with popular developers costs them some good will with developers, but it also puts that feature in the hands of more users than any third party developer ever could. That, in turn, may help the growth of the platform.

For features that are infrastructure, making the feature part of the OS may in turn make life easier for other developers as well. For example, iCloud Documents clearly competes with Dropbox. For developers who want to be able to share documents through the cloud, iCloud is much more compelling than DropBox because every iOS user will have it. Adding iCloud Documents is a no brainer, no matter how unhappy Dropbox and its fans are about it. (For what it’s worth, I’m a huge fan of Dropbox and I expect that they’ll be fine.)

When it comes to other features that are more about convenience, the case is less clear. For example, Apple has added a new Reading List feature to Safari that enables users to store articles for later in an easy-to-read format. There’s already a wonderful third-party solution to this problem called Instapaper that Reading List competes with directly. The author of Instapaper, Marco Arment, publishes an excellent blog.

Reading List is something to brag about, but it doesn’t add anything fundamentally new that other iOS developers can build on. And it competes directly with a very, very popular third party iOS application. On the other hand, Instapaper is amazingly convenient and basically makes the concept of being bored while waiting in line obsolete. I’m sure Apple’s developers decided that the functionality was too great not to build into the platform. Why shouldn’t every iOS user have it?

This is the thing every third party developer has to worry about; will Apple or Google or Microsoft or whoever look at their application and decide that the core functionality should be built into the platform. More importantly, they have to figure out how to build a sustainable business in a world where that’s always a possibility.

In the end, I’m not entirely sure that this sort of competition is always bad for application developers. In 2007, Slate published a piece explaining why Starbucks was actually good for independent coffee shops. Starbucks teaches people to appreciate fancier coffee and soon discover that independent shops offer better coffee at a lower price than Starbucks does.

Instapaper is almost certainly already better than Reading List will be when it’s released, and even if it isn’t, Marco has a few months to make improvements that will make it better before iOS 5 is out. In the meantime, people who are intrigued by Reading List can go out and get Instapaper right now. In the future, people will try Reading List, and some of them may decide that they want the more powerful features Instapaper offers, just like Starbucks customers eventually try independent coffee shops.

So while Reading List can clearly be seen as a threat to Instapaper, it may also turn out to be the best thing that ever happened to it, depending on how Marco responds. And I’d say the same for many threatened applications.

The real worry isn’t fair competition, but rather the ability of platform vendors to make life harder for rivals. Platform vendors can use APIs that they don’t provide to third parties, and of course Apple can abuse the application review process in any number of ways to cut off third party developers. As customers, that’s where we need to be attentive. Adding a feature to Safari that competes with Instapaper is fair as far as I’m concerned. Later denying Instapaper access to the App Store because its functionality overlaps with a feature provided by Apple would not be.

Addendum: I should note that for a long time I was on the other side of this debate, and fiercely argued against platform vendors adding features to their platforms that cannibalized the work of third-party developers. What I realized was that this sort of thing is inevitable and often a positive for users. It’s not debatable that Microsoft creating Internet Explorer was good for end users and was of course great for the Web. Some of their business behavior was problematic and probably illegal, but Microsoft was completely right to go into the browser business.

6 thoughts on “When platform vendors attack

  1. Joel Spolsky calls some of these examples “picking up coins in front of a steam roller” and he’s right imho. The main point here is that if you provide a service that is useful to every single last user of a platform, basically something that should have been part of the platform, you will eventually have that problem. In the case of WhatsApp they might even have enabled Apple to build this, because first the network operators had to realize that SMS-revenue will not exist forever in a smartphone world.

    So the final point is that a 3rd party developer should build interesting verticals. Games, API clients and services that need highly scalable back-ends are a good match.

    Any feature that appeals to everyone on a platform is a natural match for a platform extension. That’s just how it is. Btw, this also applies for: backup software, malware scanners, firewall software, browsers, mail clients and more…

    So I don’t agree with your analysis completely. “Reading list” vs. Instapaper is a special case where Apple’s interest in wanting to be perceived as the publishing industry’s savior overrides the necessity for a wider appeal across the platform’s users, but in general developers simply should try not to fill obvious gaps in a platform vendor’s system.

  2. All of those categories are ones where third parties have made a lot of money over the years. Developers always face competition from other third party developers, from platform vendors, from open source. That’s just the nature of the beast.

  3. Microsoft didn’t get into trouble because they included Internet Explorer. They got into trouble because they excluded and sabotaged other browsers.

  4. Every 3rd party developer facing competition from the new iOS 5 features has at least 3+ months to innovate and differentiate – iOS 5 will be available “in fall”. Thats a lot of time to improve and refocus an app and revalidate your business modell. And everyone mentioned already made money through sales and/or advertising by using the ecosystem built by Apple. Reinvest the money in app updates! (It would be a diffent situation if a new app that was developed over months would be rejected by Apple only because the same function already exists in the upcoming version of iOS.) Things are changing all the time – if its not Apple competing then its the other developer. Play your stengths: Dropbox wins hands down in cross platform availability and ease of use. Camera+ has lots of great filters and post-processing features that can be used as a differentiating point (and is missing the universal app so it works on the iPad2 as well). What about cross platform and social charing features for ReadItLater? And so on. Find your niche and you’ll win, especially with an already large installation base. Do something better or different. Speculating that Apple could ban established apps with functions now built into iOS in the future has no foundation and IMHO is very unlikely.

  5. Well, Apple has banned certain classes of applications that duplicate built-in functionality. As Apple builds in more functionality, the possibility exists that Apple could ban more apps for the same reason.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>