Selling in your mobile app? Let’s save you some money!

Doing business with Apple and Google certainly comes with well-publicized drawbacks. While their ubiquity and powerful development SDKs have created countless opportunities for app-based businesses, these tech giants have imposed restrictions and rules that have sparked controversy for years. A particularly contentious rule in recent months concerns in-app payments (IAP). Apple and Google mandate that apps offering digital goods, subscriptions, and premium content must use their native payment solutions, securing a revenue share often referred to as “The Developer Tax.” This requires apps to fork over 15%-30% of any subscription or sale revenue made within the app.

While continuing to hold out hope for the ongoing legal challenges worldwide, many teams are finding innovative ways to mitigate the impact of these revenue share requirements. Here, I highlight some recent changes teams should be aware of on the Apple side of the house while also elevating creative solutions you may wish to explore as you aim to minimize the impact of “The Developer Tax”.

So what’s there to know?

Apple and Google offer similarly capable payment SDKs aimed to help apps collect payment and unlock recurring or consumable experiences on their platforms. In fact, unless you fall under one of their specific exemptions , this integration is required. At least, that was until recently. In response to pressure from the European Union and the loss of an antitrust case earlier this year, Apple has eased up on two key restrictions that open the doors to new opportunities. Those changes were:

1. Apps may now promote and inform users of alternate ways to purchase or subscribe to content, both in-app and out-of-app. Before this change, Apple retained the right to reject applications if they shared it was cheaper to purchase outside of the app and even held apps back if they found out that users were targeted with emails directing them to alternative purchasing solutions.
2. Apps may now link out to third-party payment providers to complete purchases in-app. That is, with some key restrictions. Offered with the request of a special entitlement, Apple now allows you to insert static links to third-party payment experiences so long as they meet their list of highly prescriptive requirements .

While the remediation efforts produced by Apple are not a full sail win for developers, this does bring about more flexible opportunities when building on Apple operating systems.

So how do we avoid “The Developer Tax”?

When accepting these guardrails and restrictions, app developers can find new opportunities to get creative and push the limits of how we can collect payment as an app-based business. While there are many ways to attack this issue strategically, I want to highlight 4 creative solutions that developers have been using to mitigate and even sometimes completely avoid Apple’s in-app purchases revenue share. Those are:

1. Supporting Authenticated Experiences Only. Developers are releasing products that only support users who show up with established paid accounts from other platforms. This effectively only enables a login function within their app while relying on places like the web to play the role of the top of the funnel.
2. Introducing “Free” or “Limited” accounts. Teams like Spotify have enabled users to create an account within the app, granting them “free & limited” access to the app while capturing just enough information to make them marketable through other channels. This allows them to promote their preferred payment method through owned channels like email communication.
3. Bundling with a physical good. One of Apple’s key exceptions to the IAP mandate comes if your service is dependent on a physical good. Creatively bundling services with goods can allow teams to bypass the requirement if you can prove the good is necessary to an external experience.
4. Adopting Apple’s external purchase link entitlement. Developers can request access to a special entitlement that grants them the ability to link out to a static payment flow using an Apple-authorized web session. That is, so long as you report sales back to Apple and accept a lessor revenue share agreement.

Focusing solely on Apple in this case, let’s take a look at the pros and cons of these approaches and review a few examples of products leaning into these tactics today.

#1. Supporting Authenticated Experiences Only.

While naturally limiting, one approach to avoiding the IAP revenue share is to restrict the use of your app to those who have already established a relationship with you elsewhere. Take time to carefully engineer your customer journey so that consumers find you first on the web or another digital property prior to engaging with your app. By focusing your attention on a strong acquisition strategy within a complementary platform, you can increase the likelihood that by the time consumers find your mobile app, they have already created an account and paid for your service elsewhere. That is exactly what HEY did as they launched their mobile email and calendar apps!

This approach is certainly a bit limiting as you are not offering a solution for users who find your app organically in the app store without a prior relationship. It also limits you from being able to take advantage of many app store go-to-market and growth tools. The restrictive user experience is the tradeoff you must accept when considering this route to avoid the revenue share requirements. However, with a detailed understanding of the journey you are promoting to your users, you may still be able to craft experiences for the happiest paths that support your business’ growth without forking over portions of the profits to Apple.

#2. Introducing “Free” or “Limited” accounts.

