External Purchase Without a Separate App
Apple (Hacker News, MacRumors, tweet):
Apple is eliminating the requirement that developers of dating apps in the Netherlands who choose to use the above entitlements must create and use a separate binary.
[…]
Apple is providing updated and more-specific criteria to evaluate non-Apple payment service providers that developers of dating apps in the Netherlands may use.
[…]
Apps that use either entitlement need to include an in-app modal sheet that explains to users that they’re going to make purchases through an external payment system, and the potential impact that choice could have on the user. Apple is adjusting the language on the modal sheet and reducing the number of times the sheet must be displayed.
Before, the required language was:
Title: This app does not support the App Store’s private and secure payment system
Body: All purchases in the
App Nameapp will be managed by the developer “Developer Name.” Your stored App Store payment method and related features, such as subscription management and refund requests, will not be available. Only purchases through the App Store are secured by Apple.
It is now:
Title: You’re about to leave the app and go to an external website. You will no longer be transacting with Apple.
Body: Any accounts or purchases made outside of this app will be managed by the developer “
Developer Name.” Your App Store account, stored payment method, and related features, such as subscription management and refund requests, will not be available. Apple is not responsible for the privacy or security of transactions made with this developer.
Still charging 27%, though, so I don’t know why the ACM or the affected dating companies would accept this unless all they want is a token symbolic victory.
Fun loophole in Apple’s ‘dating apps in the Netherlands’ policy:
“[devs] using these entitlements will be required to provide [every transaction] that has been facilitated through the App Store”
However, external link policy prohibits parameters & only allows for a single link
[…]
So depending on your reporting/analytics practices and how you choose to implement this, you may have no data whatsoever as to whether a transaction has been facilitated by the App Store, or whether it was generated outside of the App Store
The big question for me is whether this purchase flow will be expanded beyond dating apps and outside of the Netherlands. It is becoming quite polished, and permitting it within an existing binary seems like a possible — albeit unlikely — path toward broader use.
Previously:
- External Link for Reader Apps
- Proposed Digital Markets Act to Require Sideloading
- Apple Submitted New Proposal to ACM
- Dutch ACM Wants Existing Apps to Support External Payments
- App Store External Purchase Fee: 27%
- StoreKit External Purchase Entitlement for Netherlands
Update (2022-04-11): John Gruber:
Baby steps, but all of these changes are in the direction of decreasing regulatory pressure. Apple can be stubborn but they’re not stupid.
I just confirmed YouTube has been skirting IAP rules by redirecting to Safari to process the card transaction themselves. Of course, now that I try again, they are showing proper in-app-purchase sheets. Seems like they were A/B testing it to see if they can get away with it?
Update (2022-04-13): Dave Howell:
I was cheesed when Phil Schiller, out of the blue, decided that the QuickTime 3 installer was going to cost developers a couple of bucks for every installation, with absolutely no way to help us track installs. Announced at WWDC with no warning. Boneheaded. Finally retracted it.
Nobody could answer basic questions like what if the user already has QT3 installed? Or what if they get a refund? Or what counts as an install vs a shipment, etc. The WWDR folks just said, in obvious exasperation, Dunno, ask Schiller.
