Hacker News Reader

Comment by somenameforme | Hacker News Reader

It seems easy to kind of shrug at this, but this does seem quite significant because of many mobile apps are 'free to play.' Apple pocketing 30% of all of these transactions, and forcing users/devs to go through Apple, is a major part of its revenue. And all of those apps now have the option to direct users to alternative payment methods, where they can both charge users substantially less and make more profit doing so. Should be interesting to see what happens!

View on HN

From the NPR article at the time[0]:

> Yvonne-Gonzalez was skeptical of the 30% fee during the trial, and in the ruling she was suspicious about Apple's justification of the commission, writing that "the 30% is not tied to anything in particular and can be changed," but did not order Apple to do so.

Nothing in the ruling[1] seems to prohibit Apple from still charging a "iOS License Fee" for access to the developer tools, APIs, etc. I can very well see them charging based on # of installs or % of revenue, even if developers direct people to an outside payment processor.

0: https://www.npr.org/2021/09/10/1036043886/apple-fortnite-epi...

1: https://www.documentcloud.org/documents/21060696-epic-v-appl...

Apple randomly guessing how many users would have bought the app through the store and charging that amount to another company sounds like an easy anti-competitive lawsuit.

They don't have to randomly guess, they'd ask developers who are using external payment processors to provide an accounting of the number of sales, with a clear paper trail showing that the developers certified that their numbers were honest.

It'd end up functioning similar to income tax: Apple has a pretty darn good sense for what the numbers should look like, but they'd rely on you to fill in the gaps, and if you didn't do so accurately they'd sue you for breach of contract.

I'm not sure what would make that an easier anti-competitive lawsuit than the one that Epic lost.

Let's say Spotify adds this in-app message: "Buy with Apple Pay, or visit our website and pay 20% less". No links, just simple text. How would anybody be able to produce a "clear paper trail"? Spotify can only say the total number of web purchases. Apple has no choice, other than to guess how many people would have bought through the app store instead.

If they decide to ban these kinds of messages, and only enforce link tracking, that would be directly in conflict with the ruling.

Spotify is in a category that already is a known exception for Apple [0]—they sell a subscription to media and they have an accompanying app. I expect the anti-steering provision to go away and for Apple to just eat the cost on that category.

Most apps that currently go through the App Store for sales are simple. There are sales for apps (or subscriptions), and they can be individually accounted. You and Apple both know how many users you have on Apple devices, and Apple gets a cut of sales to those users.

I don't like it any more than you do, but it's not hard to do the accounting.

[0] "A Licensed Application may read or play content (magazines, newspapers, books, audio, music, video) that is offered outside of the Licensed Application (such as, by way of example, through Your website) provided that You do not link to or market external offers for such content within the Licensed Application."

That only works for apps that are exclusive to Apple devices or that have separate licenses for Apple devices.

If I buy Epic in-game currency from Epic and use it on my PC to buy some skin, and then use the skin I bought that way when playing on my iPhone, should Apple get a cut of the money? If yes, how much? The cost of the skin, or the cost of the in-game currency (maybe I bought a 10 USD bundle, but the skin only cost 1 USD, the other 9 USD is just staying in my account unused)?

> Buy with Apple Pay, or visit our website and pay 20% less

Worth noting that they only charge the commission on In-App Purchases, which are "Not Apple Pay".

Apple Pay itself is just a way to pay with Wallet-saved cards and Apple only charges a nominal 15bp fee to the bankcard issuer.

> If they decide to ban these kinds of messages, and only enforce link tracking, that would be directly in conflict with the ruling.

Which part of the judgments would that conflict with? Both the District Court’s ruling and the 9th Circuit’s decision that affirms it only speaks of anti-steering, without any qualifications on potential limitations on steering users away

They also both affirm that the commission would still be due and that Apple would have the right to audit to enforce payment of said commission.

Apple, since then, has implemented changes to its policy that allow steering, albeit under circumstances that will enable them to track users using the purchase link and claim commission over sales in the seven days that follow.

