Can't imagine that flying with the EU...
The regulator will argue that the technology in the phone has already been paid for by the buyer of the hardware (which came with a license for iOS)
Charge developers at-cost for hosting/distribution. Want more compensation for producing the hardware/platform? Here's my $1,000 receipt. Now go away.
Seems a bit dishonest from our protector and guardian.
Edit: I should have been specific that I was referring to the Core Tech Fee that will apply even to free apps with more than a million users. Developers will still pay a value based royalty of 10% (small devs) or 17% (large devs) for paid apps.
I am. And even if I’m not, I don’t give a rats ass.
If entity providing the application wants money, it can talk to me.
The DMA is 66 pages of legalese, otherwise I would have read it to find out:
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
(Disclaimer: I'm no lawyer, armchair or otherwise)
Disclaimer: was an attorney, now just of the armchair variety when I’m not buy as a code monkey, NL was where I went to law school
Apple's entire plan is a farce that further illuminates the deathgrip they have on the entire platform. Preferential treatment of their own app store, requiring Apple's approval (notarization) of any app, regardless of distribution channel, their ability to revoke any developer's ability to publish app, regardless of distribution channel, etc.
[1] https://developer.apple.com/documentation/appdistribution/in...
So handy that Apple will keep such meticulous records of exactly how much and who they're charging.
I wonder if the alternate App Stores will have to be installed via the official App store?! That’s the way I would do it. Gives Apple a way to shut them down if they try to circumvent the reporting piece to bypass the 0.50 fees.
The user paid for the technology in the phone, but the dev didn't pay for use of Apple's IP to build their own product which they are offering to users.
I don't see regulators being able to challenge this (nor is it particularly unfair).
Hardware-platform SDKs generally cost tons of money. Visual Studio Professional Enterprise — essentially (if you think about it) the SDK for the Windows platform — costs $250 per month per seat!
(And that's cheap, compared to the SDK costs for proprietary platforms that people don't usually consider "computers." How much do you think Blackberry charges for a QNX SDK? There's a reason that maybe five companies in the whole world ever bothered to develop car infotainment "partner apps", before Apple CarPlay and Android Auto came along to make the platform moot.)
These SDK fees pay for "the platform" — but specifically, in IP terms, they give you a license to use the source code and libraries that come with the SDK, a license to redistribute the outputs of the compilers that come with the SDK — and so forth.
PC and smartphone platform vendors stopped charging so much for SDKs (or at least their non-enterprise-level SDKs) right around when they introduced App Stores. Because they changed the model, to one where the license you got with the SDK, said that your IP license to the stuff in the SDK, is paid for through royalties, by the revenue you make from publishing your app on their App Store.
And that's a perfectly valid arrangement. If you breach the contract, by not giving Apple royalties, then you don't have IP rights to redistribute the derivative works from their SDK any more!
And then on top of that, Apple already charges developers for tooling via their dev license program. Which at least makes some sense since it's a fixed fee. The notion that maker of the toolchain gets to claim a percentage of what the app written using it brings in is ridiculous by all industry standards.
Never published a game on a game console, eh?
Read the terms: it’s not for commercial development
Do you also believe that Epic's Unreal Engine pricing is also ridiculous under the same standard?
Professional and Enterprise are two distinct editions. Professional is $45/user/month, and it's a capable IDE even if Enterprise has some extra features.
Or you can use GCC and compile “Hello world” for windows, no Microsoft IP involved? What am I missing
Certainly, you can compile Hello World with GCC — or maybe even a POSIX network server — to run under WSL. And maybe redistribute the resulting hello_world.exe to other WSL users.
But what happens when you want to compile that same program to run "on Windows" directly, to be redistributable to people who don't have WSL installed?
Well, even if you're using GCC, you'll probably end up linking your program against the Visual C Runtime. (Because otherwise you'll need to ship — or statically link — glibc.dll. Which is a bit ridiculous.) And the Visual C Runtime is... part of Visual Studio! A part that's freely redistributable, yes... for those developers with a valid Visual Studio license. Otherwise, Microsoft can sue you for packaging MSVCRT.DLL with your app.
And as your app gets more complex, that just keeps being truer. While Microsoft Store apps can just list their package deps and get the store to install them, if you're a standalone Windows UI app, you might have to redistribute, say... DirectX. Or SQL Server Embedded. Or even — and this is a very clever trap on Microsoft's part that many FOSS devs don't notice — some "sample library code" from MSDN. All of which are offered under that same redistribution licensing clause.
---
Note that there are high-level "app platforms" that attempt to work around all this — mostly by not having you compile anything to target the Windows native ABI at all — but rather, just providing a higher-level platform abstraction, that you write code against, where that code ships with the executable but not within the executable (so as to keep the executable's Microsoft-stamped code signature intact.) This is how Electron's Windows support works, for example. Also, most game engines, e.g. Unity, Love2d, RenPy, etc.
I believe that there are also a few "app platforms" that go another route, trying to avoid the Windows runtime altogether — using funky low-level static-compiled languages to directly address the NT syscall ABI, and then building up from there to doing multimedia and networking. I think Haxe is like this?
But while Haxe has some level of windows-and-menus UI toolkit (http://haxeui.org/), it's not one that supports OS accessibility APIs (e.g. screen-reader support), or DPI scalability, or high-contrast mode. (In other words, it's just not suitable for writing B2B software where your users are under a bunch of business requirements on what the software they give their employees to use, needs to be able to offer them.)
Also, you're not getting integration with OS file-picker dialogs, or multi-format drag-and-drop / copy-and-paste, or embedding of arbitrary graphical COM components within the view, or — especially — being embedded as a graphical COM component within some other app. (This last one is pretty important for boring line-of-business apps like tax-filing software; you want your app to be able to render its document filetype to the viewport when documents of that type are opened in a browser!)
In short: for making anything that you charge for... you're still gonna just pay Microsoft for Visual Studio.
