Web vs in-app subscriptions: Web subscriptions result in 6% drop in takehome revenue

Two weeks ago, we shared initial results from our first-of-its-kind experiment comparing web vs. in-app purchase (IAP) flows for subscriptions in a blogpost that’s included, in full, at the bottom of this post.

At that time, we only had early data, primarily on initial conversion (free trial or subscription start) rates. Now, with the experiment running for a little over three weeks, we have new data on trial completions, conversions to paid, and revenue. This update digs into the findings for the three main variants we tested (B, C, and D), examines the revenue implications in cents on the dollar, and provides fresh context on the shifting legal landscape (think anti-steering, the Apple vs Epic case, and more)

Our goal remains the same: We want to help you make informed decisions about offering web subscription options alongside (or instead of) native IAP. We’ll dig into the data, but for now we noticed a clear trade-off: Web purchase flows might indeed yield stickier subscribers, but at the cost of significantly fewer conversions up front. Let’s break down what we learned

Key summary. Once we added a web purchase button, the app made 93¢ for every dollar we made with IAP-only. And that’s with a 30% App Store fee. If this app were on the Small Business Program, they would have made 86¢ per IAP dollar. Head straight to the Revenue Per User (RPU) section for the details, or follow along as we go from experiment design, to conversion rate, to RPU.

Recap of the web vs IAP experiment and variants

For those just tuning in: We’ve been running a four-way A/B/C/D test on the subscription app we acquired last year as a testing ground. We used RevenueCat Experiments to split new US users into different paywall experiences:

The four paywall variants in our experiment (Dipsea app on iOS)

Variant A (not discussed in detail here) was the original native paywall using only IAP. Variant B was a functionally identical IAP-only paywall built with our latest paywall system (a control to ensure our implementation didn’t introduce issues). Variant C offered two purchase options – an Apple IAP with a free 7 day trial at the standard price or a discounted web subscription (annual price with 30% off to mirror the fee savings). Variant D was web-only: All subscription CTA buttons led to our Web Billing flow, with no in-app purchase option at all (possible because Dipsea qualifies as a ‘reader’ app)

Each variant showed the same content, only differing in the purchase flow and messaging (eg. Variant C’s “save 30% on web” CTA, and variant D’s lack of any IAP button)

We started the test on May 7, and now – after three weeks – we’ve seen over 3,100 users per variant (roughly 12,500 total participants) enrolled in the experiment. With a good portion of those now having made it through their trial periods, we can compare how offering web purchase options affected user behavior further down the funnel

New findings on initial versus trial conversion rates

The initial results (after ~6 days) showed a dramatic gap in initial conversion rate between the IAP-only and web-only experiences. Now with more data in, that gap has persisted: Variant B (IAP-only) has achieved an initial conversion rate of about 27.0%, whereas variant D (web-only) managed only 18.1%.

In other words, forcing users to an external web checkout reduced the immediate trial start rate by roughly one-third.

This confirms the big drop-off we suspected: handing off to the web introduces friction (extra taps, payment form, etc.), and many users bail out before starting a trial. The funnel metrics pinpoint that most of this loss happens after the paywall CTA tap, so during the payment flow itself. On variant B, the IAP paywall, about 71% of users who tapped ‘Subscribe’ completed the purchase, versus only 44% of those who tapped the web CTA.  The IAP variant got 1 in 4 users to start a trial, while the web only barely got 1 in 6.

variant	Paywall CTA Tap	Initial Conversions	CTA Tap to Initial Conversion	Trial Starts	CTA Tap to Trial Start
IAP only	1170	830	70.9%	768	65.6%
Web only	1239	550	44.4%	485	39.1%

The story evolved once we tracked what happened after those trials began. Even though the difference isn’t pronounced, the new data on trial conversions to paid seems to support rampant speculation on increased conversion for web: Variant D’s trial conversion rate (percentage of trials that converted to a paid subscription) ended up at 26.3%, slightly higher than variant B’s 25.0%. Especially when we consider that the highest trial conversion rate of all was in Variant C (IAP + web) at 28.2%. This suggests that offering a web option did yield some cohorts that cancel less and carry trials to completion more often. It’s likely that users who chose the web path in variants C and D were more committed, encountered more friction to cancel, or a combination of both, resulting in a greater share sticking past the trial period

