Epic v. Apple, 10 months later: How are teams growing faster with IOS External Payments?

What’s changed, what’s stayed the same?

For many app-first teams, uncertainty about scope is the biggest blocker. The perceived impact feels larger than the reality.

Here’s how the teams we speak to already using App2Web (External Payments) flows describe it. 

What changes

• Checkout moves to mobile web. Users are routed from an in-app paywall to a browser-based checkout.
• You control pricing and payment methods. Discounts, bundles, refunds, and trials are no longer constrained by App Store rules.
• You take on the responsibility Apple used to handle. Tax, compliance, fraud, billing support.
• You keep more of the revenue, avoiding the App Store’s 15-30% fee.

What doesn’t

• Distribution and discovery. App Store presence, ASO, and Features remain unchanged.
• Core product experience. The app remains the primary place users engage and convert.
• Entitlement logic. Purchases still map cleanly back to in-app access.
• In-app purchases. Most teams continue to offer IAP alongside web checkout.

The shift teams didn’t expect

Some app leaders have hesitated adopting External Payments, concerned that it means fully abandoning Apple’s system. From what we’ve seen that’s rarely the case.  

In many cases, External Payments doesn’t necessarily replace the App Store, but complements it. Almost all successful implementations we’ve seen keep In-App purchases alongside External Payments. 

External payments for teams selling in the US often means more choice for the customer, not more restrictions with minimal conversion impact. 

What does the data say? 

After 10 months of real-world adoption, the data is clearer: minimal conversion impact, meaningful gains in net revenue, revenue per user, and LTV.

*Data is aggregated from Paddle customers & RevenueCat content.

Even with a modest dip in conversion, most apps see higher net revenue through an increase of revenue per user or/and LTV. 

The common myth that this conversion can only be attributed to an external flow is disproven in the data we have.

Providing mobile native payment options and a checkout that matches the UI of your app goes a long way in staving off conversion dips and some even see negligible dips in their conversion. Ensuring fast web page load times is absolutely critical here too. 

Web2App or External Payments?

There’s still no right answer 10 months on from the ruling: apps should experiment with every stream they can and find out what works best for their users and their revenue. 

One benefit of External Payments emerging derives from ASO and External Payments.

Driving users into the app from your ads first means:

• More installs
• More onboarding engagement
• Stronger ASO signals

Crucially, you can prompt for ratings and reviews during onboarding or immediately after a user passes the paywall. 

That’s something you simply can’t do with Web2App. But Web2App also has clear benefits over App2Web. Web2App still brings unique benefits around audience expansion and attribution that are unmatched. Ultimately both motions can go hand-in-hand and it’s down to the developer to experiment and find that balance.

How do I get started today? 

Start with a single External Payment route: one plan, one paywall, one checkout.

Ship it behind a flag if you want. Keep IAP live. Then measure and iterate.

1) Design the handoff first.
Before Safari opens, tell users what’s happening, why it benefits them, and what to expect after purchase. Don’t oversell it. The goal is trust and clarity.

2) Treat web speed as conversion infrastructure.
Measure the time from paywall tap to web “Buy” click—not just checkout completion. If that interval is long, you have performance issues, confusion, or both.

3) Keep the web experience familiar.
Match plan naming, benefits language, and pricing. Avoid surprises between paywall and web. Familiarity beats novelty in payments.

4) Keep Apple Pay on the web.
A common misconception is that leaving the app means losing Apple Pay. It doesn’t. And for iOS audiences, Apple Pay can be the difference between “marginal” and “works.”

5) Solve identity and return-to-app.
Use a consistent checkout/session ID so you can track the full lifecycle. 

Where possible, bridge identity so users land on the web already recognized. Use universal links for return-to-app with a clear fallback for edge cases. Post-purchase confusion is a trust killer.

This is enough to generate signals quickly without boiling the ocean.

The great misconception: “We need to rebuild payments”

A lot of teams assume External Payments means building a payments stack from scratch.

In reality, the hard part often isn’t the checkout UI - it’s the operational surface area that comes with web monetization.

When payments move to the web, you inherit what the App Store used to bundle into its commission: tax and invoicing, compliance updates, fraud and disputes, billing support, localization, and keeping payment performance strong across regions.

For many teams, that operational work is the real blocker, not the web flow.

This is also where partner choice starts to matter.

How teams get there faster with Paddle

Rather than redesigning App2Web flows, Paddle focuses on removing the operational and technical drag that makes them hard to execute well.

Teams use Paddle to:

• Launch quickly with a production-ready, mobile-optimized hosted checkout
• Support Apple Pay and Google Pay on the web for familiarity and trust
• Offload tax, compliance, fraud, and billing as yourMerchant of Record
• Maintain full visibility across the payment lifecycle with a single checkout object.

What the last 10 months have clarified

External Payments are not a guaranteed win. Poor execution can erase the upside.

The teams seeing the best results treat External Payments as a product surface.

They test carefully, keep in-app purchases live, and remove operational risk before optimizing for scale.