Any opposition to these requirements would be met with a “legitimate interest” counterargument, the legitimacy of the interest already being established by the courts by them stating that they still owe Apple a commission.

In layperson’s terms:

The courts have said that Apple can’t prohibit developers from steering users to an alternative purchase flow while simultaneously stating that developers will still owe Apple the commission. Apple, in response, said: Fine, but we want to be able to track it when you do this and make sure you don’t make it look like the native IAP flow to trick users.

What’s the argument of the developers here? They’re allowed to steer users away to their purchase flow of choice; they just have to do it in a way that makes it easy for Apple to audit the owed commissions.

I can’t imagine the courts frowning upon this, especially when both courts have stated on multiple occasions in their judgment how arduous it would be for both Apple and the developers to ensure payment of commissions if alternative payment methods are utilized. This alleviates some of those concerns.

When an app is first opened it needs to validate the digital signature with Apple.

So they do definitively know the volume of apps a developer has sold.

StoreKit API likely phones home as well: https://developer.apple.com/support/storekit-external-entitl...

In fact, Apple is already pretty clear in its developer agreement [0] that the 30% commission is for "its services as Your agent and/or commissionaire" (Schedule 2 3.4), not for its services as a payment processor. They are contractually allowed to take the 30% fee out of payments collected, but merely using a different payment processor doesn't remove the obligation to pay them for their other "services as Your agent and/or commissionaire".

[0] https://developer.apple.com/support/terms/apple-developer-pr...

I think the main thing is they'd drop it to 26/27% to comply with how they can't perform anti-competitive actions to prevent developers from using another payment processor. If it was still a flat 30%, developers would be losing ~=3% more on every transaction with the overhead that comes with using another processor.

This is exactly what they are doing: https://www.macrumors.com/2024/01/16/us-app-store-alternativ...

I’m curious to see what devs do.

On the one hand Apple payments are really frictionless. There is no way 3rd parties can match it. Plus easy to track/cancel.

On the other hand a lower price is a lower price. But is it low enough to get enough users to enter a credit card?

Combine this with the alternate App Store thing (looks like EU only) and we’re in for some shaking out of what is and is not a good strategy as an app maker with never before seen on iPhone options in the mix.

> On the other hand a lower price is a lower price. But is it low enough to get enough users to enter a credit card?

An excellent question. I think the thing is that for the prices that often show up in apps, maybe not? Like, for a $3 app I don't think I'm going to go visit some website, go through their flow, and get out my credit card if I'm only going to save $1. (Ok, I'd probably do it on principle at this point to stick it to Apple, but that's not the same thing.)

If I were going to shell out $100, I'd certainly go to the extra trouble to pay $70 instead, though.

The dangerous thing is that with all these mobile games that slowly siphon money from you, you might over time end up spending many tens or even hundreds of dollars (where 30% off might be a significant amount of money). But if each transaction is small, you might not think much of the difference of a dollar or so per transaction.

I would expect from a developer's perspective it makes sense to stick with Apple's mechanism until ARR * 0.30 = whatever it costs to run your own solution. (More power to you if you're the developer who can do that from the start, but that won't be most people.) I wonder, though, if the slow siphon becomes more obvious if it's attributed, in a customer's credit card statement, to [Game Co.] instead of [APPL]. I won't be sad if fewer people spend money on those types of games.

I agree for the developer. But there’s the cost of users who don’t want to go outside Apple that you’d need to account for.

And right now we don’t know how big (or small) that effect is.

Exactly.

- no need to enter a CC number in another site (and maintain it)

- no need to create another account to make that payment (or unironically use Apple Pay flows)

- trivial cancellation

- trivial cancellation of limited time trials

Maybe I'm fortunate, stupid, or a combination but not being able to pay for Netflix using Apple subscriptions really bugs me and I'd pay more to avoid it. Which reminds me I need to cancel it...

