While I’m waiting (too long) for Apple to review my App Store app update, I decided to write a blog post.
In 2021, Apple introduced support for extensions in mobile Safari. This bold, unexpected, spectacular move reshaped the web browser extension landscape and, from a personal perspective, changed my life as a Safari extension developer. It was a quintessential Apple “surprise and delight” moment. Since then, however, Apple has behaved too conservatively with regard to Safari extensions, largely conceding its momentary leadership role to Google in guiding the direction and future of web browser extensions. This is unfortunate, because Google is a poor steward. More than four years later, Google has neglected to add support for extensions in mobile Chrome, not only on iOS, where Apple’s WebKit engine requirement may pose technical difficulties for extensions in non-Safari browsers, but also on Google’s own mobile operating system Android. There’s no excuse when Google controls the entire technical stack. Firefox, I should note, does not support browser extensions on iOS either, but Firefox does support extensions on Android, which proves that Google and Chrome simply don’t want extensions on mobile. Worse, Google has intentionally debilitated and decimated its desktop browser extension ecosystem—as well as the extension ecosystems in all browsers based on Chromium, such as Microsoft Edge—via the removal of support for Chrome extension manifest version 2, replacing it with the vastly inferior manifest version 3. This is a classic “embrace, extend, and extinguish” strategy, pioneered by Microsoft. So far, neither Safari nor Firefox has followed Chrome in removing support for MV2, at least not yet, but both of those browsers have spent—wasted, in my view—a lot of engineering resources adding support for MV3. I wish they had just said no, and let Chrome self-destruct. The cross-browser WebExtensions Community Group operates by consensus, as one would expect in such a group, but the discussion and consensus appears to be based on Chrome manifest version 3. The browsers with better extension API are allowing the browser with the worst extension API to set the agenda for all extension API, despite the fact that Chrome extensions are irrelevant on mobile, which has a much larger user base than desktop.
In my opinion, the greatest advantage of Safari extensions is their built-in native platform integration. Every Safari extension, on both iOS and macOS, can use extension native messaging with no additional software installation or configuration by the extension user, because Safari extensions are designed to be distributed inside native apps. Chrome and Firefox cannot match this experience. They require every extension user to install a special native messaging configuration file in a specific, obscure, hidden location in the file system. And they require every extension developer to reimplement the entire native messaging protocol in their extension and native app, whereas Safari provides the native messaging API ready-made to all developers in a system framework.
I would like to see Safari double down on its native platform advantage. For example, Safari extensions on iOS currently support only HTML/CSS/JS popup windows, which of course allows cross-browser and cross-platform compatibility. And on desktop, this compatibility is important. On the other hand, it’s less important on mobile, for a few reasons. First, Chrome and Chromium browsers do not have extensions on mobile, so there’s nothing to be compatible with in that respect, and Firefox has extensions only on Android. Moreover, even if a developer is porting an extension from desktop to mobile, a popup window designed for desktop would be a poor fit—literally!—on mobile. You probably don’t want to use the same HTML and CSS in a mobile extension popup window that you use in a desktop extension popup window. The user interface needs to be designed specifically for mobile screens.
A few years ago I wrote about the four types of Safari extension, one of which was discontinued in 2019 and one of which is supported at present only by macOS Safari. The latter type, Safari app extensions, have a native macOS/AppKit user interface for their extension popup windows and contextual menu items. My own extension StopTheMadness, first released in 2018, is a Safari app extension on macOS because Safari web extensions, another one of the four types, were not introduced until 2020. A couple of years ago I wrote about how Safari can improve extensions, and one of my suggestions was to combine the app extension and web extension API.
One massive advantage of the Safari app extension API is that it allows the extension to display a native AppKit user interface in the Safari extension popup, while Safari web extensions must rely exclusively on HTML and CSS. I would love to be able to display a native UIKit user interface in Safari extension popups on iOS, because HTML is so clunky, limited, and ugly in comparison.
I continue to believe that building on native platform features would be advantageous to Safari extensions. I’m not suggesting that Safari remove cross-browser and cross-platform support but just that Safari add native UI features as an option to extension developers. After all, no extension developer is required to use native messaging in Safari. This powerful feature is available as a built-in option for those extension developers who can make productive use of it. My own extension depends on native messaging to support iCloud sync of extension settings (which Apple itself has thus far failed to provide).
The Safari app extension contextual menu item API is quite nice and very flexible. In contrast, the Chrome extension contextual menu item API is awful and extremely inflexible. The Firefox contextual menu item API is slightly better than Chrome with the addition of onShown and getTargetElement but still inferior to Safari app extensions. This is another case where the native platform integration is a big advantage, and I think it’s a shame that Safari web extensions limit themselves to emulating the lowest common denominator, Google Chrome.
I have no insider information, but what I’ve seen coming out of Apple in Safari updates over the past few years has been mostly enhanced Chrome MV3 support for Safari extensions. Most of the suggestions in my aforementioned blog post have not been implemented. One small improvement that finally shipped in iOS 26.2 was a native API to open Safari Extensions Settings and to detect whether your extension is enabled in Safari Extensions Settings. This API already existed practically forever on macOS. As far as I’ve seen, though, major innovation in Safari extensions has been lacking since the great leap in 2021. Apple did introduce extension support (Safari web extension support, anyway) for Safari web apps in 2024 on macOS but not yet on iOS. Still, the prospect of WWDC—in June, only five months away!—always brings renewed hope for innovation and improvements. Although many, perhaps most WWDCs have been disappointing to me, there are exceptions, such as WWDC 2021. I’m crossing my fingers for another exceptional year.
P.S. Longtime followers know that I’m no Pollyanna. I hope for the best but prepare for the worst. In contrast to the best case scenario, a host of Safari extension enhancements, the worst case scenario is that Apple simply deprecates Safari app extensions with effectively no equivalent replacement. That would be a disaster, both for Safari users and especially for me as a developer. I pray to the gods that Apple does not choose this road, the highway to hell. Needless to say, though, these are the same people who thought that Liquid Glass was a great idea.