Murror
AI that helps you understand your emotions & connect deeper
Start new thread

Apple's EU commission cut is worth five points to a small dev. Do the arithmetic before you take it.

by
•

From 1 October, leaving Apple In-App Purchase drops a Small Business Program developer from 15% to 10% in the EU. On a 4.99 euro subscription, a processor's fixed per-transaction fee can eat most of that on its own - and your choice locks for 12 months.

Apple updated the Developer Program License Agreement on 18 August, and the new EU business terms go into effect on 1 October. The coverage I've read frames it as Apple finally opening up. That's true in a structural sense and mostly irrelevant to anyone running a small subscription app, because the interesting question isn't whether you can leave Apple's payment system. It's whether the arithmetic works. For most of us it doesn't, and it's worth being able to say why rather than just having a feeling about it.

Here are the actual rates, from Apple's own support pages.

Apple In-App Purchase: 26%, or 15% if you're in the Small Business Program, the Mini Apps or Video Partner Programs, or on an auto-renewable subscription after the subscriber's first year.

Alternative payment processing inside your app: 20%, or 10% for those same groups.

Out-of-app offers with an actionable link: a 15% store services commission, or 10% for those groups, on anything bought within 7 days of the tap.

Apps distributed outside the App Store entirely - an alternative marketplace, or your own website - pay a 5% Core Technology Commission, which replaces the old per-install Core Technology Fee. The Initial Acquisition Fee and Store Services Fee are gone.

So if you're a small developer on the App Store, the headline is: 15 down to 10. Five points.

Now the part nobody puts in the headline. Five points of what?

Take a 4.99 euro monthly subscription. Five points is about 25 cents a month. Stripe's published EEA card rate is 1.5% + 0.25 euro per successful transaction - that's a vendor quoting its own price, so check the current page for whatever processor you'd actually use, but the shape is standard across the industry: a percentage plus a fixed fee. On 4.99 euro that fixed 25-cent component alone is roughly 5% of the transaction. Before you've paid a single basis point of the percentage, the entire saving is gone.

The fixed fee is the whole story for small-ticket subscriptions, and it's the thing the commission-rate debate never mentions, because the debate is conducted by people selling 80-euro-a-month software where 25 cents rounds to nothing. If your price point is under about 10 euro, moving off IAP is arithmetically a wash at best. If it's 2.99, you are paying for the privilege.

And the five points isn't only buying you payment processing. Read what else transfers to you. You become responsible for collecting and remitting VAT across EU storefronts. You handle refunds, chargebacks, failed-payment recovery and subscription management. You handle the support tickets - Apple says plainly it won't be able to help your customers with refunds or purchase history. Your transactions won't appear in the user's App Store purchase history, won't work with Family Sharing, and won't surface in Report a Problem. And you owe Apple a monthly transaction report within 15 days of month end, which must include refunds, corrections, renewals and transactions that didn't result in a purchase. Apple has audit rights on it. Non-payment can mean offsetting your proceeds in other markets, or removal from the App Store.

That's a finance function. You'd be trading five points for a finance function.

Two more details that changed my read.

The choice locks for 12 months. Once you select your payment options - IAP, alternative processing, out-of-app offers, or a combination - you must maintain that choice across all EU storefronts for a year. This is the one I'd underline. It converts a reversible experiment into a bet. You cannot ship it in October, watch conversion drop in November, and quietly revert.

The entitlement has an OS floor. Apple's docs say the entitlement profile only works on iOS 26.2 and iPadOS 26.2 or later, and 26.6 for macOS, tvOS, visionOS and watchOS. So on day one, alternative payments don't reach your whole EU base - they reach the slice that's updated. You'd be building two payment paths and maintaining both, indefinitely, for a partial rollout.

Who should take this? If your average transaction is large, the fixed fee stops mattering and five points is real money. If you already run web billing with tax handling and a support process, the marginal cost is close to zero and you should probably do it. If you're at genuine scale, 5% via Web Distribution instead of 15-26% on the App Store is a different conversation entirely, and worth having properly. Notably, Apple also dropped the requirement to have an EU legal entity to operate a marketplace or use Web Distribution, which makes that path reachable for more teams than before.

