Apple's bad faith 27% tax on web purchases

This might be due to a slightly different era and/or market, but I recall in the WAP and i-mode era, 50/50 would’ve been amazing.

More often than not, you’d be lucky if you got 30%, and you’d brag if you’d get 40%. In most cases, you’d be left with a measly 10%, and none of it included payment processing, which ate up a few percent more.

The worst part wasn’t the revenue split, though believe it or not, it was negotiating with multiple carriers over every little thing, and it could take months to get things going.

Discoverability was a bit better in this era than what you describe because carriers would have a little directory in which they listed apps. Of course, being listed in this directory, especially in a helpful way, would eat up more of your revenue share.

Carriers were also acting in a dirty way. If something was wrong and a customer complained, they’d charge you a refund but wouldn’t pass it along to the customer. Essentially, telling the customer they’re SOOL while telling the developer to pay up because their app didn’t work and then pocket that money.

The barrier to entry was also high and costly. Developer tools were shit, as you said, and the pipeline from development to sales was nearly non-existent.

So yeah, of course, in comparison, Apple was some kind of utopia, not despite the 30% but because of it, not to mention how hassle-free it is and, like you said, the excellent tools provided. I genuinely like Xcode despite the hate it gets, and I’d say that it’s been significantly improved over the last decade or so.

Similarly, the improvements and development of frameworks in the last couple of years are tremendous. I’d say all of it is well worth the 30%, but at the 15% I’m at now, it’s close to a steal.

Without exaggeration, the latest developments in frameworks really make my life easier, and some of what I do wouldn’t even be possible without it.

The framing around the commission is starting to irk me the wrong way.

In part because these big developers such as Epic, Spotify, and the like claim to speak for me, to make it look like they fight for “the little guy” and drum up support when they plainly don’t. Their interests and mine are miles apart and only marginally overlap and, in some cases, contradict each other.

In part, it is also because the effective rate for most developers is 15%, regardless of Apple’s motivations behind that discounted rate.

15% in exchange for the low barrier of entry and the solid tools that allow you to spin up an app and publish it on the App Store within a day or two is a pretty solid deal, in my opinion.

Also, PayPal is more than a payment processor. It also is a broker (and, effectively, also a shop).

This is where you get it wrong.

If there were other stores for iOS apps and the difference was only Apple's vetting and developers were still choosing to pay Apple 30% vs. much less for some alternative, then you could say that what they're paying for is trust.

But everybody including Apple knows that isn't true in general. As soon as there were other viable stores and developers could put the same app there for a lower price, the large majority of customers would take the lower price over whatever "trust" Apple is ostensibly providing. Unless Apple were to charge substantially lower fees for it.

Which is the only reason they preclude the other stores. If customers actually wanted trust and it could only be provided by Apple then customers wouldn't have to be precluded from using alternative stores because they just wouldn't choose to.

And when that isn't possible, you can't say that people are choosing Apple's store because of trust, when there is no choosing happening because there is no alternative installation method to choose.

You’re approaching this from the premise that you pay a commission for payment processing, when in actuality the primary purpose of the commission is to collect payment for the use of Apple’s IP. All the rest is secondary to that.

Nevertheless, even from the payment processing premise there are some questions that come up when reading your comment.

> You cannot issue a partial refund.

True. It’s either all or nothing.

Closest thing to a partial refund would be pushing the renewal data back on subscriptions, either individual or for all subscribers of a specific product e.g. if you had a widespread issue

> Actually, you can't refund a customer at all.

Nope you can’t directly refund a customer.

You can have a say in refunds for consumables by informing Apple if the consumables have been consumed and you can offer a refund sheet in your app so that the customer doesn’t have to contact Apple themselves, but ultimately Apple’s decision mechanism is the final arbiter.

In my experience both by keeping tabs on users reached out to CS to ask for a a refund, tracking refund requests via the refund sheet in apps, analyzing refund history and notifications and personal experience of me as a user and that of others in my circles, refunds are issued generously, close to 100%.

It seems they have a “Yes, unless” policy, where the unless is mainly tied to having a history of requesting refunds.

A decent amount of developers actually complain about how easily Apple gives refunds going by posts I see on different forums, but I prefer it this way.

> If Apple declines the refund for whatever reason, you and the customer are just screwed. Literally had to buy a gift card to give a customer so we could make them whole.

This seems like a rather extreme solution. Was there a big issue with your app that compelled you to do this?

> You cannot offer a discount and free trial at the same time.

Depends on what you mean by this.

If you mean a free trial and after that a discounted rate you can just create a new product at that discounted rate and enabled the free trial.

If you mean a trial and then a temporary discount then no, there’s no direct native way of doing this. Presumably because you can just calculate the discount into the introductory offer instead of confusing the user with having to track two time periods, the period of the free trial and the period the discounted rate is in effect.

But close to native is using offer codes and enabling eligibility for introductory offers. Then your users will get the introductory offer first (i.e., free trial) and renew at the offer tied to your offer code (i.e., discounted rate). You can also use this to give longer free trials during certain periods, the introductory trial will stack with the trial set on the offer code.

Nevertheless, I was partial to utilizing the DeviceCheck framework before all of this was possible. Check if this device is new, if so, enable free trial and after that trial offer discounted introductory offer.

Benefit of this was that users appreciated not having to initiate a purchase flow to get access to the free trial, risking a charge at the end if they forgot.

Downside is that it’s tied to device and not Apple ID, so technically users can get a free trial on multiple times, if that’s something you’re concerned about.

> When trying to create a different subscription group to A/B test our pricing, we somehow got cursed with a reviewer who did not understand the concept long after it was released. New app builds with bug fixes completely unrelated were getting rejected. It took weeks of escalations before they finally relented.

That’s a shame. What did they get hung up on? Not being able to see certain products in the app?

> Promotional pricing is so frustrating to setup between Introductory Offers, Promotional Offers, and Offer Codes.

What did you find frustrating about it?

> You cannot generate ad-hoc pricing for anything

Depending on how “ad-hoc” you’re talking about, wouldn’t offer codes fulfill this desire?

Perhaps I worded this poorly, but I was specifically talking about the 27%-30% apple tax. The tax burden inevitably is either absorbed by the developer entirely leading to less profits and funds for them to innovate or they off board some of that tax burden by bumping their app's cost for the customer. I don't see how anyone but apple benefits in either of these situations.

>Let's wait until they are aware, and let them choose. We shouldn't assume other people's choices and "act in their best interests".

I'm confused... when did I recommend removing someone's choice? All I want is for the millions of people who have chosen apple to be taken advantage of less.

>We have endless periods of time where the setup wasn't conducive to the sort of innovation that's happened over the last 20 years in phones.

Yes and often those times coincide with awful exploitation. Industrial revolution was great for innovation, bad for the children who died working 12h a day in factories. Ideally we can strike a balance here and when it comes to preventing apple from charging 27%-30% for developers to innovate on their platform, a reasonably strong argument(s) can be made that it wouldn't prevent innovation.