External Purchase Conversion Metrics
Turns out, in-app purchases are good for conversion rates. In fact, at least 30% better. That’s one of the things we found while running the first large-scale, side-by-side test of in-app vs web purchases in history.
[…]
The initial conversion rate for variant B is between 27% and 30%, while the equivalent web flow in variant D is between 17% and 19%. This is a large decrease, a 25% to 45% relative drop between the two. Digging into the funnel, most of that drop occurs from the payment sheet through to purchase. That’s a lot of fall off.
I do not find the difference surprising—especially since this is all so new. It can get better from here. I wonder how many of the customers had Apple Pay set up and how many used it.
Reduced fees aren’t the only benefit of web purchases; they usually have more tools to retain and serve these users. Payment processors like Stripe pay out much more quickly than IAP, reducing cashflow constraints.
And better handling for refunds.
You can make this up by offering a discount, we tested this too but don't have anything conclusive to say about that test yet.
It’s almost like Apple never needed these draconian rules all along and could have just competed on the merits 🤔
They’re still not competing on the merits because they don’t allow implementing alternative in-app payments.
Previously:
- Apple Appeals Epic Anti-Steering Injunction
- Free With In-App Purchase Is a Sham
- App Review Guidelines Updated for Epic Anti-Steering
- Court Orders Apple to Comply With Anti-Steering Injunction
Update (2025-05-16): John Gruber:
That’s a notable drop-off.
I don’t find it surprising at all though. IAP really is more convenient. Apple’s built a great system, and they don’t need exclusivity to keep users preferring it, and thus keep developers using it.
18% vs. 28% is basically the same take-home revenue when you factor in Apple’s 30% cut. Most devs would probably prefer having 2/3 the customers (and support) for roughly the same income.
This is not competition. This is comparing an inconvenient workaround to a good system. Competition would look like an Apple Pay or Shop Pay button right in the UI.
There’s a long and growing list of features common on most payment & subscription service providers that still aren’t possible on the App Store today. Price testing, refunds, managing subscriptions, plan migrations, gifting, discount codes, subscription bundles—to name just a few. Entire businesses have spawned just to fill these critical gaps.
In fact, just last week a group of app developers and I were debating the least awkward approach to test subscription prices on the App Store where you have to choose between stranding customers on dormant plans or listing every price ever tested to everyone. Thankfully, in 2025, and we have solutions for things so fundamental as this—just not at the world’s largest tech company.
Via John Gruber (Mastodon):
It’s kind of bananas that it’s 2025 and the App Store still doesn’t allow developers to issue refunds. I’ve had this discussion with numerous developers. They’ll be doing customer support, and want to issue a refund, but explain that they can’t — and users find that so hard to believe they suspect the developer is bullshitting them.
Previously:
Update (2025-05-19): Curtis Herbert:
There are two things Apple provides as part of the IAP system that has always been undervalued, and in my opinion they are well worth that theoretical 27% (or 12% on subscription renewals).
[…]
The way I'm looking at all this is that IAPs are the best way to gather your first payment from a customer, especially if you have a free trial. They'll provide the least friction and highest conversion rate. From there, after you earn a customer's trust over time, you can try to move them over to the web, likely from other flows like emails. Maybe you have a black friday sale with a one-time discount to move them over. Maybe a year after they first subscribe, you offer a one-time 15% renewal discount if they move to web. Maybe you leverge the web to try to win back people who have churned out, or people who abandoned checkout.
There's a lot to experiment with here, and a lot to learn, as an industry. Just like you needed to experiment with things like the best time to show your paywall, you'll have to experiment with when's the best time to try to move them to the web.
I think the perspective on this topic varies between developers partly based on whether you expect users to randomly discover your app in the App Store, or whether you’re building a service outside the store and the mobile app is just a companion to that.
[…]
Developers are in the best position to know what marketing and payment options will work for their app. The whole point of these changes — from the EU’s Digital Markets Act to the judge’s ruling in the Epic trial — is to put the decision back in the hands of developers where it belongs.
See also: Nick Heer.
2 Comments RSS · Twitter · Mastodon
I don't find it surprising that apple can provide an easier payment solution on iOS and therefor convert better.
Does Mobile Safaris store user details like name, address and payment info?
Another factor they seem to have skipped is how much money each transaction results in after fees.
@ Kristoffer
Yes, Mobile Safari will memorize your card information (if you like) for future auto-complete at online store.
Apple’s IAP and App Store one-click purchase was actually licensed from Amazon’s one-click purchase patent (expired in 2017), so we should credit Amazon for that reduced friction.
“Reduction in friction” is worth something to sellers. It was valuable enough that Apple to paid Amazon. I’d argue it’s valuable for app makers, even those complaining about the fees.
Apple (and Amazon) are selling lube, and lube is worth something. Better lube is worth more — ask any motor oil maker (like Epic Store).