What I'd actually do this week, if you sell to EU users: work out your five points as a euro figure per transaction, then put your processor's real fixed fee next to it. That's a ten-minute exercise and it answers the question. Separately, note that agreeing to the updated agreement is the gate for all of this - and that the old Alternative Terms Addendum is being superseded on 1 October whether you engage or not.

The Murror version is boring. We're a small subscription app and we're staying on In-App Purchase, and I want to be honest that I didn't reach that by principle. I reached it by writing 25 cents next to 25 cents and noticing they cancelled. The thing I nearly got wrong was reading "Apple cut the commission" as good news that needed acting on, when the correct response to most platform changes is to do the arithmetic and then do nothing.

72 views

Add a comment

Replies

Best

From the page side, the line nobody puts in that arithmetic is what the checkout has to do afterwards. Apple's payment sheet carries the trust for free, and once the payment moves onto a web page, that page has to earn it with layout, refund copy and logos, and someone has to keep it doing that. That is not a fee, so it never shows up in the comparison.

  That's a fair hit, and it's the cost I'd have left out. Apple's sheet is doing trust work I never had to build or maintain, and it doesn't appear on either side of the fee comparison because nobody invoices you for it. The version of that I've felt is narrower but real: people trust a payment sheet they already recognise, and a first-time subscriber to a journalling app is exactly the person who hesitates. Adding a page I have to keep earning that on is a cost with no line item.

  The cheap way to borrow some of it back is to put the cancellation and refund terms above the card field rather than below it. A first-time subscriber hesitating is usually worried about being stuck, and that is the one worry a page can answer for free.

 Taking that one. It costs nothing and it answers the worry at the moment the worry arrives, rather than in a link someone has to decide to open. For a journalling app the hesitation isn't really about the 4.99 either - it's about being on the hook for something you might use twice and then feel bad about. Refund terms above the card field is a better answer to that than anything I'd write in the pricing copy. The honest caveat is that I'm agreeing with it, not reporting it: I haven't run that test, and staying on IAP means I won't get to. So treat it as a good argument rather than a measured result until someone here has the numbers.

The fixed fee is the part I'd push hardest on, because it's the only variable in your arithmetic you actually control.

Same 25 cents, but count how many times a year it fires. A 4.99 subscription touches the card twelve times, so on 59.88 of revenue you've paid 3 euro in fixed fees before a single basis point of percentage. That's your 5%. Sell the same 59.88 once and you pay it once, 0.42%. The percentage part doesn't move either way. So the shape of the transaction is worth about four and a half points, which is the same size as the whole Apple concession you're weighing, and it doesn't lock you in for a year.

That's the trade I took, though our products aren't the same shape. Mine is a flashcard generator, episodic by nature, and it sells credits in one-time packs that don't expire instead of a monthly plan, for exactly this reason. Nobody was ever going to buy 4.99 of it twelve times a year. Murror is a habit product where the value arrives every week, so a subscription is probably the honest match for what you deliver, and I'm only talking about the fee, not your model.

  I checked your numbers before replying and they hold: 3 euro of fixed fees on 59.88 is 5.01%, the same sum charged once is 0.42%, so the gap is about 4.6 points. That is the better framing and I wish I'd written the annual view instead of the per-transaction one, because it makes the point harder - transaction frequency is worth roughly what Apple is offering, and it doesn't come with a 12-month lock. Agreed on the model too. A journal only works if you keep coming back, so credit packs would be selling the wrong shape of thing even if the fees favoured it. But that means the fixed fee fires twelve times for us and there's no pricing trick that avoids it, which is most of why staying on IAP was easy.

 Annual billing fires the fixed fee once for the same twelve months of subscription, and it doesn't ask a journal to stop being a subscription.

Run it against your own break-even. You told Ryan the line sits at 7.14 euro, and that's per transaction rather than per month, so a 4.99 plan billed annually is a 59.88 transaction and clears it eight times over. Same product, same price, same year of revenue. Billed monthly, leaving IAP costs you about 90 cents per subscriber per year: 10% to Apple plus twelve lots of 1.5% + 0.25 comes to 9.89 in fees against 8.98 if you'd stayed. Billed annually the same subscriber earns you about 1.85, because those twelve fixed fees collapse into one. The sign flips on the billing period alone and nothing about the product moved.

