New rules: WTF does it all mean?

Apple lost to Epic, what now?

(someone must have enjoyed writing this portion ^)

New rules:

• Apps on the US storefront are not prohibited from including buttons, external links, or other calls to action

• On the US storefront, there is no prohibition on an app including buttons, external links, or other calls to action

• The prohibition on encouraging users to use a purchasing method other than in-app purchase does not apply on the US storefront

• …no External Link Account entitlement required for apps on US storefront for all of this

That’s the easy part. Now the hard part.

WTF does it all mean for you?

Look, anyone who tells you they know confidently is lying. The short answer is we’ll have to wait a little to see how it all shakes out.

But I’ll do my best.

First, at an operational/implementation level, what can you now do?

• You are allowed to link out of your app to a website with a web purchase flow, can discount this cheaper than IAPs, and can tell users whatever you want (E.g. “please go to our website, Apple is screwing us so we’re giving you a discount if you purchase on our website”)

• And Apple can’t take any commission from these external payments

But exactly how does that implementation work?

Do you have to open an external browser window outside of the app and users need to leave your app?

I don’t think so. It seems you’re allowed to open a web view within the app via a slide up “drawer" for users to complete the purchase.

Do you have to show both the IAP and web purchase option?

I’ve seen apps test this quickly using only one purchase button and see results.

Even if you need to add an IAP purchase option, you can make it not very visible so not many people will use it if you don’t want. Apple can’t control appearance or messaging.

At the moment, the exact requirements are unclear, but I bet you’ll still need to support IAPs.

Can you embed Apple Pay directly into your app like you could for physical products?

This would allow you to use the same Apple payment card and be almost indistinguishable to an in-app purchase to the normal consumer.

There is nothing saying explicitly you can’t, so some seem to think so, but I’m skeptical.

Apple has to issue merchant IDs and controls how and where you can use Apple Pay, so I would guess they still try to control this usage.

I also bet we’ll see a wild west of testing and web purchase implementations that get past reviews for the short-term. So I wouldn’t be confident what gets approved today will get approved in the future forever.

Do it while you can, I guess?

Next, what are the business implications?

The obvious is that you can keep a greater percentage of your revenue.

IAPs:

• Under $1M: 15%

• Over $1M: 30%

Web purchases (we’ll look at Stripe for simplicity)

• 2.9%+30c - let’s call it between 3-4%

There are cheaper payment providers and more expensive, so Stripe is a decent middle ground.

So with simple math, you get 27% back. Pretty damn impactful.

But web purchases are not free.

Why?

Because you are now responsible for tax compliance and everything else that comes along with web payments.

Refunds, fraud, chargebacks, etc.

Obviously, the whole rest of the non-app world has been dealing with this, so it’s certainly not impossible.

The Merchant of Record platforms (e.g. Paddle) are big winners here.

I’m sure you’ve seen enough people say the above already, so this probably isn’t a new revelation for you :)

If you’re in the small developer program, should you start using web payments?

Probably not.

You’re still figuring out how to grow your business and focus is key here.

15% fee by Apple is worth the simplicity and ease it offers you.

And there is no guarantee you can get good enough conversion rates on web to beat that.

For larger developers at the 30% fee, it gets a lot easier to get a lower conversion rate, but still make more money with the higher take rate.

You also have to optimize different trial start and conversion rates, renewal rates, churn, and it’s much harder to really understand your business.

What if you’re a larger developer?

Many developers already use web to app purchase flows, so web payments aren’t new to them.

One of the advantages of these web to app flows is the better attribution data you get. I don’t believe this can be replicated from app web purchases.

This could be a huge win for a lot of apps that have strong brands. People will be much more willing to leave the app and come back for them because the trust is there.

https://x.com/vahebagdasar/status/1918358378952441920

Secret story time:

Multiple years ago I tested app to web purchase flows.

We used in-app messages that linked to Stripe checkout pages.

The in-app message functioned as a paywall.

We tested both web views that opened in the external browser as well as an in-app browser.

Obviously, the in-app browser performed better. People don’t need to leave the app and it kind of appears native. Not 100%, but it’s not bad.

At first we had credit cards only enabled and it sucked. And then we added Apple Pay.

And it started to work pretty decently.

It wouldn’t work 100% of the time though. And by work, I mean beat the IAPs.

We would A/B test this in-app message, so 50% would link to IAP and 50% to Stripe checkout page web view that would open within the app.

This would work decently well with discounted offers or promotions.

It usually had a lower conversion rate, but when we factored in higher renewal rates and higher take home revenue it sometimes won.

This was 100% against Apple rules at the time, but we would never do this for the first paywall shown, only for subsequent upsells (e.g. 1+ days out). Apple reviews go through the initial experience, but they’re not using the app for multiple days.

I will say, once we had full renewal data from doing it for 1 year+, we did see meaningfully better renewal rates.

But better renewal rates isn’t really news now, we know that generally, web purchases convert and renew better (but the initial conversion is usually worse).

What’s the moral of the story?

This isn’t a guaranteed win and should test it for yourself.

