Yesterday, I laid out some concerns with Apple’s App Store model.

Here’s a suggestion for how Apple could improve and tackle those challenges:

  1. The iOS App Store is reduced to a curated experience of 20,000 apps or less.
  2. Sideloading apps is allowed.
  3. Optional: Apple sells an “App Platform as a Service” that handles distribution, hosting of app binaries, etc.

Curation for the Best

By reducing Apple’s iOS App Store to ~20k apps, consumers who visit it know they are getting the best of the best. Think Trader Joe’s-level product selection and curation.

  • Developers must apply and be let in.
  • A developer with one app in the Store is not guaranteed a second app inclusion.
  • The iOS App Store is marketed by Apple as the primary, best, and safest way to install apps on your iPhone.

Why do this? First, Apple will have a much better time of it reviewing 20,000 apps versus the millions of apps which litter the App Store today. This model gives Apple’s team of 500 human reviewers the chance to make a quality judgement about each and every app update. No more calculator apps with casino’s hidden behind the 7-key. When you choose an Apple App Store app, you are choosing a best-of-breed option.

Second, given the constrained space within the App Store scam apps would become apparent almost immediately. Given the limited “shelf space” available in the App Store, developers who were included would not risk losing their spot (and future spots) by introducing a scam product.

Third, Apple can seize the marketing opportunity to claim the iOS App Store is truly “safe and trusted”. Apps offered in this model would be partnerships approved by Apple, much like the physical accessory products sold throughout Apple Retail Stores are today. I can buy some nice Belkin accessories in Apple Retail, but I cannot buy a cheapo $5 charging brick that burns my house down. Apple would never allow junk to be sold through it’s retail channel; apply that same thinking to the App Store.

Sideloading for the Masses

Reducing the App Store from millions of apps down to a mere 20,000 is going to impact a lot of really good developers. This is the problem sideloading solves.

  • No human app review.
  • App must be notarized by the developer.
  • External payment options are allowed. Cannot use Apple’s in-app purchase (IAP).
  • App developer responsible for hosting, distributing updates, etc.
  • Limited access to services paid for and provided by Apple.

Removing human app review means Apple does not need to staff up a team to handle the ever-increasing volume of app submissions. This also frees developers to try new and exciting ideas which might be outside the scope of what humans employed by Apple are currently willing to approve, yet would find a customer market if only given the chance to live.

The requirement for notarization follows how most modern macOS software is distributed. Let’s bring Gatekeeper to iOS. This would also allow Apple to “kill switch” apps which are proven to be truly malicious. We should not look to Apple to protect all users from every possible scam, just as we don’t expect Apple to review the entire internet for every possible malicious website when using Safari on iOS.

When collecting payments in a sideloaded app, it’s only fair to both parties (Apple and the app developer) to (a) not allow the app developer access to Apple’s home-grown IAP payments software and (b) not restrict the developer from using Stripe or similar third-party service to collect payments.

In the same vein, the hosting of the app binary should fall to the developer1. Over time I can imagine a robust third-party ecosystem springing up here to support developers big and small in this mundane tasks. See Stripe for payments and RevenueCat for IAP as examples of how a focused third-party can build a much better product than Apple, with it’s attention pulled in every direction, can.

Finally, iOS platform services Apple has built themselves (e.g. CloudKit2) should be limited and possibly something a developer pays a monthly bill to Apple for. Sideloading should not create a “free ride” for developers within Apple’s ecosystem, and the flow of cash should reciprocate with the flow of value. Doing so will incentivize Apple to build better products that generate cash flow, and abandon those which do not.

App Platform as a Service

This is the area I am most fuzzy and likely to get something wrong, but I believe Apple should offer an App Platform as a Service (APaaS). This is a split between being a curated app within Apple’s App Store, and being a sideloaded, do-it-yourself app in which Apple has no involvement.

Include in this service:

  • In-app purchase
  • App binary hosting and distribution

Offering APaaS along with sideloading creates a competitive environment. If it’s a bad solution for most developers, then third parties will move into the space to build something better.

There is one thing Apple can offer here that no third-party can, and that’s an Apple-branded seal of approval. Apple’s brand has a lot of cachet in the consumer marketplace, and Apple is right to make a profit off of that.

Will it work?

As John Gruber has claimed, the iPhone is an “app console”. I disagree. Too large a population of people do most of their computing from a single device, and when a person has a single device it is most often a phone. The iOS ecosystem is simply too large to be constrained to the limits of a console like an Xbox or Playstation is.

However, in a model where the iOS App Store offers a curated experience of ~20k apps, the notion that the iPhone is an “app console” begins to clarify. With sideloading as the pressure-relief valve to ensure that many developers are not shut-out from their customers, and that iPhone owners can always have the broadest selection of software, we can have the best of both worlds.

  1. This may pose some logistical challenges at first, but given that I can download an update to Microsoft Excel from Microsoft to my Mac today, I see no reason why I could not download the iOS version from Microsoft as well. ↩︎

  2. CloudKit storage uses iCloud storage already paid for by the end user. As stated in Apple’s Developer Resources: “Store private data securely in your users’ iCloud accounts for limitless scale as your user base grows, and get up to 1PB of storage for your app’s public data.” The app public data would have to be paid for if used by the app developer, or the developer could investigate a third-party solution a la AWS S3. ↩︎