Apple opened the door to web paywalls — our test shows it might hurt conversions

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.

Read on to find the full results, learn how we ran the experiment, what we think the findings might mean, and what you can do today to run a similar test with RevenueCat. If you’d like to see us review the latest experiment data live, join our next bi-weekly office hours this Friday.

How it all began

Two weeks ago, there was a court order in the Apple vs Epic case that forced Apple to allow developers to circumvent in-app purchases (IAP). As of April 30th 2025, developers were finally allowed to send customers in the United States to an external website to complete the purchases, and thus avoid the 30% fee that App Store takes. We quickly released Web Purchase Buttons that, combined with our Web Billing product, create a seamless way for developers to drive purchasers out of their app to the web for check out.

RevenueCat’s new Web Purchase Button in action

IAP in the US is a $52B market, representing about half of all App Store revenue, and this is the first time that Apple has opened up such a major market to web purchasing. Previously, similar court orders have been limited to much smaller markets. It has been much debated over the years how much, or even if, this new-found freedom would help developers make more money. The only real way to know is to run a test, so we took this opportunity to run the biggest open test of web purchases in history.

Last week, we deployed an experiment on Dipsea (the app we acquired last year as a testing-ground) and we’re excited to share initial results.

Our experiment

We ran a four-way test using RevenueCat’s Experiments tool, with the following variants:

	Variant A	Variant B – Clone	Variant C – IAP + Web	Variant D – Web Only
Paywall	Dipsea’s native paywall	A clone of Dipsea’s native paywall implemented with RC Paywalls	Option to subscribe on web & save 30%	A clone of Dipsea’s native paywall but purchases can only be made on web (no IAP)
Payment Options	IAP	IAP	IAP + Web Purchase	Web Purchase Only
Prices	$69.99 Annual (IAP) $25.99 Quarterly $12.99 Monthly (IAP)	$69.99 Annual (IAP) $25.99 Quarterly $12.99 Monthly (IAP)	$69.99 Annual (IAP) + $47.99 Annual (Web) $12.99 Monthly (IAP)	$69.99 Annual (Web) $12.99 Monthly (Web)
Notes	This serves as a baseline and to isolate any issues potentially introduced with our implementation of Paywalls	We tried to match the native Paywall pixel for pixel.. Same prices as in the control.	This variant introduces a discounted offering on the web, offering 30% off the annual IAP price. Theoretically, this should make up for the 30% fee Apple charges developers, and developers should be indifferent between these options	This variant removes all IAP options. Dipsea is able to do this because it falls under the “reader app” exemption. Compared with variant B, it helps us characterize the inherent friction in the web flow, holding all other things constant.

We started the test on May 7th targeting all of Dipsea’s new US customers. So far approximately 5,600 participants entered the experiment, totalling roughly 1,400 customers per variant. 

Results at a glance

Early conclusions

The experiment has only been running for 6 days, but we’ve already seen some interesting results. 

IAP vs web

Variants B and D have the clearest, and easiest to interpret, differences. They have the exact same design and layout, the only difference is in-app purchases vs external purchases. And we can get a pretty clear understanding of the drop-off caused by kicking someone out to the web and circumventing IAP. 

The IAP Only variant of the paywall (Variant B) had a 42% lift in Initial Conversion and a 43% lift in Trial Starts vs. the Web Only variant (Variant D).

Variant	Paywall Views → CTA Tap	CTA Tap → Initial Conversion	CTA Tap → Trial Start	Paywall View → Trial Start
Variant B – IAP Only	50%	73%	67%	33%
Variant D – Web Only	52%	42%	37%	19%
DIFF	-4%	42%	45%	43%

This early on, the only metric we can have any confidence in is Initial Conversion (trial or subscription start).

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.

We don’t have data on trial conversion rate yet, or any other downstream rates that may affect LTV. It’s possible the web cohort has a higher LTV, but they are starting out from a deep hole. 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. 

Run this experiment in your own app

This is one data point from one particular app, with a particular user base. If you want to really understand how your app will do with a web based purchase flow, you will need to set this up yourself. Fortunately, we make this easy:

1. Set up RevenueCat Web Billing by connecting your Stripe account to RevenueCat
2. Create a Web Purchase Link, attached to an Offering that includes Web Billing products
3. Add a Paywall for your Offering with web purchases that uses the Web Purchase Button component to link out to a Web Purchase Link.
4. Create an experiment comparing your existing IAP Offering & paywall with the new Web Billing offering

Limitations and coming data

It’s only been a week, so this data is very preliminary. Big unexpected swings in things like trial conversion rate, renewal rate, refund rate or more could affect the outcome, however with the significant dropoff in initial conversions on web, this doesn’t seem likely. It seems likely that pushing users out of the app has a substantial impact on initial conversion rate, and isn’t a “free” 27% boon to developers. 

If you are on the Small Business Program, it’s unlikely sending traffic to the web will net you ahead given Apple’s fee is only 15% of revenue. If you are paying 30%, it’s possible that it’s closer, but a naive implementation, with no discount tradeoff, doesn’t seem to be worth it. Perhaps with more sophisticated targeting, better framing, different checkout pages, or some middle ground on pricing, you could find a way to make the drop off in conversion make up for the increased revenue, but you are playing a game of inches. 

We’ll continue to monitor the test and will update with new posts in the coming weeks, including a roundup when we have confidence in the mid-term LTV implications of the experiment.

We’ll also keep shipping like crazy so you have the tools to make testing like this even easier.