Yes because theyre distributed through the app store.
If you distribute via sideloading - Apple cannot claim that they had to incur the costs of vetting each update, distribution, payment processing, security, server maintenance, etc.
I had posted a separate comment on the ruling that discusses this point.
The district court and the appeals court both agree that Apple is well within its rights to charge developers $99 initially and x% of revenues, under the principle of what they are calling IP compensation.
The district court did not completely agree to Apple's argument that 30% is fair (they expressly rejected it) and the appeals court observed that Epic's tactic on this argument was legally flawed and mentioned something to the effect of Epic should have used a different argument (and since they didn't, we are not ruling on this). To me, this looks like a vulnerability for Apple that they could be attacked by a different plaintiff using a different legal theory.
It seems like you're saying that there can exist enforceable revenue-sharing agreements between developers and Apple. But with sideloading, I don't see why a developer would have to enter into any contract with Apple in the first place? And in the absence of any contract, surely Apple would have no right to a developer's revenue?
The court held the Apple DPLA (developer program license agreement) as an adhesion agreement. If you want to develop apps for Apple you need to sign that. I think that is also needed to get their compilers, SDK etc., that provides apps access to their IP (i.e., the device, ios etc.,).
While the contours of how sideloading is going to unravel is unknown at this time, it is possible that Apple may still use some form of app notarization (perhaps an API for 3rd party stores and require that the stores use those APIs -- similar to their stance on webkit).
Then, similar to the Netherlands case where dating apps were allowed alternatives to InAppPayments, but charged 27% commission, Apple might charge a discounted commission (relative to the 30%) for sideloaded apps.
They will look to get their cut.
I don't like it, but that seems to be where this is headed.
It's at least technically possible to build an iOS app without any Apple tools. It seems like there are some guides already (https://vojtastavik.com/2018/10/15/building-ios-app-without-...), and I imagine it will become easier if there's suddenly a lot of interest in avoiding Apple tools.
I agree it's not entirely clear how this will play out, but I don't think a simple policy of sideloading only apps approved by Apple (or someone acting like their proxy) would be compatible with DMA rules like
> The gatekeeper shall allow and technically enable the installation and effective use of third-party software applications or software application stores using, or interoperating with, its operating system and allow those software applications or software application stores to be accessed by means other than the relevant core platform services of that gatekeeper.
There are some security-related caveats, so perhaps Apple can use those as a pretense for denying sideloaded apps access to a bunch of features, but I don't see how they could block simple games etc.
But they didn’t get past signing. They did the signing steps themselves but still used a developer account. The iPhone will not run unsigned code and you can’t get a signing key without the help of Apple.
Apple has enough security to ensure nothing gets on the phone without their signing, and legally they are in full control over that and can set the terms (within what’s legal for contracts). No court or law has yet said that has to change.
People have speculated that side loading may work by Apple just letting you download the fully signed IPA file, as it would exist in the App Store. That way side loaded apps would pass the security checks but Apple is still in full control.
IANAL, but to me "allow and technically enable the installation and effective use of third-party software" sounds like a broad rule. There are a few exceptions mentioned in that provision, but it doesn't seem like a gatekeeper would be able to just come up with their own exceptions where they won't follow the rule, like "except for apps we don't like" or "except if the developer hasn't agreed to pay us".
Apple will be required to "allow and technically enable the installation and effective use of third-party software applications".
IANAL, but I doubt a policy of "sideloading is allowed, but only for apps that we approve and/or developers who pay us" would be considered compliant with that.
They could enforce some sort of signature requirement, but if they tried to force developers into some sort of business relationship before being able to sign, that seems like failing to allow third-party software.
Apple's commission could very well be on the basis that they create and maintain the APIs, libraries, and GPU that enable the developers to distribute on iOS at all.
but if you run on their OS and use apps that take advantage of iCloud or push notifications or any host of apple services, none of that is free. those apps are getting tools and support and features as well as OS APIs to use.
Then charge people for it. Developers are the people enabling and exposing this functionality, not the ones using it. Apple gives away the Apple services and iCloud functionality to all of their users - if these are expensive then it makes no sense to charge the developers for it. By your logic, this "expensive OS" theory should be amortized by an iOS subscription service - but it's not. Apple chooses to develop iOS, it is not democratically compensated somehow by the success of the App Store.
Orwell himself warned of the "perversions to which a centralised economy is liable", maybe the company that spoofed 1984 should take it to heart. The optics of the world's largest business doubling-down on their right to control what their customers use is a bit dystopian, if I say so myself.
But that assumes that Apple is the marketplace in the first place.
The best way to think about this is in terms of accesories for physical products.
Unofficial aftermarket accesories are considered completely legal to make and sell, without paying a dime to the base product's manufacturer. Such should be the case with iOS. Apps are essentially "digital accesories".
This feels a lot like a case where the EU may have wanted Apple to lose all their controls but they didn’t put it in the law.
Apple can still charge 30% (perhaps minus CC fees). They can still force you to be a developer in good standing. They can still limit what apps can do via their APIs. Heck they might be able to give App Store apps extra privileges because the developer choose the App Store.
If they wanted iOS to look as open as Windows or MacOS they needed to specify that.
The problem is that, at least in Europe, the intent of the law is evaluated just as strongly as the letter of the law.
So, if we got this law that very clearly says it shall be easy to technically and effectively install third-party apps as a user, and also contains provisions that say third-party apps must get the same API access first-party ones get, it would be ridiculous for a court to reach the conclusion that it's acceptable for a developer to still be subjected to Apple's whims, except now they're being screwed inside their own infra!(tm)
I would have said the same thing about allowing third-party payment providers but we will see. I have no doubt Apple could come up with some kind of "justification". Do they start charging for Xcode if you don't distribute through the App Store? "Xcode Pro", only thing that can build for sideloading and it costs $X/yr or "Any app built with it must give X% to Apple"?
If you distribute via sideloading - Apple cannot claim that they had to incur the costs of vetting each update, distribution, payment processing, security, server maintenance, etc.