Your argument is basically that Apple provides X and Y, and Epic is only providing Y, so Apple’s higher cut is justified.
My position is that users already bought X when they purchased the device from Apple (X in this case being the OS). Apple wants to charge for X multiple times per user.
You honestly don't know what you're talking about.
You're making the following assumption (correct me if I'm wrong):
Assumption: Apps are mostly only using the Apple frameworks and apis that Apple needed to make to create iOS and its own apps.
That assumption is WAAAAAAAAY wrong.
You truly don't understand that apple spends an incredible amount of developer time and money on fully optional convenience features for devs. These have nothing to do with the OS or Apple's apps. Apps make HEAVY use of these to do all kinds of semi-invisible things that make app development way easier (and apps way more functional) than even 5y ago.
Apple does this part of the work because they are reaping very good profits on the extra money invested in that development!
So Apple does do X and Y, but there's a Z, and that Z is HUGE and completely different from X and Y.
Z lets developers with almost zero effort do concurrency, operate correctly in different regions with different number and date formats, different language directions, lets apps background sensibly without losing data, offer low-networking modes, do crypto work, animations, and literally 1,000 other features.
Features that devs just don't have the expertise or the YEARS to implement without Apple's convenience apis.
It's naive beyond belief to assume Apple could slash its revenue and would then not correspondingly slash its budget on these convenience features.
In fact Apple (Android does this too) is CONSTANTLY growing and shrinking its team of devs doing this work. They tune the profitability margins. It's a trade-off that benefits us as users of the phones/apps, Apple in making its optimized profit, and developers who before this model basically made nothing at all for WAY more work.
15 years ago it was insanely harder to write an app that did 1/10th what current apps do. Things that you probably don't even realize apps do, things which take INSANE amounts of time and expertise, time and expertise which 95% of the app developers out there making your favourite apps simply don't have.
--
Here's a little eye-opener to give you perspecitve. This is one of those developer convenience features that is very, very tiny...
(This also happens to be relatively new in the past few years and is something that you just don't get on other platforms.)
Ask a dev friend how to deal with something as trivial as dates. Say, find a date 6 days from another date.
You think that's as easy as adding 6*24*60*60 seconds to the first timestamp? Oh poor child no. No, no, no.
Look into the complexity of dates and calendars and it will turn your crap white. It used to be absurdly difficult to do it well. (For ONE locale! Look into the differences between locales and your white crap will scuttle under the bed and cry.)
If you needed to have consistent date manipulation it was a nightmare. It took absurd amounts of research and a ton of coding to do the simplest thing (say make this appointment repeating every Wed at 5pm, THAT is far more difficult than you can imagine, it goes well beyond simply checking for leap days, especially if you want it to be robust).
Apple recently gave us a convenience api that makes NONE of that knowledge or expertise necessary. It took a ton of their time, but now we just say, essentially 'give me a date one week from this date' or '1pm on the second weekday of the month 6mo from now for the user's current calendar locale'. I cannot stress how difficult that would be to do properly with custom code (you would almost certainly drop in a library built by somebody else's volunteer work, which probably would be full of bugs, possibly be insecure, likely have little or no documentation, or worse, wrong documentation, wouldn't have the same locale abilities, and perhaps would only have a non-commercial license. Actually you'd have to spend quite a few hours determinign which of 5 different public libraries might have the right balance of those trade-offs. Honestly this process of finding and using third party frameworks is FRAUGHT.). Like I said... 👻💩
Aside, don't take my word for it, check out what
Paul Hudson from HackingWithSwift has to say:
You see, working with dates is hard. Like, really hard – way harder than you think. Way harder than I think, and I’ve been working with dates for years.
(And if you're interested in learning Swift and building an app, believe me it's the PERFECT time for it, because Apple has made it so incredibly easy. And Paul's Hacking With Swift is a wonderful place to start, even if you couldn't tell the difference between a Double and an Int, and have never done any programming in your life. Check out his "Unwrap" app which is a fun teaching tool for many of the very earliest programming concepts. If you find it fun, which you might!, his 100 Days of Swift course will get you building an app that actually does something within a few hours. It truly is miraculously more easy now!)
Back on topic...
Now the calendar convenciences were to be fair a relatively tiny amount of effort for apple. Probably not much more than 1,000 dev hours to design, implement, unit test, document, and prepare WWDC presentations for. So, likely this TEENY feature cost Apple no more than half a developer year, say in the ballpark of $50k (though probably that's low, because a large part of the design and architecture of even such a simple feature would be done by a very senior architect who makes a WHOLE lot more than $100k a year).
But hoo baby, does it save so much grief from app developers. So much so, that we all quit using our own brittle logic or external frameworks and just use
Calendar.current to add/modify/construct dates and date components.
And most importantly this is nowhere near required to make an app work well in the AppStore. This is an invisible convenience that makes developers lives TONS easier and very slightly improves quality of apps.
And EVERY YEAR Apple puts many convenience features like this that probably have 10-20x that amount of effort. Usually one or two a year which have 100-200x that effort (like Async/Await).
If you don't believe this. If you don't get some inkling of the sheer scope of this work. I encourage you to watch some WWDC videos from the past year. Come back here and report at exactly 3pm on the second weekday of next month as measured in Manila. 🤣
