App Review Guidelines Updated for Epic Anti-Steering
Apple (e-mail, Hacker News):
The App Review Guidelines have been updated for compliance with a United States court decision regarding buttons, external links, and other calls to action in apps. These changes affect apps distributed on the United States storefront of the App Store, and are as follows:
3.1.1: Apps on the United States storefront are not prohibited from including buttons, external links, or other calls to action when allowing users to browse NFT collections owned by others.
3.1.1(a): On the United States storefront, there is no prohibition on an app including buttons, external links, or other calls to action, and no entitlement is required to do so.
3.1.3: The prohibition on encouraging users to use a purchasing method other than in-app purchase does not apply on the United States storefront.
3.1.3(a): The External Link Account entitlement is not required for apps on the United States storefront to include buttons, external links, or other calls to action.
I’m still not really sure what this all means, but it seems to be in line with what I suggested yesterday: it’s US-only, and there are still many places where you have to use IAP. External links are allowed for digital content and services. I take this to mean not apps themselves or feature upgrades. (The exception is that if you support Android or Windows and track the user via an account, Apple lets you avoid its fees by unlocking via that account.) So I think it’s not a big change for most indie developers, but it is potentially a big deal for Apple because most of the App Store (and thus services) revenue comes from cross-platform game content. (On the other hand, maybe a lot of the sketchy purchases wouldn’t happen without IAP, so Apple will keep that revenue.) It’s not clear to me whether Kindle and Patreon are allowed if they don’t also support IAP.
Here are some parts of the App Review Guidelines that have not changed (emphasis added):
If we can’t understand how your app works or your in-app purchases aren’t immediately obvious, it will delay your review and may trigger a rejection.
[…]
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc.
[…]
3.1.1(a) Link to Other Purchase Methods: Developers
may apply for entitlementsto provide a link in their app to a website the developer owns or maintains responsibility for in order to purchase digital content or services.[…]
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app.
[…]
3.1.3(d) Person-to-Person Services: If your app enables the purchase of real-time person-to-person services between two individuals (for example tutoring students, medical consultations, real estate tours, or fitness training), you may use purchase methods other than in-app purchase to collect those payments. One-to-few and one-to-many real-time services must use in-app purchase.
[…]
3.1.3(g) […] Digital purchases for content that is experienced or consumed in an app, including buying advertisements to display in the same app (such as sales of “boosts” for posts in a social media app) must use in-app purchase.
[…]
3.1.4 […] App features that work in combination with an approved physical product (such as a toy) on an optional basis may unlock functionality without using in-app purchase, provided that an in-app purchase option is available as well.
[…]
3.2.2 Unacceptable (i) Creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection.
But note still not even the slightest largess from Apple - US storefront only. So additional complexity and hence disincentive for the vast majority of us who of course sell worldwide.
They are really going to fight this until the last drop of developer blood is spilled…
How are they going to differentiate between storefronts? Are they going to ask for separate IPA’s? Are they going to have it where it’s a feature flag based on region? Is it going to be up to the app developer?
At least how this is written right now, it seeeeems like there is no mandate to link out.
- in other words, a Stripe Apple Pay button can be directly in the app
- or the entire paywall could be a webview, with the button right there in it
John Gruber disagrees (Mastodon):
This does not mean apps can now use alternative payment processing in-app. It doesn’t even mean apps are no longer required to offer Apple’s IAP in-app for purchases and subscriptions. All it means is that apps (in the US for now, but Apple really ought to make this worldwide, but I suspect Tim Cook wants to fight this on appeal in federal court) are free to inform users about offers available on the web, and to link to those offers on the web. Those links must open outside the app, in the user’s default web browser.
The guidelines are not very clear. One interpretation is that you still need to use the ExternalLinkAccount API; the only difference is that it’s not gated by an entitlement. But I don’t think it can be that simple because that API relies on a single predefined URL in the Info.plist, which Judge Gonzalez Rogers found to be too restrictive. Another interpretation is that the API associated with the entitlement is what’s no longer required; you can just use the regular URL APIs. Guideline 3.1.1 would seem to still prohibit non-IAP purchasing within a Web view in the app.
lol this doesn’t make any sense. The only reason the link out requirement was there is to create friction to minimize revenue impact… now the friction is gone, if they keep that, it’s only about making iOS customer experience worse, which would be weird.
It’s not weird: it’s maintaining as much friction as legally allowed, which has been the goal all along.
Bookmark that thread – it’s becoming the running logbook of clarifications and edge-case discoveries as the news settles
[…]
Relying less on Apple’s IAP can simplify development and testing. You won’t need to deal with Apple’s sometimes laggy review process for price changes or new IAP products, since web purchases can be adjusted server-side. Bug fixes or improvements to your external purchase flow can be deployed instantly on the web.
If you support countries other than the US, it complicates development because now you have two parallel systems to maintain and test.
These moves by big players aren’t surprising, and I’m sure we’ll see more companies explore ways to take advantage of Wednesday’s ruling. Over time, though, the more interesting consequence of Wednesday’s ruling will be whether and how it changes the business models of indie developers and other small businesses that offer apps.
My current plans are to sit tight and see how the App Store changes play out.
I doubt that Apple would win on appeal, but who knows. Also, my business model is upfront paid, which would mean I’d have to go through the ordeal of switching to IAP in order to take advantage of the new App Store rules.
It’s not clear that I’d even benefit, because I’m already in the small developer program with the lower 15% fee.
My initial thought for indies on App Store Guideline changes:
Don’t rush into anything. Watch the market and give it six months to shake out tweaks to the guidelines and App Review process, and for possible other payment options to stabilize their integrations, options, and fees.
If you jump on something, you may just create a lot of headaches and migration work in the coming months that distracts from delivering value to your customers.
Previously:
