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.

What Apple subscriptions? Logic Pro? Are you talking about a free trial or a paid trial? Also, if it is paid and you cancel and they terminate usage, do you end up seeing a refund for the balance of the time? With third-party devs, they have already sent the money along to the dev so they would have to pull back money to terminate immediately and refund the prorated balance of the subscription cost to the user. That would be hard on devs.

But the dishonesty comes from allowing users to take risk-free advantage of free trials from third parties (which is good for consumers and business in general), but subjecting the same users to potentially unwanted renewals when it comes to an Apple product.

Rules for thee, not for me, says Apple to devs and users.

[1] https://www.theverge.com/2019/11/1/20943286/apple-tv-plus-fr...

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.

If not, I wouldn't be opposed to the paying to review apps outside of the App Store (where their 30% cut assumedly takes into account for App store apps), as long as the review is purely for security and not to comply with App Store rules (since I am not hosting it on the app store). But charging everytime someone download a semi-popular app, or worse, updates that app (since the install fee is per year) starts to go beyond "what value am I bringing to this feature?"

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)

I mean whether it’s the EU or Epic, Apple isn’t interested in letting anybody just co-opt their baby.

well yes. That's part of the rub. You'll pay $100/year even if you never launch an app so that makes sense. That's the cost of using Apple's SDK.

But you may now pay $.50 per install even for a free app if you don't/can't host outside of the App store, unless you declare your company/business a non-profit or educational instituion. This was previously $0. So the price hike can become absurd, to say the least.

>Apple isn’t interested in letting anybody just co-opt their baby.

Well tough luck. you made more money off your "baby" than many country's GDP. Microsoft got co-opted for much less decades ago. Governments' interest is in making sure companies do not in fact hoard all the money in the world, and when your product becomes a centerpiece of society something's got to give.

You don’t need to pay Apple $100/year if all you want is Xcode and the documentation, but if you want to actually launch an app, that’s when you pay Apple.

> But you may now pay $.50 per install even for a free app if you don't/can't host outside of the App store, unless you declare your company/business a non-profit or educational instituion. This was previously $0. So the price hike can become absurd, to say the least.

Yeah, due to *checks notes* changes in the regulatory environment making their previous model untenable in the EU. It is now not worth the cost or business risks to Apple to let all free apps free-ride, just most of them.

> Well tough luck. you made more money off your "baby" than many country's GDP.

Two things: not my baby, and it is absurd to compare annual corporate revenue to GDP. GDP is a measure of economic activity within a nation, not a revenue figure, and revenue measures money earned before costs are accounted for.

> Governments' interest is in making sure companies do not in fact hoard all the money in the world

This statement is meaningless. A government that sees its role in society to cap profits is one that will assuredly wreck that society.

> and when your product becomes a centerpiece of society something's got to give.

Except that it’s not. Apple’s customers are customers who voluntarily spent money to purchase iPhones when other choices were available to them, and an iPhone is a luxury good, not a necessity. It is lucrative to invest in developing software for iPhones, but there are other businesses to go into.

If the user has not exchanged consideration for the software, what is it, a gift? Do they want it?

You can’t force someone to accept a gift, now you have to sell me iPhone without iOS!

If user just paid for the hardware, locking down the hardware and forcing the user to use iOS is interference with the user’s property, potentially a crime.

Furthermore, you have to provide a user manual For The Hardware separately. How is that gonna work? What does it do without software?

So consequences of taking this route could be even worse - having to allow android to run on Apple hardware or something.

The phone at least in the case of iPhones is the hardware unit plus the software (the operating system, the secure boot environment, the baseband firmware, and the apps bundled with the phone).

sounds good to me. But I don't think anyone's really arguing that here.

>You can’t force someone to accept a gift, now you have to sell me iPhone without iOS!

I mean, for Windows OEMs the licensing cost of windows is bundled in the price. Apple can do the same here. they are buying hardware plus a software OS. they aren't buying the entire app store as those apps each have separate costs assossiated with them. This is more like you can sell me IOS without the App Store (which again no one is really asking for. Just a reasonable option to sideload other stores).

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

It’s been a few years since I’ve left the low lands and a bit longer since I stopped practicing law, so who knows what has happened in the meantime.

I mainly jumped on it because I know of a rental specific statute, having used it a few times, so just assumed that’s what you were talking about.