2 things I would hang on that before it reads as advice. It only bites off IAP, since Apple's cut is pure percentage and the fixed fee doesn't exist while you're on their sheet, so annual billing on IAP is a cashflow and conversion question rather than a fee one. And you told Lisa the person who hesitates is a first-time subscriber to a journalling app, which is exactly who a 59.88 upfront ask sends away.

 Ran your numbers and they come out where you said: monthly off IAP is 5.99 to Apple plus 3.90 in twelve fixed fees, 9.89 against 8.98 on IAP, so about 90 cents worse. Annual is 5.99 plus 1.15, 7.14 against 8.98, so about 1.85 better. The sign does flip on billing period alone. Where I'd push back is that it stops being a fee decision at that point. An annual plan doesn't collect the same year of revenue from the same person - it collects a different, smaller set of people who were willing to commit upfront, and you find out which in about two months rather than two days. You named that yourself with the 59.88 ask. So the honest comparison isn't 1.85 gained per subscriber, it's 1.85 gained per subscriber times however many you keep, minus the ones who'd have said yes to 4.99 and won't say yes to 59.88. I don't know that ratio for a journalling app and I'd rather say so than guess it. The other thing annual changes is refund size. A monthly refund is 4.99 and a decision nobody agonises over; an annual refund is 59.88 and it arrives with a support conversation attached, which is exactly the finance function I said I didn't want to inherit. So it's a real answer to the fixed fee and I think it's the strongest one in this thread - I'd just file it as a pricing experiment with its own risks rather than a way to win the platform argument. And your first caveat is the one that settles it for us: on IAP there's no fixed fee to collapse, so annual is a cashflow and conversion question we can run whenever, independent of anything Apple does on 1 October.

  The take rate isn't something you have to bet on, because annual doesn't replace monthly. You keep 4.99 a month and put the year beside it at a discount. Everyone who'd only ever say yes to 4.99 still says yes, the ones who take the year are added rather than substituted

On refunds, look at which side of the IAP line that objection sits on. Off IAP a 59.88 refund is your support conversation. On IAP it's Apple's, and so is the decision: you get the clawback, not the thread.

So both of the things that make annual expensive are things you already decided not to own. Which leaves it as the cheap experiment in this thread rather than the risky one, and the only one with no October date on it

I suggest adding a simple spreadsheet template so readers can plug their price and processor fee and see the break even point instantly without guessing like me every single day


  Fair ask, and honestly the whole thing fits in one line, so here it is rather than a file. Break-even is where 0.05 x price equals (processor rate x price) + fixed fee. With the Stripe EEA numbers I quoted, 1.5% + 0.25 euro, that solves to about 7.14 euro. Under that price you lose money moving off IAP, over it you start gaining, and it's pure fee arithmetic - substitute your own processor's published rate. Two caveats I'd put on the same row so nobody reads the break-even as a green light: it counts only fees, not the VAT remittance, refunds, chargebacks and support you inherit, and the choice locks for 12 months. So 7.14 is the floor, not the threshold - you want to clear it by a margin that pays for a finance function.

I love your closing line about doing nothing being the smartest response to most platform changes and I agree completely

  Thank you. Though I'd put one guardrail on it, because "do nothing" is only the right answer once you've done the arithmetic - the same line without the ten minutes of maths is just inertia wearing a good argument as a costume. The deadlines are also where it stops applying: this one has a 1 October date and a 12-month lock, so doing nothing is an active choice here rather than a deferral, and it's worth knowing that's what you're picking.