Taking a page out of Spotify’s book, some teams are creating new account access types and leaning into careful in-app copywriting to navigate the IAP guidelines. As exemplified below, one approach is to start by allowing users to sign up to capture their information and consent to be marketed to. In exchange, limited functionality is made available to users. After a user signs up, an email drip campaign begins informing them of the benefits and locations in which they can upgrade to a paid account.

One limiting factor of this approach is that the app can not link users to or directly instruct users on how to upgrade their accounts. This effectively dead-ends a user who may be looking to pay you as they navigate your app. Balancing this with creative copywriting and outside drip campaigns, many products like Spotify have been able to lean into this approach to completely bypass the revenue share without creating too cumbersome a user experience. As highlighted above, “You can’t upgrade to Premium in the app. We know, it’s not ideal.” is a creative approach to acknowledging the friction to the user but offering a slight teaser that this could be done elsewhere.

#3. Bundling with a physical good.

Several niche exemptions are offered that would allow a team to directly integrate with a third-party payment provider or roll their own solution. One of the most common has to do with a physical good being sold and delivering value outside of the digital experience. This most often comes to life when hardware is involved.

In the early days, many fitness products used this exemption. For example, you may use an app to purchase an exercise bike. Advertised with your purchase, you are gifted an annual subscription to the accompanying fitness content by the manufacturer. This strategy allows these providers to say that what was purchased was the bike and that all they need to do is validate a registration code to grant users access to their content. It is important to note that as many fitness equipment and content providers have grown in popularity, they wished to offer services to anyone who wanted to subscribe, even those who didn’t purchase their equipment. This required them to move away from this strategy as they couldn’t link access to the digital experience to the physical good consistently.

An approach like this can certainly unlock opportunities but is also limiting to growth organizations. Not all growth strategies can be pursued if you are tightly tied to the sale of physical goods. Soon enough, your team is likely to produce an additional service you want to offer to repeat customers. If there isn’t an additional purchase of a physical good that is to be used outside the digital experience, this could not be sold in-app without supporting in-app purchases.

#4. Adopting Apple’s external purchase link entitlement.

In direct response to the recent antitrust case, Apple has introduced a new developer entitlement that they are encouraging all developers to use if they are unwilling to integrate with the native in-app payments solution. A developer entitlement grants an app special permissions or capabilities that are not available by default and in this case, it allows you to do what Netflix is accomplishing below.

When the “External Purchase Link” entitlement is granted to a developer, it allows them to embed a static URL that launches a third-party payment flow in Safari. However, before the user is presented with that flow, a large native warning is given to the user. This causes a fair amount of friction as Apple announces the potential risks and tradeoffs that this presents to a user. This is not the only speed bump Apple produced with this solution though. They also state that:

• External links can not contain additional URL parameters to pass along information like a preferred option or custom selection making personalization very difficult to accomplish.
• The payment window must be opened in a separate Safari window, ruling out the ability for it to be displayed in the context of the app using an in-app webview or alternative browser like Chrome.
• The URL must be statically defined when you ship the app. This means that if you wished to transition that URL in the future, you would need to ensure that all apps that have been shipped previously are updated or your payment flow would break.
• The external link can only be displayed in the app once. This means that if you display it during an onboarding flow, you can not continue to offer this in alternative ways throughout the app.

Those developers who are willing to put up with the interstitial warning and additional implementation guidelines are not fully off the hook when it comes to sharing revenue back to Apple either. Apple continues to charge a commission on any digital purchases initiated in this fashion within seven days from the link out — no matter where the purchase is made. This means that if a user taps this link but returns to the brand’s app on a desktop computer to purchase within seven days, Apple is supposed to get 27% of that revenue. While self-reported, this added financial burden and friction is seemingly designed to discourage the adoption of this flow by developers.

So what should I do?

The payment requirements and capabilities made available by Apple and Google are some of the most dynamic and evolving areas of their business. You’ve already done the hard work of building an app that people are willing to pay for. With some thoughtful and clever design and some preparedness for not if — but when — the rules change, you can keep more of your hard-earned revenue while still providing your users with an experience that feels safe and familiar. All of these workarounds offer value along the way but certainly come with steep tradeoffs. Weighing your options regularly is critical so that you can remain flexible in your approach.

Jack helps teams strategically navigate the Apple & Google ecosystems at Livefront .

• Jack Cunningham

  Director, Product Management

  More from Jack