This blog post attempts to give an overview of what happened to Safari extensions in the past few years, from the perspective of a developer (me) with many years of experience working on Mac apps and Safari extensions.
Safari extensions were introduced in 2010 with the release of Safari 5. By design, Safari extensions were very similar to Chrome and Firefox extensions, so it was feasible for a developer to write an extension for all of those browsers using standard web technologies: JavaScript, CSS, and HTML. Apple opened a free Safari Developer Program to allow developers to securely sign their extensions for distribution. Extensions were distributed in the safariextz file format either directly by the developer or by Apple in the Safari Extensions Gallery.
Since 2018, the Safari extensions situation has changed radically. Apple deprecated safariextz extensions with the release of Safari 12, and support for them was removed entirely with the release of Safari 13 in 2019. Instead, developers were told to create Safari app extensions, distributed in the app file format just like any other Mac app. Safari app extensions still use JavaScript and CSS like before, but standard web technologies are no longer sufficient. It's now impossible to create a Safari extension without also writing native code — Objective-C or Swift — and compiling the Safari app extension in Xcode on a Mac. Moreover, in order to distribute Safari extensions, developers must join the Apple Developer Program, which costs $99 USD per year, even for free Safari extensions. There are fee waivers available to accredited nonprofit, educational, and government organizations, but the waivers require official documentation (a lot of red tape) and are not available to individuals such as hobbyist developers. (For comparison, Firefox has no extension developer fee, and the Chrome Web Store has a one-time $5 USD fee.)
Contrary to widespread misconception, Safari app extensions don't have to be distributed in the Mac App Store. Safari extensions can be distributed in the Mac App Store, but developers also have the option to directly distribute a Safari extension on the web. However, a Safari app extension distributed outside the Mac App Store must be signed with an Apple Developer ID certificate, and it must also be notarized by Apple in order to run on macOS 10.15 Catalina.
As a result of the change in format from safariextz to app, Safari extensions have been decimated. There are significantly fewer Safari extensions available. The developer program membership cost factor is obvious, so I won't spend any more time discussing that. I believe that the biggest barrier now to creating Safari extensions is not money but developer expertise. To create an extension for Firefox, Chrome, or any browser based on Chromium — Microsoft Edge, Brave, Opera, Vivaldi — you just need to know JavaScript, CSS, and HTML. In other words, almost any web developer in the world can create an extension for almost any web browser in the world. All these worlds are yours… except Safari! Attempt no landing there. Safari is unique, unprecedented in its extension requirements. Safari extension developers still have to know web development, but they also have to know native Mac development. Mac developers themselves are unfortunately a dying breed, but even during the "glory days" of Mac OS X development (before iPhone), Mac developers were a small fraction of software developers, always vastly outnumbered by web developers. And the intersection between Mac developers and web developers is smaller still. Apple, in its infinite wisdom, has decided that Safari extensions are to be created only by developers who are experts in both native Mac development and web development. This is one of the smaller developer pools you can imagine. No wonder it's so hard to find Safari extensions nowadays. In a sense, I can't complain, because this bizarre situation has opened an opportunity for me personally, as a member of that very small developer pool. Nonetheless, I don't think the elimination of safariextz has been good overall for the Safari extension ecosystem, and perhaps my uncommon position makes me especially qualified to write an article discussing this problem.
Apple has been trying (mostly futilely) to "revive" Mac development via Catalyst, a technology that enables iPad apps to be directly ported to Mac. Catalyst allows the very large pool of iOS developers to participate in Mac development. This doesn't help at all for Safari extension development, though, because Catalyst apps don't support Safari extensions. Why not? Sadly, Safari for iOS doesn't support extensions, and thus iPad apps don't support Safari Extensions. Unless Safari for iOS (or iPadOS) adds extensions, which in my opinion is highly unlikely, it's also unlikely that Catalyst will add support for Safari extensions. After all, Apple went out of its way to invent a separate technology for iOS: Safari content blockers. Unlike Safari extensions, which can execute arbitrary JavaScript code in the context of web pages, Safari content blockers can only use limited, predefined blocking rules, defined via a JSON array. According to the beta release notes, support for Safari content blockers will be added to Catalyst in macOS 10.15.4. (Safari content blockers are supported on both iOS and macOS, unlike Safari extensions.) In contrast, Apple has announced no plans or intentions to add Safari extensions to Catalyst.
The paucity of publicly available Safari app extensions doesn't reflect the full extent of the decimation of the extension ecosystem caused by the elimination of safariextz. We don't see it, we can't see it, because not all Safari extensions were distributed to the public. A lot of people who know a little JavaScript wrote Safari extensions for themselves, for their own personal, idiosyncratic use, to be run only on their own Mac. Previously, knowing a little JavaScript was all it took. Now, however, knowing JavaScript is not enough. In order to create a Safari extension for your own personal use on your own Mac, you still have to know native Mac app development and how to work with Xcode. This is a huge hurdle for the hobbyist. In effect, Safari extension creation has been removed from the reach of amateurs and has now become an activity accessible only to professionals. The few professionals who remain.
If you're wondering why your favorite old Safari extension hasn't been ported to a new Safari app extension, the reason isn't necessarily just lack of native Mac development expertise by the developer. Even though an app extension still uses JavaScript and CSS like a safariextz, the new API is not the same as the old API. Developers can't simply take the old JavaScript and stick it inside a Mac app bundle, that's not how it works. The new SafariServices API is simply not as powerful as the old Safari JavaScript API. There are things an extension could do in the past that it can no longer do. The most prominent difference is the old canLoad API, which allowed Safari extensions to block content from loading. This API has been removed completely, which is why ad blockers such as uBlock Origin can't be ported to a Safari app extension. The reason is not lack of effort or expertise; rather, it's technically impossible now. Apple wants developers to switch to the more limited, non-JavaScript Safari content blocker API instead.
That's not the only example. I won't discuss the API differences in depth here, but speaking generally, an app extension has less control over Safari's user interface than an old safariextz did. I believe that change was intentional by Apple, who may cite "security" as a justification, but regardless of the justification, there's no guarantee that that the functionality of a safariextz can be ported to a Safari app extension, even if the developer has the desire and the skill.