TThe programming languages used to build the web often find their way into apps, too. That’s largely due to software that allows developers to “reuse” the code they write for the web in products they build to run on operating systems like Linux, Android, Windows, and macOS.
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. With a recent policy change, the company has made it a little more difficult for developers to submit apps containing web code.
The Mac App Store has quietly started rejecting apps made with a popular tool called Electron that allows developers to base all of their apps on the web-based code. Some of the most popular apps in the App Store, like Slack, Spotify, Discord, and WhatsApp, fall into this category.
In a discussion on the programming community Github, several developers say rejections for apps that they built using Electron — which would were approved in the past — came with an explanation that these apps “attempt to hide the use of private APIs,” which are APIs built for Apple’s internal usage, rather than for third-party developers. Using private APIs to build public-facing apps is commonly frowned upon because they may change or break over time, and Apple bans apps that use them.
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.
Now it’s unlikely that the thousands of developers who have built their apps using Electron can release updates to them unless the Electron framework releases a major change to its implementation.
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.
Apple has a history of stunting the web’s progress on its platforms. On iOS, Apple doesn’t allow fully independent third-party browsers, requiring all apps to leverage its Safari browser when rendering web-based content. While browsers like Chrome and Opera are available in the App Store, they must use Apple’s Safari browser behind the scenes to render web pages, rather than their own. That means Apple has a monopoly on how iPhone and iPad users access the web. To push developers toward building native apps on iOS rather than using web technologies, Apple ignores popular parts of the open web specification that other browsers implement, to its own benefit.
Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy.
A technology called WebRTC, for example, allows video calling in a web browser without additional software. It powers tools like Google Meet. But Apple was incredibly slow to implement the specification, leaving out key pieces of functionality, and the technology didn’t work when embedded inside apps.
Apple also handicapped an emerging standard called Progressive Web Apps (PWAs) — which, like Electron, allows developers to build native-like apps for both desktop and mobile — by partially implementing it in a way that makes it too inconsistent to rely on. PWA doesn’t have the same problem if users open apps in Chrome or Firefox, but iPhone and iPad users can’t install third-party browsers, which makes PWA-based technology a non-starter.
Developers use technologies like Electron and PWA because they allow for faster updates across platforms without an array of different codebases. Some argue that this results in lower quality apps, but I’d argue the alternative is no app at all or apps that are rarely updated because maintaining unique Windows, Mac, and web-based products is complex and expensive. Apple recently launched a competing framework called Catalyst, which allows developers with iPad apps to bring them to macOS quickly — a great tool for developers exclusively targeting Apple users, but not those building cross-platform apps.
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. Now that the App Store is not accepting apps built using Electron, developers will likely find creative ways to work around it, but Apple is setting up for a continual cat-and-mouse game as it plans to exert more control over which apps can run on the platform in the future.
These types of changes may be made in the name of privacy or security, but the reality is that the argument looks weak when both users and developers simply don’t have a choice because Apple controls the platform, browser engine, and the distribution method. Regardless of your opinion of Electron app quality, choice is important.
Apple’s control over its app ecosystem is a new type of monopoly that’s hard to understand for lawmakers, and difficult for us to fight back against — because there simply isn’t a way out of these restrictions when the company controls both the distribution method and the platform itself.