But here’s the rub: a higher trial retention rate didn’t fully compensate for the lower trial start rate. Variant B (IAP) still produced more net new paying subscribers than Variant D (web) in the same audience. We can look at conversion to paying (the percentage of all users who ended up as paid subscribers). Variant B’s overall paid conversion was 6.3%, compared to Variant D’s 5.3%. So, even though web sign-ups did convert to paid at a somewhat higher rate, the initial shortfall in volume meant fewer paying customers overall. We basically traded quantity for quality: the web funnel gave us fewer trialers, but those who did subscribe were slightly more likely to become paying users

The IAP + web variant: Does choice help or hurt?

The variant that’ll be most relevant to the majority of apps is variant C, which gives users a choice: Apple’s standard in-app purchase (with free trial) or an external web purchase (with a 30% discount on the annual plan). This was meant to test a more common scenario: Unless you qualify for the reader-exemption, you’re still required to offer IAP alongside whatever web option you want to experiment with.

Metric	IAP only	IAP + Web	Web only
Customers	3,127	3,191	3,113
Initial Conversions	844	749	562
Initial Conversion Rate	27.0%	23.5%	18.1%
Trials Started	780	701	496
Trials Completed	537	493	373
Trials Converted	134	139	98
Trial Conversion Rate	25.0%	28.2%	26.3%
Paid Customers	198	187	166
Conversion To Paying	6.3%	5.9%	5.3%

So what happened when we put IAP and web options on the same paywall? Variant C’s results landed in-between the extremes of B and D. The initial conversion rate was 23.5% – lower than the IAP-only flow (27.0%), but higher than web-only (18.1%). This indicates that having two buttons (and an arguably more complex decision for the user) did introduce some friction or decision paralysis, reducing overall uptake compared to the clean single-CTA paywall. Some users likely clicked the web option and then dropped off (as in Variant D), while others chose the IAP trial (which has the smoother funnel)

On the other hand, trial conversion for Variant C was the best of the bunch at 28.2%. This high rate likely reflects that a segment of users in Variant C took the web offer (perhaps enticed by the 30% discount) and then more of those web trialers ended up paying. In essence, Variant C captured a hybrid benefit: it still let less price-sensitive users convert easily via IAP, but also attracted a subset to the discounted web subscription, who then churned out of the trial less. The net outcome was that Variant C’s overall conversion to paying (5.9%) came out slightly below Variant B (6.3%), and it yielded only a marginally lower number of paid customers in absolute terms (187 for C vs. 198 for B, out of ~3,150 users each). So offering the choice didn’t produce a breakthrough lift in paid conversion, but it narrowed the gap caused by the web friction. It’s interesting that some users did take the web deal: roughly 36% of revenue in Variant C came via web purchases (with the rest via IAP) based on the proceeds data, and those web subscribers generate a higher net return per user

The takeaway seems to be that a dual-option paywall can moderate the trade-offs: initial conversion will still dip compared to a pure IAP flow (choice adds friction), but you may gain higher-value subscribers and generate only a slightly lower overall pay conversion. This variant’s performance also hints at the impact of pricing (the 30% annual discount on web) might have influenced some users’ decisions. More testing would be needed to see if a smaller discount (or no discount) with dual options would perform differently

Revenue per user: Web vs IAP in dollars and cents

Conversion rates tell only part of the story. A big motivation for pushing users to the web is economics: avoiding the app store tax means developers keep more revenue per purchase. Our experiment tracked revenue per user in each variant, so we can assess if the higher net revenue share from web purchases makes up for the lower conversion

metric	IAP only	IAP + Web	Web only
Customers	3,127	3,191	3,113
Paid Customers	198	187	166
Conversion To Paying	6.30%	5.90%	5.30%
Revenue	$9,324.00	$7,865.00	$6,508.00
Revenue Per Customer	$2.98	$2.46	$2.09
Revenue Per Paid Customer	$47.09	$42.06	$39.20
Proceeds (30% & 6%)	$6,527.00	$6,188.00	$6,111.00
Proceeds (15% & 6%)	$7,925.00	$6,941.00	$6,111.00
Proceeds Per Customer (30% & 6%)	$2.09	$1.94	$1.96
Proceeds Per Customer (15% & 6%)	$2.53	$2.17	$1.96

The gross revenue per user (i.e. average revenue per user before any fees) was highest in Variant B (IAP only) at $2.98 per user, and lowest in Variant D (Web only) at $2.09. In other words, on a pure revenue basis each user in the web-only group generated only about 70 cents on the dollar compared to each user in the IAP group. Even Variant C (mixed) was around $2.46 per user, closer to B but still ~17% lower gross than B. This makes sense given the conversion differences: fewer people started trials and became paid in the web cohort, so total revenue per user suffered

