Three easy ways to fix the App Store. And one really, really hard way.

posted 17 November 2009, updated 19 November 2009

The iPhone App Store is broken. Everyone can see it's broken, and the nerdosphere is abuzz with people wondering aloud why doesn't Apple do something? The answer is: because it's really, really hard. But they're going to have to do it, and soon.

The background

When Apple launched apps for the iPhone, it also launched the App Store. It had a bunch of good reasons to do:

  • Discoverability: a traditional limitation of mobile apps has been that because browsing (in the sense of "browsing a book store" rather than "browsing the web") on a mobile device is quite finicky, people are willing to spend less time doing so.
  • Installation: installing apps on phones prior to the iPhone was almost always a gigantic hassle that involved downloading the app to your computer, running software on your computer, hooking your phone up to that computer, and transferring over the apps. On-device installation was pretty rare and combining it with a purchase mechanism essentially unheard of.
  • Trust (from consumers): people are very aware that their phone is a device full of personal information, for some reason more so than they are of a full computer. They are also much less tolerant of software failure in a phone -- they need it to make calls all the time. As such, people were -- prior to the iPhone -- very wary of installing anything at all on their phone.
  • Trust (in developers): when Apple built the iPhone, it decided to write apps in Objective-C. This meant that apps could do stuff like use private APIs that would let them do anything the phone could do, rather than the "safe" subset selected by Apple for public APIs*. And a dirty secret of the mobile phone business is that a lot of mobile infrastructure relies on operators trusting devices to behave properly. This is why new phones have to be tested extensively before an operator will approve them for use on its network -- it's not because the phone might not work (why would they care? you'd still pay your bill) but because a badly-behaved phone can break the network, or at least badly degrade service**.

The very existence of the App Store fixed the first two problems. To solve the last two, Apple instituted a manual approval process: actual human beings would install and run your app, and make sure that it was useful, safe, and didn't break any rules.

But now the cracks in the model are beginning to show. As the market scales up, the App Store is failing to scale with it. You just can't scale up an organization of people and expect it to work like it did when it was small. Misunderstandings grow, miscommunication increases, and stupid decisions get made. automating the common reasons for rejection is merely a delaying tactic. The unpredictability of the app store is starting to drive developers away.

You can't shut down the app store, and you don't want to. But how to fix this situation? How do you make the app store scale?

1. Open the gates

As I mentioned earlier, the store is really doing several unrelated functions:

  • providing a discovery mechanism
  • allowing on-device installation
  • allowing on-device purchase
  • providing a quality and safety filter

You can split these out. Just as you created the itms:// link, create the ipas:// link that points to a standard file that the iPhone can use to request installation permission. Then you can follow the link from any web page, either from a computer with iTunes installed or from Safari on the iPhone itself. If the app is free, that should be all that's required.

2. Separate payment from approval

If they want to be a paid app, they will need to register with your store as an application publisher. Once registered, they'll get access to the APIs that allow them to request payment. All of that can be self-service, and doesn't require any human intervention. It scales beautifully.

Worried about the stain on your reputation by taking a cut of apps that turn out to be rip-offs? Don't. Have a report-and-takedown mechanism for scams, sure, but once you are just the payment mechanism, you'll be fine. People will learn. It will be easy for them to spot quality apps, because...

3. Make app store listings paid

So you have 100,000 apps in the store, huh? Good for you. Nobody will ever view more than a fraction of the best-selling ones. However, as a discovery mechanism, it's still very powerful. Even after you open the gates and allow anybody to install from anywhere, most people will still hit the app store first. This is advantage you can use.

Make apps pay to get reviewed, and let them pay more to get reviewed faster. This isn't the best metric for getting the highest-quality apps reviewed first, but it's better than what you appear to have, which is no metric at all.

With the money you get from paid listings, hire more reviewers. At the moment, anybody can submit an app, and if it's free the only revenue supporting your staff of reviewers is their $99 developer program fee. A flat fee isn't going to scale to all of those reviews (and re-reviews). So charge, and hire more people to do the fewer reviews. I know I said organizations don't scale up well, but rumours are there are only 50 reviewers working for the app store; you need more than that. How many people work for iTunes Music Store?

4. The big, hard problem: lock it down

All of the first three suggestions sound great and are easy to implement, but they rely on one big point: you need to find a way to keep apps from accessing private APIs. This is a fundamental architectural problem with using Objective-C as your development language, and I'm not suggesting it will be easy. You might need to create Mobile-Objective-C, where the rules are slightly different (there is already a mobile Java).

Locking down APIs means you can still promise the operators that your iPhones will not be either intentionally or maliciously trashing their networks, something you can't do right now without manually inspecting each app. If you have to, split your APIs into two tiers: "automatic approval" APIs, available to apps that are installed without your approval, and "blessed" APIs, available only to apps that get special keys that you provide when you approve them for the store.

I won't lie. This will be a huge pain in the ass. Standard compilers will need to be rewritten, old IDEs won't grok the syntax, shit will go down. But your alternative is to get buried under an avalanche of your platform's own success, and drive away the long-tail of small developers who have been the drivers of that success.

Update: Paul Graham has his own thoughts on the App Store, although he doesn't seem to think Apple can or will fix the App Store, and instead wishes for another platform to replace iPhone entirely.


* This is because Objective-C lacks private methods. On other mobile platforms, apps are frequently written in Java (Android) or a variant of C++ (Symbian, which runs Nokias), both of which supports private methods natively.

** My own discovery of this was when I worked for a mobile content company several years ago, and accidentally discovered that a combination of badly-written APIs allowed me write a "multipart" SMS with a flawed header section that declared it to be "part 1 of 0 parts". On a receiving Nokia phone, this caused the phone to throw a totally unhandled exception, and summarily shut down.

tagged with
6 comments