What Apps Are We Missing Out On?

One of the biggest downsides of in-app purchase (IAP) restrictions is that many apps simply never get created. We see these tensions play out all the time — with the conflict between Epic and Apple, Netflix pulling back from IAP, and Amazon not selling books in their Kindle app. And these are just the stories that get attention. There are whole categories of great software that never get to exist on the app stores because of IAP constraints.

Now that the Epic v. Apple case may open up commerce on the app stores, I’d like to highlight some of the business models that couldn’t work under the old regime.

Companies that don’t quite fit the mold

I think about this all the time: What about the companies that don’t exist because the current payment model doesn’t work for them?

What about all these “in-between model” companies that don’t neatly fit into the App Store in-app purchase system? Take user-generated content companies, for example. They have to create an IAP product (SKU) for every content creator, and it’s a total nightmare for them to administer and pay out. And financially, when Apple takes 30% of every $1 you make from a consumer, there’s really no margin left for the app developer.

Most of these companies just don’t get created. Every time I meet with app developers and someone comes to me with something that’s “weird” and pushes the limits of the App Store Guidelines, I can’t tell them confidently that Apple will allow it. And that’s because Apple’s policies are kind of hostile, at least with the way the rules are set up right now. I don’t think Apple is necessarily out to get developers, but the current IAP rules lead to these outcomes..

Technical vs. economic constraints

That’s because Apple is catering to very specific business models. And the current IAP system creates two major constraints for app developers.

First, there are the technical constraints. It’s very difficult to modify someone’s billing programmatically in IAP. You can do it, but a user has to be in the app and has to go through a second purchase UI flow. I don’t think a ton of apps can do this because it’s really difficult to test. It adds a whole other layer to all the complexities of IAP, which most small companies aren’t ready to handle.

Then there are the economic constraints. Apple’s large take rate is a big deal. Any time there’s a digital transaction, Apple takes 30% — it doesn’t matter how many parties are involved. Take ebooks as an example. There’s the author, the publisher, the app creator, and the user. The author, publisher, and Apple get such a big chunk of the pie, there isn’t much left for developers. This diminishes the incentive for innovation around content distribution apps.

Here’s another example: the F1 and MotorTrend apps. F1 owns the rights to Formula 1 broadcast, giving them margin and allowing IAP to work for them. Same with MotorTrend. They produce a lot of first-party content and can manage 30%. But if you’re a smaller app that doesn’t produce first-party content, operating with the 30% is likely a dealbreaker. There’s just no margin left for you after Apple and the publishers take it all.

In a perfect world, I could see a case where Apple gets more discerning and says something like: “If this is purely first-party content that you’re selling, it’ll be a 30% cut. But if you’re a reseller of content, then that’s a different thing.”

But that creates more work at the app review level, and Apple has to think about scale. So that might cause more pain for developers because it’s really hard to get normalization across thousands of app reviewers.

The prosumer app category

Another category that’s constrained by Apple’s rules is the prosumer space. Years ago, I talked to a barber shop app that helps shop owners manage their business, and it’s a great example of an app that faces technical limitations.  

Here’s how it works: You own the barber shop, you have multiple chairs, and you have barbers who rent the chairs from you. Ideally, the app wants to charge more or less for a shop owner depending on how many chairs they support.

Unfortunately, this goes back to our initial technical problem. On IAP, there’s no way to incrementally change a subscription. So salon owners can’t simply say: “I need 2 more seats this month” and have the developer update their billing — at least not without a complicated upgrade/downgrade UX.

It’s just too difficult to pull off. It’s difficult on iOS and it’s difficult on Android, so it creates a lot of business models that just don’t function. Often, usage or seat-based pricing is the most directly tied to value, especially in the prosumer and business space. And this really upsets me because mobile is just such a good form factor for small business owners. Everyone’s got a phone, and you don’t always need a big point-of-sale system.

But when there’s no good way to monetize good software, it forces those companies to monetize in more awkward ways.

Pushing through technical constraints

Tingles, one of RevenueCat’s earliest customers, is a great example of this. They’re an ASMR app and managed to push through the technical limitations, but it was an intense engineering lift for them.

Essentially, they have a gold pass that gives you all-you-can-eat content, but there were also individual Patreon-style subscriptions with a bunch of creators on there. Seems straightforward enough, right?

Unfortunately… no. They have to deal with the 30% cut because it’s one-to-many digital content, not person-to-person. Since they don’t create private ASMR experiences for people (they’re selling access to recorded content)  they have to go through IAP. They had to create hundreds of in-app purchase SKUs for each creator, and it wasn’t very flexible because of the technical limitations.

If you were to do it with a different payment platform, such as Stripe, you’d just have one SKU and tag it with the actual creator, which is very easy to track within Stripe’s system. But with IAP, it’s really difficult. There are companies that can push through it (like Tingles), but it puts a huge engineering burden on them.

The way forward

This is why I’m excited about the potential changes to the App Store rules.

While these companies will probably still have to offer IAP, once cracks begin to show in the foundation, and the UX benefits that IAP provides in simple cases no longer dominate, it’ll start making sense to send customers out to alternate payment methods. You’ll be able to send customers to a website, or use Stripe, where you can charge users per seat, per haircut, or whatever billing system makes sense for you.

This will give app developers a lot more freedom and flexibility. And I can’t wait to see what kinds of apps spring up because of it.