I haven’t looked into it further so it might just as well be that I was too confident in thinking that’s what you were talking about.

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.

Therefore it's reasonable to assume that the regulators will not be happy with the proposal unless (1) is false.

https://digital-markets-act.ec.europa.eu/about-dma_en

[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.

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?

If I create a platform, and an SDK that targets that platform, and require everyone to pay for the the SDK to use my platform...

... is that the same as if I create a set of libraries (nee game engine) that avoids you from having to recreate that work yourself?

I'd hazard that the two are different, because Epic isn't really gating access to an "Unreal Device" by withholding access to their engine.

A developer is free to use a competitor's engine and distribute the same places. (Afaik, Epic's store doesn't have any "must be built on Unreal" qualifier, right?)

Apple's SDK includes the compiler that target's Apple's chips, a fully-featured IDE, the platform specific APIs (sure), the UI framework, a shader API, a physics engine, etc.

Limiting the ability for dominant companies to crown themselves gatekeepers and toll all who pass was the intent of the EU rules.

If Apple tries to argue that the one SDK is intrinsically tied to the hardware, and also conveniently is required for apps on any store... that starts to sound a lot like 90s Microsoft and Internet Explorer, except Apple doesn't have the "But it's free" defense.

Who is arguing that Apple's libraries don't provide value? Certainly the person you replied to isn't. That's an incredible strawman fallacy

But if we've decided that it's unhealthy to allow dominant tech firms to tax everyone for access to their platforms...

Then an SDK might become the final area where they attempt to do so.

It'd certainly be a lot cleaner if there were 2 SDKs: a base, primitive-only freely licensed one with the bare minimum for interacting with all platform components and a higher-level, premium paid one that had better DX.

This is certainly not normal for any even remotely mainstream desktop or mobile platforms, though. iOS would be a glaring exception.

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.

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.

First of all, MinGW does come with all Win32 headers of their own included, and no, they're not protected IP (or at least Microsoft never made the claim to the contrary).

With respect to C runtime, Windows itself ships with a bunch of them, packaged as system DLLs. MinGW used msvcrt.dll historically, which is the one that originally shipped with VC++ 6.0 before getting included into Windows. Since Win10, Windows ships an ABI stable C runtime called uCRT, precisely so that different toolchains have a single shared library for better interop. Modern versions of MinGW link against uCRT. Visual Studio still ships the C++ runtime, which MinGW doesn't need because it has its own.

On top of that, unlike Unix, in Windows, CRT is not the basic OS API, but mostly a relatively thin wrapper around rich native Win32 APIs, so there are far more around than just different versions of VC++ runtime and glibc. For example, C++ Builder has its own.

If you're a standalone Windows app, you don't have to redistribute DirectX. You can just target the minimum version supported for your matrix. If you're targeting supported versions of Windows (i.e. 10+), that'd be DirectX 12. And then of course you don't have to ship SQL Server Embedded because you don't need to use it; there are plenty of alternatives such as SQLite and Firebird.

Just about the only situation I can think of where you have to pay Microsoft for the privilege of developing for Windows is when writing drivers.

Despite things having changed, though, I think "Windows in the before-times" is still a viable precedent to cite in its own right, for Apple's current behavior. IP case-law hasn't changed too much between then and now.

For example: when developing for Windows 98, you needed to ship DirectX, because otherwise there would be no pre-installed version of DirectX — and the average user's internet connection wasn't fast enough to download it in any reasonable amount of time!

And uCRT + WinSxS preloads both exist now, but obviously, neither did before Windows Vista. Before then, you couldn't predict if any MSVCRT was gonna be available, so if you were trying to publish e.g. Apache Server But Running In a Windows Tray Icon With A Little Management Context Menu (a common thing back then, for some reason), then you needed to package the particular MSVCRT your app was compiled with. Which is why you never saw FOSS binary releases for Windows back then; instead, there was the FOSS project, with compilation instructions that involved downloading the right MSVCRT yourself; and then there were random third-party downstream "freeware" releases published on CNet or whatever.

> and no, they're not protected IP (or at least Microsoft never made the claim to the contrary)

They haven't, because there's nothing to gain from them doing so, because they aren't trying to run an ecosystem that has a per-install fee, unlike Oracle ca 2010, Unity last year, or Apple right now. (And they never will, because they're all-in on service fees (Azure) instead.) Without that incentive, Microsoft has every reason to listen to the competing incentive — that of making Windows a platform that's friendly and open to developers, that doesn't force them through this kind of bullshit.

