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:
- Court Orders Apple to Comply With Anti-Steering Injunction
- StoreKit Purchase Link Entitlement for United States
7 Comments RSS · Twitter · Mastodon
Apple deserves every bit of dressing down and punishment that they are getting from this judge.
All they had to do was acknowledge that the market today is very different from the market in 2008.
Instead of having a flat developer fee of $100 and percentage per sale, they should start differentiating between the developers based on company size.
The really big companies can work out who pays who what based on what they each bring to the table. For example, the Apple and OpenAI deal where Apple brings in customers and OpenAI brings the product but there is no exchange of money.
The mid sized companies pay Apple something like 10-20% of what they charge customers or an annual license fee in the range of USD 50k -500k. There can even be different fees based on differing revenues for different companies.
The flat fee can continue for small developers and hobbyists who build apps for themselves or do open source projects.
Everyone wins.
Customers get a one stop shop for buying apps and resolving disputes.
Developers can choose which bracket they fall in based on how successful they are.
Apple gets its revenue for services but in a way that is fair.
Instead we are getting another round of Apple tying to fit a square peg in a round hole.
Is rather see that the developer fee hours away completely, and then Apple drops their tax to 8%.
The idea that developers owe Apple money for making apples devices useful is backwards.
It would be possible for me to live without a smartphone but my days would be filled with many small annoyances to the point that I really don't want to try it.
This means that developers have made an iPhone or an Android phone an essential purchase. Apple should be fucking grateful. They have no right to the money other people work their asses off to earn.
We've gotten to the point where federal judges are pointing out dark patterns. Where Apple is deliberately, openly, admittedly making things worse for their users, developers, and literally everyone except Apple, literally only for money. That's got to be even worse than enshittification somehow, or maybe just its final form.
@Bart That's just enshittification, plain and simple. Every step of it is adding a dark pattern, anti-feature, or paywall purely for money, and for no one's benefit other than the company.
The final form is when all of the good will of every customer has been burned away and the company collapses on itself.
It is time.
For upgrade pricing.
What Apple did, or rather, what they've refused to do played a leading role in the absurd levels of enshitification we're living with today.
This feels like a class action lawsuit waiting to happen. Any company that had to pay the 27% vig will want to recover that, plus business costs related to the bookkeeping and auditing that Apple required. And if they are found in contempt of court, additional damages.
The one thing working in Apple’s favor is that the terms were so unfavorable that few apps probably used them.
@Nate there was a class action in Australia, one for Devs and one for Consumers - it concluded mid last year, and judgement is awaited.
