The pros, cons, and “gotchas” of the new US ruling on external iOS payments 

If you spend as much time as I do scrolling on LinkedIn, you’ve probably seen tons of posts flood your feed about the new US ruling which:

1. Forces Apple to allow iOS apps in the US to link to external payments
2. Prohibits Apple from taking commission from the payments (no extra fees!)
3. Prohibits Apple from throwing up those biased warning interstitials that tank click through rates.

A great day for everyone working in the mobile app industry.

But all of the posts I’ve seen pretty much focus on how this means developers will save fees. Up to 27% by taking payments on the web as opposed to in-app.

Don’t get me wrong — this is a big deal!  And on the surface, seems like the primary reason to jump on this as soon as possible.

But there’s a but!

As with all things there’ll be advantages and disadvantages to leveraging external payments that will come out over the next few weeks as developers get the first batches of data in from experiments. But based on the data I’ve seen from thousands of mobile growth experiments I have a few predictions on what we might see.

Before launching any growth experiment, I’m a big advocate of defining a hypothesis and performing a premortem analysis to help minimise unexpected outcomes and prioritise initiatives. So let’s do that together!

Premortem analysis

Starting with the hypothesis that we’re seeing on LinkedIn:

“We think that switching to external payments in our iOS app will lead to a 27% gain in the US from reduced fees”.

Assumption 1: There won’t be any additional costs that reduce the 27% gain

I’d argue, this is the most dangerous, common and costly assumption being made.

Subscription app teams aren’t used to having to manage the payment relationship with the customer directly. When selling through the App Store, Apple does a lot of the heavy lifting behind the scenes that saves developers time, money and gives them peace of mind. But when implementing external payments, all of a sudden new responsibilities land on developers.

That means dealing with chargebacks, refunds, payment fraud, delinquent payments, sales tax compliance – the list goes on. And handling this in-house is no easy job; sales tax is not the same in every state! It’s very easy for costs to add up building an infrastructure for this, which could easily eat into the 27% gain. And for smaller apps who are paying a 15% fee, it could significantly eat into the gain, which is already lower to begin with.

Once more developers become aware of these factors, I anticipate we’ll see a larger number of app companies adopting a Merchant of Record (MoR) like Paddle and/or a tool like RevenueCat’s Web Billing to sync subscriptions and entitlements across web and mobile.

Of course, for companies that have already scaled with web-to-app, they’ll have already considered this, but for everyone else – this will be a new hurdle to overcome. 

Assumption 2: Conversion through the funnel will remain constant

Apple is no longer allowed to add biased interstitial screens that “dissuade customer usage of alternative purchase opportunities”. And this is great news!

But they are still allowed to add a neutral warning that lets users know they are exiting the app and being redirected. Honestly, I think that over the mid to long term, users will get comfortable seeing this notice and will go through with the redirection without thinking twice.

However, at least immediately, this will mean friction on the UX side and increased drop offs. Ultimately a lower percentage of users will reach the checkout page.

And just as we often see lower checkout page conversion in web-to-app funnels compared to in-app purchases, this will hold true for external payments. Paying in-app with Apple Pay is an ultra-fast super smooth journey that web checkouts don’t perfectly replicate. (But I don’t this will always be a drawback…as we’ll touch on shortly)

Assumption 3: That it should just be pitted against in-app purchases

I hate to say it but even up to this point, in-app monetisation has not been the only option for developers.

web-to-app has been a thing for a long time now! And hundreds of apps have already scaled with these reduced fees and a breadth of other advantages.

Side note: I suppose this ruling will make “app-to-web” an official strategy…

But one advantage web-to-app offers that app-to-web doesn’t offer is on the attribution side. UTM tracking, mapping users and cohorts back to specific campaigns and creatives. This can’t be done with external payments leveraged by app-to-web funnels.

Ultimately attribution never has and never will be perfect – even web-to-app invites its own struggles. So whilst I don’t see this as something that should nor will stop teams from adopting external payments and seeing success, it’s worth keeping in mind.

But there are huge advantages no one is talking about

So maybe we don’t see a 27% gain. Perhaps it’s 20% or 15%. Time will tell. But fees aside, there are several other potential advantages from this ruling which could make app-to-web even more appealing. 

1) A cash flow flywheel to help scale up your user acquisition

One big pain of scaling profitable user acquisition has been the time it takes to actually get access to money that users have paid you.

With Apple’s payout cycle and bank processing times, it can take up to 60-65 days for the users’ payment to land in your bank account after it has left theirs. As if it’s not already a big enough challenge to build out a profitable paid user acquisition engine!