But if, in some hypothetical world, Microsoft were to be charging developers per app install... then Microsoft would likely tell MinGW to stop redistributing "their" headers, so as to force more developers onto the SDK and through that into being install-monitored. And they would have every right (according to current IP case-law) to do so.

They wouldn't have a mandate to do so, mind you — source files, including headers, are copyrighted, not trademarked, so they don't need to enforce their IP rights to keep them. They could simply choose to enforce their copyright against only the most egregious violators: those who are clearly making millions of dollars off the use of their platform, without paying them a dime. As Apple is trying to do now!

I did years of development work against Windows machines before I got my first paid Visual Studio license, and it was still like a couple years until the first time I bothered actually installing the Windows SDK.

Actually, the result of the Google v Oracle case was ultimately that what Google was doing constitutes fair use - and what MinGW is doing is even more clearly in the fair use zone than what Google was doing. So, current IP case-law is firmly on the side of "copying APIs for interoperability is fair use".

The main reason why people shipped their own version of the CRT for VC++ was because they wanted to use a more modern version of VC++ itself (e.g. because of better support of new language features; C++ was just standardized then and all compilers were updating very rapidly to catch up), which then required a new version of the CRT that wouldn't be guaranteed by the lowest target OS version. But even VC++ did not require you to use the CRT; you could just #include <windows.h> and linker had a flag to drop stdlib.

And even when you wanted to use MSVCRT while targeting platforms where the desired version wasn't guaranteed, you still didn't have to ship it. All redistributable packages were (and are!) also published as standalone installers that users could just download and run themselves; indeed, it was not uncommon for open source Win32 software to require one to do exactly that. The bundling packages that MS also provided for integration with your own installer are a convenience, not a prerequisite.

The story with DirectX is very similar. DirectX did in fact ship as an OS component with every version of Windows starting with Win95 OSR2 and WinNT4. The reason why games pretty much always bundled it is because they wanted to use something newer, given how fast things changed back then. But, again, it was always available separately as a standalone installer, and any app that needed it could request it to be installed manually by the end user, and some apps did just that. I will also note that those standalone CRT and DirectX installers were also commonly redistributed, e.g. on large websites like Tucows.

With respect to Win32 APIs themselves being somehow protected through some form of IP, that wasn't the case, either. Again, Borland C++ / Builder used its own headers with no problem. And then of course pretty much every non-C toolchain that wanted to expose the dev to the OS API also had to provide their own equivalent of windows.h, which they all did - Delphi being probably the most prominent third party example, but there were numerous others - Ada, Eiffel etc; and even most scripting languages such as Perl. Again, back in that period, I myself wrote a bunch of Win32 header translations for then-nascent D. I don't recall anyone ever bringing up the notion that doing so was somehow legally risky; it was understood as an obvious and necessary step in development of any toolchain targeting the platform.

XP era also includes early .NET. The interesting thing about that one was that the .NET Framework redistributable (which, again, was provided as a standalone installer) also includes the C# and the VB command-line compilers, and since .NET metadata is embedded into the binaries, the result is that you effectively got a free build toolchain that let you do anything .NET could do. XP SP1 even included .NET 1.0 builtin, which I believe was the first time Windows came with dev tooling sufficient to write a full-fledged app for itself in the box.

The bit about "you never saw FOSS binary releases for Windows back then" is plainly not true. FOSS in general wasn't nearly as widespread then, and people who cared about it generally didn't care much for the DOS/Windows ecosystem, so mainline would often not even bother and just assume POSIX, and porting was a slow effort that required constant ongoing maintenance to keep up-to-date with upstream. But what did exist would normally be redistributed in binary form; examples include MinGW, Perl, and Python. Similarly, when using FOSS libraries like zlib, it was common to download and use redistributed prebuilt DLLs + import libs for your compiler.

So, to summarize: Microsoft never charged developers for access to the platform itself, and you could always write and distribute Windows apps without paying anything to MS. It charged the devs for tooling, but it also left the door wide open for alternative tooling, which did proliferate to the point where in some markets like Europe there was more Windows software written using Borland tools rather than Microsoft tools.

You are arguing that a replacement for windows with an identical API would be protected IP. Not the toolchain for building applications.