Depending on the developer, there is also quite a lot of trust I need to impart on them too. I am reasonably confident in Apple keeping my data secure. I would likely be confident in it for the bigger apps out there, like your Netflix or Spotifys. But some rando app, would I be comfortable putting my personal and financial info on their server, instead of just using Apple's?

"But is it low enough to get enough users to enter a credit card?"

Well, Apple Pay makes that way easier. But that brings them back to Apple.

As far as I know, Apple Pay does not cost merchants any extra than any other card payment mechanism. Apple actually collects fees from the card issuing banks to be able to work with Apple Pay:

https://www.wsj.com/articles/apple-pay-fees-vex-credit-card-...

That's right, I just meant they have control over it and could theoretically exert that somehow.

At least apps can provide transparent options now. Your payment page could have a "pay us through the App Store" button that costs 30% more than the "pay us through our website" button, and explain why the numbers are different. Safari supports ApplePay, so your app could link you to a website which has a one-click payment option: no entering credit card details required.

Would be hilarious is Apple decided to make ApplePay less convenient in Safari now to hobble the competition.

It won't be 30% less. It'll be 10% less.

The vast majority of App Store transactions incur a 30% fee. The most common credit card fee is ~3%. It's gonna make a pretty big difference.

~3% plus costs of chargebacks, foreign exchange fees, time spent resolving disputes, customer service, etc.

App Store payments are independent of customer service for the app itself. App developers would have to provide that either way.

App Store refunds are not that different from credit card chargebacks. They mostly happen automatically, with some automatic abuse mitigation as well as a mechanism for the developers to report abuse.

With Stripe, foreign exchange is an extra 1%. The rest of those are taken care of as part of the 3% fee. It doesn't cost that much to process payments.

The one nice thing about the App Store is the centralized recurring subscription management. Seems like a nice juicy low-hanging fruit for Strip to disrupt now that they're allowed to.

The AppStore still charges developers for chargebacks and you still deal with dispute resolution and customer service. Foreign exchange fees are generally 1-2%, so they're not a huge consideration.

It's actually worse with the AppStore, because Apple provides absolutely no assistance to the developer unless you're a billion-dollar plus company.

But regardless of where it is purchased the developer still needs to pay Apple 30%.

So Apple gets paid. The customer who has to pay more loses.

And the debate is whether Apple or the app developer gets the blame. I suspect the latter.

It would be 3% less, assuming 0% fee credit card processing (and there is no such thing).

Apple will still be collecting 27%: https://www.macrumors.com/2024/01/16/us-app-store-alternativ...

> There is no way 3rd parties can match it.

The EU will attack this eventually and demand that the number of taps/clicks/screens to do an apple payment match those of third parties...

Funnily enough I think third parties will integrate Apple Pay to maintain the seamlessness. Apple likely would be hit for anticompetitive practices if they forbid developers from using Apple Pay for third-party In-App Purchase payments.

This doesn’t apply to the EU.

I paid a lower price until I did not.

2023 New years day I signed up for an offer 6 bucks a month. I knew it was only for a year, but then I forgot. On new years day 2024, I got charged 50 bucks. Maybe I could have fought it, maybe I could have spent some time challenging it, but it was not worth my time, so I canceled my subscription. But what cost me 12 X 6 = 72 for a year now cost me 50 bucks for a month.

This is the difference Apple's payment system can make. You visit the store regularly (hopefully), so you know when the renewal is up, and at what price. Even if you do not visit regularly, I presume you can set up alerts to notify you of expiry, and IIRC they allow small adjustments to the price without notification, but 6=>50 would be notified. Pretty sure.

Of course this does not work for some companies who thrive on people slacking off on canceling re-priced subscriptions.

You don’t have to set up alerts. They automatically notify you when subscriptions are going to be rebilled with the amount, at least for yearly ones.

I don’t think I have any monthly or weekly subscriptions so I can’t be sure about those. I would expect they’re the same though.

Reply on news.ycombinator.com