In fact, it’s such a big pain point that there are now companies that offer platform earning advances and other  financing options based on pending payments from Apple.

But as with all financing, not every developer can access this. Well, fortunately, now they don’t have to.

MoRs like Paddle and PSPs like Stripe, pay out significantly faster than Apple. Rather than having to wait 65 days to get your proceeds, you can get your money the same week, even as fast as the same day in many cases.

This has been a web-to-app advantage I’ve spoken about before. But it applies to app-to-web now too.

This is huge when it comes to rapidly scaling paid acquisition. Especially for bootstrapped teams without access to external funding.

2) Increased trial conversion rates

I’ve seen and discussed web vs app metrics for close to 100 apps. One thing I’ve seen time and time again is a higher trial conversion rate on the web when compared to in-app.

Not all the time, but often.

Now granted, this is primarily down to a lack of reminder emails and the more complex UX journey that have come with cancelling a mobile app subscription on the web.

And with the Click-to-Cancel Rule coming into play in a couple weeks, these ‘grey patterns’ are being cracked down on. So the jury’s out on how exactly. But I do still think we’ll see trial conversion rates increase on average, at least in the short term.

Because the UX of cancelling a mobile trial on the web inherently has more friction, at least a little, than cancelling a trial from the app store.  And it’s certainly a process that users aren’t all that familiar with yet.

3) Stronger revenue retention

And the same applies to revenue retention. One of our clients at Perceptycs saw a 3x increase in year 1 renewals from users who purchased on the web compared to users to purchase via the App Store.

Now 3x is definitely a red herring.

But time and time again we see higher renewal rates on web revenue versus in app revenue. I anticipate that we’ll see these for app-to-web flows too.

Again, Click-to-Cancel, will close the gap here. But, and I hate to say it – I do still foresee developers abusing these patterns in the short to mid term. A ruling is one thing. But it’s not so easy to monitor and take action against these practices on the web – especially when it comes to international developers selling to US users.

4) A UX match made in heaven

Here’s where things get more intricate. At App Promotion Summit London this year, I led a roundtable discussion on web-to-app strategies. And one developer shared that the reason they’ve never invested time in web-to-app is because it just doesn’t feel native to them.

He said, ‘Surely users would rather pay directly in-app. It’s the way they’ve always done it. The checkout process just wouldn’t be as smooth on web’

And there is a lot of truth in this. I mentioned it earlier. 

But it’s not always the case. In fact I have examples of the opposite being true.

For one app, we’ve seen that older users actually prefer to pay by card on the web as opposed to paying with Apple Pay. For them – paying for things on the web with a card is safer and more familiar than paying by double clicking and scanning their face in an app they’ve just downloaded.

Well, with app-to-web, developers can customise payment methods and offer different user groups different checkout options. Something that’s not been possible up until now.

This is something that I’m really excited about testing with our clients–building different Paddle checkouts each with different payment options based on the first party data we’ve collected in-app.

5) A level playing field for freemium apps.

Up until now I’ve told a considerable number of developers to keep taking payments in app, not to be distracted by web-to-app, not to build out web funnels and not to take payments on the web.

The reason for this has been that the journeys available just haven’t been anywhere near as intuitive or user friendly as taking payments in the app.

Take a utility app, a storage cleaner with a freemium model. web-to-app makes no sense for them. 

The core value that convinces users to convert is experienced after signing up, setting up the product and giving it a try. This is the fastest way to deliver the aha moment to users.

Sure, they could try and force an onboarding quiz on users, or have them purchase a subscription directly after hitting a landing page – and in some cases this might work. But trust me – from experience – in most cases, it probably won’t. Especially not to the extent where it makes sense to turn off direct to app campaigns.

But now there is a middle ground!

Keep directing traffic straight to the app, keep pushing users to that freemium experience and then guide them towards a web payment.

RevenueCat’s new Web Paywall Button makes it super easy to implement this.

Net-net what will we net?

At this point, the jury’s out on how this will actually impact metrics. We’ll have to start implementing and testing. But it’s safe to say that I’m pretty excited about what this means for app teams around the world. 

The best part is that I don’t think it’s just developers who will benefit from this. In many cases I think app developers will pass on at least part of that saving to users in the form of discounts and offers to edge out a competitive advantage. Particularly in crowded markets like health and fitness.

Think about it, developers might be able to extend an additional 20% discount to users and still net higher proceeds from that user than if they charged them a 20% higher price in-app.

And whilst it might not be as simple as adding a Web Paywall Button for the first time and seeing a 27% uplift, when you stack up all of the benefits – external payments could change the game and propel app-to-web into a go-to growth strategy for many developers.

All that’s left is to get building, shipping, and experimenting!