Apple External Purchase Link (developer.apple.com)

“Apple’s commission will be 27% on proceeds you earn from sales…”

Sadly this is only going to be a tax on small developers as the big ones already have amazing “deals” in place and they’ll figure out every way around this possible.

Overall, this sucks.

It feels just like the corporate income tax system that heavily favors those with enormous incomes.

Crazy idea – if Apple is going to go to the very edge of what is allowed under the court ruling, developers should go to the very edge of this new requirement as well.

Apple will demand to collect what they feel entitled to for all purchases initiated within 7 days (omitting any free trial periods)…

So it sounds like developers just need to implement web-based “special offers” for as much as possible.

Here’s a hypothetical user experience:

1. Our user is at a login screen, profile screen, or some screen not associated with “the purchase flow”.
2. The user sees a message that the main purchase in the app costs $X. If they were a previous user of the app, they might now notice that $X is 30% more than it used to be…or maybe 300% more? This is madness! No, this is the App Store. The user also sees a message that says “Special offers at ::link::”. User taps the link thinking “anything would be better than 300% more than this app used to be just a week ago.”
3. Our user now sees that once they’ve logged in or typed in their email address, the only thing available to them are special offers for 7 days of free usage on a subset of the full-app features. This is way better than 300% more than they would’ve paid a month ago. This begins the “purchase intent”, which is a hallmark of initiating a purchase – but no purchase has been initiated because no payment information has been provided so no purchase can ever be processed in its current state.
4. Our befuddled user adds their email address or receives a unique identifier upon “purchase” of the special offer that they will paste into the app to begin using their newfound features.
5. Faithful User goes back to the app which now prompts them for an email/code. The app knew they left to see special offers! Amazing. Our web store <-> user app linkage has been created. The developer can now target this user with push notifications or maybe even email marketing. The user’s special offer has begun and while purchase intent was had, there was no purchase completed. This is simply a special offer they’ve obtained that will expire after 7 days.
6. The sad indie developer pushes an update to increase the in-app purchase price even more and change how it’s displayed. The developer can’t understand how Apple could be so hostile to their web store payment process. “It isn’t this way on a Mac or PC.” For whatever reason, the developer decides that their full-unlock (only) in-app purchase with its inflated price should be displayed no more than once in app, on no more than one app page the user navigates to (not an interstitial, modal, or pop-up), in a single, dedicated location on such page, and that it will not persist beyond that page. I guess this developer just hates money – what a crazy thing to do!
7. The user’s special offer ends after 7 days. No purchase has been initiated so their access is lost. The developer withheld a key feature from the special offer as well that the user hasn’t been able to use. Did the user see that they’ve been missing this feature? Hmm…
8. A Push notification, email, etc., is sent to the user that directly links to the store page to tell the user “Hey, we see your special offer has ended – are you ready to buy the full package at 500% off?! By the way – there’s this super cool feature that will be included as well.” The user is ready for this amazing deal and new feature.
9. The user taps the push notification, makes the purchase now that it’s day 8 of the initial link out action and original purchase intent. The developer gets to pay their ~3% stripe fees and give zero dollars to Apple.
10. Some sorry sack buys the in-app purchase for 500% of its original cost five weeks ago. Damn. I guess everyone makes more money this way but this seems like a terrible experience for that user.

This dumb story gets around the ruling and seems to follow Apple’s guidelines to the best of my knowledge.

• The original purchase intent was stifled by seeing that no purchases were available on the developer’s web store – just special offers.
• There’s no free trial, only a limited feature-set “special offer”.
• The special offer ends with a loss of functionality after 7 days.
• On day 8 a push notification is sent letting the user know they’ve unlocked new offers/items in the web store.

 

Another thing these new Apple rules seem to miss is that there’s no wording in their ruling to say that you (the mobile developer) has to sell them the digital good. You just need to make sure the purchase link goes directly to your website with some other stipulations listed here:

• Uses the https scheme;
• Forms a valid, absolute URL;
• Contains no query parameters; and
• Contains 1,000 or fewer ASCII characters
• “Go directly to your website without any redirect or intermediate links or landing page”

That there’s no reason you couldn’t display a store on your web page that was actually run by another company. You could even protect user privacy and collect no data on these sales and ensure your app never talks to your website or APIs about user digital goods or services in a way that isn’t anonymized. It appears there are companies that will even help you do this. In this way, you’re agreeing to Apple’s rules but some other company is making the sale. Some company which hasn’t agreed to the same terms…

I do think the second method I mention here is riskier, as Apple can always just make up reasons to remove your app from the app store, but maybe we can see another Epic games try to test the waters and deal with those legal ramifications.