Apple to soon take up to 30% cut from all Patreon creators in iOS app
macrumors.com1112 points by pier25 6 days ago
1112 points by pier25 6 days ago
Apple’s App Store profits on commissions from digital sales
Revenue $32 B
Operating Costs $7 B [1]
Estimated Profit $25 B
Operating Margin ~78%
Apple could take just 7% cut and still make 20% profits.
Fun Fact: During the Epic trial, it was revealed that Apple's profit margins on the App Store were so high that even Apple's own executives were sometimes surprised by the internal financial reports.
---
edit: There is no ideological argument for voluntary action here. The entire goal is to force regulators to step in. The debate over 'good vs. bad companies' is just online noise and rhetorical trik, no one on either side of the political spectrum wants these systems to be fixed voluntarily with corporate altruism.
The operating cost is the maximum Apple can come up with when their accountants attribute everything they possibly can to digital sales for the sake of legal argument. R&D shouldn't really be included, and Apple uses those same tools and APIs themselves. I think the actual profit margin is closer to 90%, and Apple could maintain a 20% margin with just a 3–4% fee.
I'd say that in the case of Patreon, any fee for Apple is unjustified. Apple can justify their fee on app purchases/subscriptions in the app store, but Patreon is not an app subscription, the money goes mostly from the patrons to the people they support. Ok, Patreon takes a cut to cover their operating costs, and also make a profit (not sure how profitable they are currently), but I really can't see how Apple, who don't have anything to do with this process except for listing the Patreon app on the app store, can justify taking a cut.
You could make the argument that Patreon isn't much more than a banking app.
It just focuses on the receiver of the money than the sender.
I think Apple is slowly killing apps with this policy. Everybody will slowly move to "web only" as 30% would kill their ability to compete with anybody else. This will likely be much stronger in countries where iPhones do not have the same market share as in the US.
> Everybody will slowly move to "web only" as 30% would kill their ability to compete with anybody else.
This is why Apple makes PWAs so miserable in Safari and disallows other browsers unless they're just Safari with lipstick.
Apple users seem to be fine with everything being much more expensive. Not only the 30% apple tax itself, developers know Apple users pay more and specify higher prices on Apple.
30% is also the cut google takes on the google play store. This is not an apple only issue. This is a regulatory one.
Google allows out–of–store installation (for now...) so it's much easier to argue there's competition. Apps installed through F–Droid don't have this tax.
And in the EU alternative app stores are allowed on iphone as well. In both cases, it’s a near negligible amount of people that use them. Your exceptions prove the rule, if anything.
This would not be true if all markets rose simultaneously. It’s why they all fight so hard to delay the inevitable. You don’t have to win, you just have to win for long enough to be established
> Everybody will slowly move to "web only" as 30% would kill their ability to compete with anybody else.
Frankly, yes, please. I mean, I'm biased as my whole career is in web app development, but there are so many things these days that do not need a whole native app. They're just communicating with a server backend somewhere, using none of the unique native functionality of the phone (much of which is available in browser APIs these days anyway). I can block ads in a web app much more easily. It's much harder to do customer-hostile things like block screenshots in a web app.
Native apps definitely have a place, but I think they're very overused, mostly for reasons that benefit the business at the expense of the customer.
Apple makes sure it's not practical.
You still can't have a "share to" target that is a web app on iOS. And the data your can store in local storage on safari is a joke.
Of course, forget about background tasks and integrated notifications.
In fact, even on Android you miss features with web apps, like widgets for quick actions, mapping actions to buttons and so on.
And no matter how good you cache things, the mobile browser will unload the app, and you will always get this friction when you load the web app on the new render you don't have on regular apps.
Service workers solve the cache issue; web apps can run permanently offline after initial load. You may be a bit out of date on the state of the web.
No, I use them but loading and unloading the app in the tab still happens when the browser flushes the app from memory because the OS killed it or the browser eviction policy hits.
This loading is not nearly as seamless as a regular app starting back up.
For a regular app, you have the app loading, and the os cache helping with it. If you do your job half correctly, it loads as a block almost instantly.
For a web app you have the web browser loading, the the display of the white viewport in a flash, then the app loading in the browser (with zero os cache to help with so it's slower). It needs then to render. Then restoring the scroll (which is a mess with a browser) and the state as much as you can but you are limited with persistence size so most content must be reloaded which means the layout is moving around. Not to mention JS in a browser is not nearly as performant as a regular app, so as your app grows, it gets worse.
> I think they're very overused
I disagree, native apps on iOS have important abilities that no web application can match. The inability to control cache long-term is alone a dealbreaker if trying to create an experience with minimal friction.
Service workers allow you to control cache in web apps; you may be a bit out of date.
There are hardware APIs for some stuff that only works in native (cors, raw tcp), but 99% of apps don't need those.
I think the parent may be referring to the fact that safari/webkit will evict all localstorage/indexeddb/caches etc after 7 days of not visiting a site. And apparently this now extends to PWAs making it a pretty big blog to building any infrequently accessed PWA that needs to persist user data locally.
I store my data in the service worker cache, so I guess I'm immune to this issue
Those same elevated controls are used to steal PII and sell to data brokers. Again, it's the companies that are trying to force apps on their users. If it were genuinely a much better UX, they wouldn't have to do that.
I don’t think you are correct, but I could be wrong. For example, can you replicate the functionality of TikTok - autoplay unmuted videos as the user scroll down to new videos? It’s the experience that the user expects.
I've probably deleted 15 apps from my phone in the past year as I steadily move over to the web for everything.
My chat agent, file transfer tool, Grubhub, Amazon, YouTube, news, weather are all deleted in favor of a set of armored browsers that suppress the trash and clean up the experience. Its been an amazing change, as those companies no longer get a free advertisement on the application grid of my phone, making my use of them much more intentional.
Sure, once the user interacts with the first video.
If third party native apps were installed and run without user interaction the same as cross-origin redirects, I would expect the same limitations with native apps.
I use FB via my web browser (Firefox on Android) and when I look at Shorts, it has this exact functionality. Web browsers on mobile can do this, clearly.