Now, once we factor in fees, the picture gets a bit more nuanced. Under Apple’s standard commission (30%) and typical web fees (~3–5% on web – we modeled ~6% based on the total costs, including chargebacks etc, that we’ve measured for Dipsea), the net proceeds per user in Variant B was about $2.09, whereas Variant D’s was about $1.96. That narrows the gap: web-only users brought in roughly 94 cents on the dollar of the IAP-only users in terms of actual revenue retained by the business.

Essentially, the web flow earned less money from fewer conversions, but you get to keep more of each dollar, partially offsetting the loss. Variant C’s net was ~$1.94 per user (blended, since it had some IAP and some web).

It’s important to consider Apple’s Small Business Program implications too. Many developers (making under $1M/yr) pay only a 15% App Store commission. In that scenario, the disadvantage of web is not up for debate. If Apple’s cut were 15%, Variant B’s net per user would be ~$2.53 versus D’s $1.96. Web-only would then deliver just ~77 cents on the dollar relative to IAP. As our initial conclusion hinted: if you’re only giving Apple 15% already, driving users to the web is likely a net loss in revenue. And even at 30%, our data shows a web strategy isn’t a slam dunk increase in LTV: you save fees but lose conversions, and in our case net revenue was still a bit lower

One more factor: the absolute revenue difference in our test favored IAP. Variant B (IAP) generated ~$9,324 in gross revenue from that cohort vs. ~$6,508 for Variant D (web). After fees, that was ~$6.5k vs ~$6.1k (with 30% fee). So about a 6.5% net revenue shortfall with web. This gap might be acceptable to some developers if it means not sharing revenue with Apple, but it’s not the free 30% boost some might expect. Every app’s math will differ, and you should absolutely run an experiment, but the key is to weigh higher margins against the drop in sales volume

UX Matters: Why we believe web flow currently converts less (and could we improve it?)

It was eye-opening to see just how much conversion dropped by adding a web checkout, even with a seamless handoff. The user experience friction is real. In our Variant D flow, after tapping “Subscribe” users had to leave the app to enter a web browser, potentially input payment details, and only then return. In Variant C, tapping the “Save 30% on web” button did the same thing. It’s no surprise many users gave up along the way.

Note that there’s been some talk about opening an in-app browser to handle the web purchase flow, but based on what happened to Patreon and others, this particular way of handling the web purchase is being rejected by app review (even if some sneaked through in the early confusion after the anti-steering ruling dropped)

There are a few ideas (and now, some updates) to mitigate this:

• Streamlined Web Checkout: Since the experiment, our team has been improving the Web Purchase Button and Web Billing flow to reduce friction. We’ve worked on making the redirect and return-to-app experience smoother, and released the Apple Pay button which we enabled on checkout for this Dipsea experiment ahead of general availability. Some of these improvements weren’t live when we started the experiment, but could theoretically lift web completion rates in future tests
  
• Better Messaging: We hypothesize that clearer up-front messaging could help set expectations. In Variant D, tapping “Try for Free” suddenly launched a web browser. Some users may have been surprised or hesitant. A future iteration might use a phrase like “Continue on Web” or an intermediate prompt explaining the secure external checkout, to reduce confusion. Variant C at least explicitly said “…on our website and save 30%,” which might be why a decent chunk still engaged with it. But even in C, users might wonder why they’re being sent to the web. Educating users that they can subscribe on the web for a discount (and still use the app afterward) is key

Ultimately, polishing the web checkout will only go so far. A slicker hand-off, Apple Pay, or crisper copy might claw back a few percentage points, but for the majority of apps a brower-based flow is likely to convert worse than a simple one-tap IAP. The pragmatic play is clear: run a quick A/B test, look at the delta in paid conversions, and if your web variant is down anything like the 25-35% we saw here, accept the verdict and aim your product and growth energy at bigger wins. If you do see some merit in web-base flows, our team is already iterating on our Web Purchase tooling to close the UX gap:

As of last week, Paywalls v2 lets you decide, per button, which purchase flow to prioritise: in-app purchase, direct web checkout, a web product-selection page, or even your own custom flow. That means you can now mix-and-match buttons (or have one smart button) that seamlessly routes each user to the best path, without hard-coding a thing. The feature is live for all US iOS apps and described in our updated documentation for the web purchase button

We expect these changes to improve conversion as the user will hit fewer surprises in the hand-off,. The new Web Purchase Button skips the extra “which product?” page when you only want a single plan, supports Apple Pay in Safari, and automatically invalidates cached customer info so entitlements appear the moment a user returns to the app. (You can even auto-dismiss the paywall on return: see the new Auto dismiss toggle in Paywalls v2). Note that most of these were tested in Dipsea during this experiment, so the data here includes features like Apple Pay