Outside App Store economics entirely the same fixed fee logic decided how I priced my own thing. I run a web product with a flat one time fee instead of a subscription, and the reasoning was the same shape as what Siarhei laid out, a fixed processor fee charged once against a fixed fee charged twelve times a year is not a small difference, it is most of the margin on a low ticket item. The bit I would add is that this is not only an Apple decision. Anyone pricing a low ticket product should run the same ten minute exercise against their own processor before defaulting to a subscription because that is what everyone else does.

  Agreed that the fee logic generalises, and your framing is the more useful one - the Apple version is just where it happens to have a date attached. The one place I'd resist generalising is the conclusion rather than the exercise. Fixed fees push you toward fewer, larger transactions, but so does nothing else about a product, and if the value shows up weekly then a one-time fee is cheaper to collect and worse at describing what you sell. We're subscription despite the fee maths, not because of it. What I'd take from your comment is that the ten-minute exercise belongs at pricing time, before the model is load-bearing, rather than at platform-change time when you're stuck defending a number you picked for other reasons.

 Fair distinction, better than the one I drew. Timing is the variable I skipped past. The flat fee decision I mentioned was not made at platform change time either, it was priced that way from the start because the product is one time value rather than recurring, so the shape of the transaction and the shape of the fee happened to agree without me choosing on purpose. That is luck, not process. The rule worth keeping from this thread is do the ten minute exercise when you pick the model, not when a platform changes terms under it, because by the second point you are defending a number instead of choosing one.

 "Luck, not process" is more honest than most postmortems I've read, including mine. I'd only soften it slightly: getting it right by matching the fee shape to the value shape isn't luck exactly - you priced from what the product does, and the fee maths agreeing is what tends to happen when you do that. The luck is that nothing else pulled the other way. We priced from the same instinct and the fee maths disagreed with us, and we kept the model anyway. Your rule is the right one to end on, and I'd add the corollary: if you do the exercise at pricing time and the answer comes out against the model the product needs, that's still a good outcome. You just want to know the size of the tax you're choosing to pay rather than discover it when a platform gives you a deadline to think about it.

the fixed fee changes the shape of the decision, not just its size, and that is the part i would put in bold.

a percentage cut is linear in price. a fixed per transaction fee is not. so the break even sits at a price point rather than at a rate, and every dev has to compute their own instead of reading the headline. what was announced as a five point saving is really a saving above some price and a loss below it, and the number that got published is the one that only helps you if your prices are already high.

the twelve month lock is what makes it asymmetric rather than just marginal. you are being asked to commit for a year to a calculation whose two inputs are your own price and your own mix, both of which you are presumably still changing.

your closing line is the one people will disagree with and it is the correct one.

 "A saving above some price and a loss below it" is the sentence I should have led with. A percentage is scale-free and a fixed fee isn't, so the announcement can be true and useless at the same time depending on where you sit, and the number that gets published is the one that flatters the people with the highest prices. That's not Apple being sneaky, it's just what happens when you summarise a two-input function with one number. The asymmetry point is the one I hadn't put that way. Twelve months isn't long against a platform's roadmap but it's very long against a small team's pricing, and I've changed our price and our plan mix more than once a year without thinking of it as a big decision. Committing to a calculation whose inputs you're still moving is a different risk from committing to a rate. Thanks for both - the second one is going in my notes.

 take it, it was your analysis, i just moved a sentence. the thing i would add is that the twelve month lock is what makes it worth writing about at all. a reversible decision does not need arithmetic, you just try it.

 "A reversible decision does not need arithmetic, you just try it" is the most useful thing anyone has said to me on here, and it generalises well past Apple. Analysis is what you buy when you can't buy a trial.

Which gives me a check I hadn't articulated: before doing the maths on a platform change, ask whether it's reversible. If it is, the spreadsheet is procrastination with better posture — ship the experiment and read the result. If it isn't, the arithmetic is the only instrument you have. The 12-month lock is exactly what moved this one across that line, and it's also, now that I look at it, why the other platform things I've bothered to write about were worth the time. Not because they were new, but because they had a date or a lock on them.

One qualifier I'd add. Reversible isn't the same as cheap to reverse. A second payment path is reversible in the sense that you can turn it off, and you'd still have built two code paths, a VAT process and a support flow, and you don't get that time back when you revert. The lock makes this one worse than most, but the switching cost isn't zero even without it. So maybe the real question is reversible at what price — and if you can't answer that in a sentence, you're back to doing the arithmetic anyway.