Hey, remember how a change was made to more accurately scan private API use for Mac App Store apps, and it caused Electron apps to be rejected because they rely upon Chromium? And even though these apps are still available for the Mac, they’re just not in the Mac App Store until the Electron project excludes said private APIs?
In Owen Williams’ eyes, this is nothing less than Apple “trying to kill web technology”. That’s right: Apple is trying to kill the web on all of its platforms, starting with the Mac:
But Apple has a reason not to like this recycling of web technology. It wants its Mac App Store to be filled with apps that you can’t find anywhere else, not apps that are available on every platform.
That’s why they’ve been so hesitant to promote cross-platform apps like those in the Microsoft Office and the Adobe suites, going so far as to only give them a few minutes of keynote time and publishing their press releases.
Electron has used these private APIs for years without issue. These private APIs allow developers to, for instance, drastically improve power usage whereas Apple’s sanctioned tools make the user experience worse. In the majority of these cases, Apple doesn’t provide real alternatives for developers who want to access these private API features.
Are private APIs unfair? Almost inherently so. Should the use of any API be withheld from distributed software until a public API is available for third-party developer use? That’s debatable.
But, again, Apple is not prohibiting the use of private APIs generally; they just don’t want apps in the Mac App Store that use private APIs. That’s a big difference.
Also, for what it’s worth, the Mozilla post that Williams links to doesn’t actually say that they’re using any restricted or private APIs, just that they updated Firefox to use Core Animation to improve its battery life and performance on MacOS.
Developers could distribute their apps from their own websites, asking users to download them directly. But that means abandoning features like Apple’s auto-update mechanism from the Mac App Store and iCloud sync. And this direct-to-consumer method could soon be locked down, too, with Apple’s controversial notarization requirements potentially requiring their review.
Setting aside the ability to use iCloud syncing in apps not distributed through the Mac App Store, notarization does not equate to locking down MacOS to outside distribution, despite Williams’ scaremongering. I have problems with notarization and Apple’s strategy for MacOS security, but Williams’ interpretation is overly simplistic and dependent on fear.
Williams follows with a couple of examples of how Apple does not implement new web standards as quickly as other browser makers do, and that leads him to this thesis:
Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy: Make it so painful to build with web-based technology on Apple platforms that developers won’t bother.
First, the premise of this argument isn’t a secret, nor is it new. Apple has long said that apps which are basically wrappers around websites should just be websites — most recently in September.
Second, Apple continues to develop and improve upon in-app web functionality, including fixing things like lacklustre WebRTC support in third-party apps, something Williams complains about in his post.
Third, encouraging a distinction between apps and websites does not therefore lead to the headline “Apple Is Trying to Kill Web Technology”. That’s rounding up to the nearest crisis position, and is wildly misleading. Plenty of ostensibly native apps continue to use web technologies — even many of Apple’s.
Apple has done a lot of stupid and controlling things in the moderation of their App Stores, but this isn’t one of those instances, and it certainly does not produce the panic-inducing headline of Williams’ post.