If you ran this experiment in your own app, look at the drop-off points – is it at the point of leaving the app? On the web form? Consider adding analytics or even a quick user survey to pinpoint friction

Listen and learn

We just published a Sub Club episode filled with relevant insights and conversation: “What Reading.com Learned Testing Prices & Funnels” with Tim Dikun (Teaching.com). Tim and David dig into web-to-app funnels, why trust signals are the secret to getting users to pull out a credit card on the web, and how money-back guarantees can outperform free trials in external purchase flows. If the conversion-vs-margin dilemma in this post has you thinking, this 45-minute chat will spark even more ideas. Find it here, on your favorite podcast player, or watch the video on YouTube:

You can also join the conversation live today: David is unpacking the Epic ruling and web-payment experiments on a free webinar with Paddle: “Epic vs. Apple’s ruling: Lessons one month in and what to do next.” Seats are limited and the session starts later today (check the landing page for your local time). Save your seat here

Conclusion: Weighing the trade-offs and next steps

This experiment provided a wealth of insight into web vs IAP subscription purchases. To sum up our findings:

• Web flows do not deliver a free conversion boost, in fact they significantly hurt initial conversion. The convenience and trust of native IAP still leads more users to start a trial or subscribe immediately. Any developer considering a web option must prepare for a drop in initial conversion rate
  
• Users converted via web could have a higher LTV (lifetime value). We saw higher trial completion and slightly higher conversion-to-paid rates for web subscribers. This aligns with the idea that the extra friction filters out less-committed users and that canceling outside the app (or via email support) is enough of a hurdle that more trials convert by default. We expect this to lead to slightly lower churn rates as soon as the first batch of renewals comes up
  
• Revenue per user was lower with web-only when factoring conversion, although the gap narrowed after fees. If you’re paying 30% to Apple on IAP, a web strategy can recoup some lost ground, but in our test you still made 6 cents less for every dollar. If you’re only paying 15% to Apple, the math tilts heavily in favor of sticking with IAP for maximum revenue
  
• Dual option (IAP + Web) can capture some upside without imploding conversion. It’s not magic (we still saw a dip in initial conversion) but it gave users choice and resulted in the highest trial conversion rate and only slightly layer overall pay conversion compared to IAP. This suggests a segment of users will take the web offer if presented, and doing so can marginally improve subscriber quality. The key will be optimizing how that choice is presented (and possibly experimenting with the discount amount or messaging)
  
• User experience and trust are critical. Many users are conditioned to the one-tap in-app purchase. Heading to web introduces uncertainty. So execution matters: clear messaging, smooth checkout, and perhaps incentives (like a discount) are needed to make web competitive. The more we as an industry refine the external purchase UX, the better these numbers will get

So, is it worth adding a web purchase option? It depends on your situation, and in many cases it’s worth experimenting for yourself (we only tested this with Dipsea, after all).

If you’re a larger developer paying Apple the full 30%, even a small net uplift in kept revenue could justify it, but you’ll need to invest in optimizing the flow to not lose too many conversions, and the added complexity of subscribers that are managed across different platforms is definitely a downside. If only there were a platform that handled that entire mess for you…

If you’re a developer on the Small Business Program, sticking to native IAP will likely yield more revenue and subscribers for now. There’s also the middle path: maybe route certain segments to web (for instance, power users who hit a paywall wall after using the app for a while, or users on platforms where you can communicate benefits of web billing, or – as described at length in a recent blogpost – an existing audience of users that you can sell a subscription before they download your app), while keeping the default flow in-app.

We’re entering a new era of flexibility, which means lots of testing opportunities. What we learned from Dipsea is a starting point, not the final word. We’ll continue to monitor the long-term metrics from this cohort (renewals, churn, LTV over months) to see if the web vs. IAP gap widens or closes over time, and will come back with an update once those renewal numbers come in. We’ll also be testing improvements in the web checkout experience to see if we can close that initial conversion gap. And as always, we’ll share our findings with the community. If you’re interested in running a similar experiment, RevenueCat’s latest SDKs and tools (including the Web Purchase Button and Web Billing) make it easier than ever to set up, and we’d love to hear what your results look like

——–

May 14th blogpost: Apple opened the door to web paywalls — our test shows it might hurt conversions

This is a copy of the full blogpost we shared on May 14, at which point the experiment was a week old. In it, we focus primarily on the experiment design and initial conversion rates

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.