There will likely be instances where this makes sense and others where it doesn’t.

One other example:

RISE used to have Apple Pay natively in their app a few years ago (this screenshot is from quite some time ago).

Credit to Sylvain Gauchet for sharing

I believe they had to get special permission from Apple. They were offering a virtual coaching service (physical product) so they were allowed to use it for their subscription.

They stopped doing it a while ago though.

I’m not sure if this permission got revoked, they stopped the coaching, or if it just wasn’t worth it for them.

How should you proceed short term?

To be honest, probably nothing.

And by short-term, I mean in the next week or two.

I don’t think there is any first mover advantage and upending your roadmap to get something out here fast is probably a distraction for now.

(Unless you’re a pretty large app company and can moving some devs around doesn’t make much of an impact on your existing projects.)

Exactly what is allowed and not allowed will shake out soon, so if you start building and figure out it’s not the optimal solution, that kinda sucks.

You’ll also be able to learn from the early testers and start with a better baseline of what’s working and what’s not.

I would start thinking about how and where you could use web purchases.

Obviously, if you can get strong conversion rates for your 1st paywall on web, this will be the largest impact.

How should you proceed long-term?

You’re guess is as good as mine. I’m sure we’ll all find out soon.

Here are a few other ideas:

• I quite like for sales or upsells later on.

  • Discounted purchases could have lower CVR drop off because users have extra motivation

    • And if they’re already users of the app, they’ll have higher trust. But still gotta test it.

• I don’t really like BNPL (buy now, pay later) apps, but this could allow for these to be offered easily for higher priced items.

• 2nd payment options after the first paywall

  • Does it make sense to ask users if they’d like to pay using Paypal, Venmo, or other check out methods?

• More flexible subscription types

  • Is there something about your product where traditional IAP subscriptions is limiting?

  • 2 year long subscriptions

  • Lifetime purchases

  • Early upgrades

  • Babbel’s “Get 12 months free”

• Segment purchase options by user type

  • I’d bet that different user segments will convert differently. Try to learn over time if you should show different purchase options to different users

  • The most obvious split in my mind is age, but potentially, users are less motivated will convert better with a discounted IAP

  • And maybe users who have very strong motivation signals you can send to a web purchase?

• Do you have web-to-app purchase flows?

  • Can you bring all of those into your app and get higher conversion? Unclear.

    • You’ll still have attribution issues, but maybe it doesn’t matter.

    • There is usually lower conversion rates on web, but higher take home revenue and better attribution/optimization made it make sense

    • If you can get all these users through your in-app onboarding flow and then convert at nearly the same rate of an IAP, that will be an instant win.

  • Also, not talked about with web to app flows, there is huge drop off from getting users from your web purchase flow actually into your app, so it’s hard to build a long-term recurring business.

    • Having web purchases in your app should be a net positive to build an engaged, retained user base.

  • I’ve heard that it can be as high as 50% of users from web flows never do anything meaningful in the product (activation or other core product action)

Lastly, how will this impact acquisition and attribution data?

You should be okay and there shouldn’t be too much impact compared to standard mobile app acquisition.

I believe web to app flows will still have more complete attribution data (if you purchase on web), but you should still be fine with web purchases from the app.

I got some help from Shuan Salim and Jakub Chour here, but your MMP should handle this okay.

You can send these events via a server connection back to the ad network (all MMPs support server side connections).

Or, you could also use the iOS webview handler to send the events back.

https://support.appsflyer.com/hc/en-us/articles/207031976-In-app-events-for-hybrid-apps

Also, depending on how you manage your subscriptions in-app, your revenue/subscription management tool might also have direct integrations back to your MMP or to the ad network and can send the data via that integration.

For example:

1. The purchase gets processed via Stripe

2. Stripe sends that purchase data back to your revenue infrastructure tool

3. Rev. infra. tool maps it to the user because you passed back a user_id via Stripe metadata. Rev. infra. also tracks IDFA so it connects the purchase

4. This purchase or trial conversion gets sent back to the MMP to send to the ad network. Or your Revenue Infra tool sends it directly to the ad network

Let me know if you see anything incorrect here!

And to wrap it all up, there have been some promising early results from testing!

One more shout out for Vahe who shared that he’s seen some positive results so far:

Have you tested any web purchase flows from your app??

Let me know what you found!

---

There is still time to go to MAU!

Early bird pricing is over - but MAU was kind enough to share a special code for you all.

Use RETENTIONVIP to get comped passes.

MAU is also doing some new cool stuff this year like their Clubhouse. Want a discount? I got more promo codes for ya:

• RETENTIONCLUBFD (25% full day passes; value $75)

• RETENTIONCLUBHD (25% half day passes; value $50)

• RETENTIONAGENCY ($300 agency passes)

• RETENTIONVENDOR ($500 solution provider passes)

Here’s some info on the Clubhouse: MAU Clubhouse | MAU Vegas 2025

---

📣 Want to help support and spread the word?

Go to my LinkedIn here and like, comment, or share my posts.

OR

Share this newsletter by clicking here.

---