By Jason Snell
January 15, 2021 1:25 PM PT
At WWDC 2020, Apple announced it was going to support Chrome-style browser extensions (the WebExtensions API) in Safari. But with a catch, as Dan pointed out:
Apple’s approaching this in an unsurprisingly Apple-like fashion. If you want to distribute a web extension, it’s got to be wrapped in a native Mac application designed in Xcode. Installing the app from the app store will also install the web extension.
At the time, it seemed to me like it might all amount to nothing if extension developers didn’t want to do the extra work to get up and running in Safari:
That’s a lot of barriers just to reach Mac users running Safari who could just as easily open a different browser to get that functionality…. If you’ve got a favorite Chrome extension that you’d like to see come to macOS, you may need to write to the developer and try to convince them.
I hope Apple makes this work and Safari gets a much richer extension library out of this, but there’s also a scenario where plug-in developers just don’t bother with Safari. That would be a shame. We’ll see.
Months after Safari 14’s release, are developers “bothering with Safari?”
The answer seems to be largely no—at least, not yet. The Mac App Store’s Safari extensions library seems to be largely populated with the same stuff that was there before Safari 14 was released, though there are some exceptions.
PocketTube is a YouTube-focused extension that recently added Safari support. OneTab coalesces open tabs into a single page. And Blue Canoe Dictionary lets you highlight English words and learn how to say them
Tony Andrews of Blue Canoe Learning says that Blue Canoe was happy to port its extension to Safari, motivated by the ability to reach all of those Safari for Mac users who were previously unable to use it. “It definitely helps if you’re already familiar with the Apple developer tools and ecosystem,” he told me, and said the process went very smoothly.
Andrew Abrahamowicz is the developer of the excellent Library Extension, which overlays book availability from your local library on top of book-related pages at sites like Amazon. Abrahamowicz has been developing Library Extension for a decade now, and while it doesn’t support Safari yet, he’s working on it.
Abrahamowicz told me that since Library Extension isn’t his day job, he’s limited in the amount of effort he can give to it—and of course, supporting a new platform takes a lot of extra work. However, I discovered that Abrahamowicz had recently gotten a new M1 Mac and had begun work on a Safari version of Library Extension. Beyond needing to get set up with Xcode, Abrahamowicz has had to deal with some specific security limitations Apple applies to extensions, which may require him to actually write some Mac-specific code in order to give the Safari version of Library Extension the same features it has on other platforms.
I was encouraged by Abrahamowicz’s interest in building a Safari extension, but my conversation with him also highlighted some of the barriers many extension developers may have: Limited time, lack of access to Apple hardware, unfamiliarity with Apple’s developer tools, Safari’s incompatibility with some existing extension-development tools, and the requirement to make some code changes in order to fit inside Apple’s security model.
Even the most popular browser extensions are, like Library Extension, the product of someone who is scratching their own itch in their spare time. If that person doesn’t use Safari or even own a Mac, it’s a lot harder to imagine they will do the extra work to bring their extension to Safari users.
Take Beyond20, an excellent extension that connects the D&D Beyond character sheet to virtual tabletop services like Roll20. When I want to use Beyond20, I have to switch to Chrome or Firefox, but when Apple made its announcement last year I wondered if I might one day be able to use it in Safari.
A visit to Beyond20 support cleared that up in a hurry. Beyond20 project owner Youness Alaoui wrote:
This wouldn’t happen unfortunately because I don’t use Safari and it’s not chromium based so it would require additional work to get it working. Even Microsoft have contacted me asking to add the extension to the Edge store (zero changes required) and I’m hesitating because of the extra overhead in submitting the package to yet another site upon release.
Getting it to work with Safari would be a headache in itself that I don’t think I’ll ever be ready for. Sorry!
Alaoui’s reluctance to submit his extension to Microsoft’s directory says it all—it’s more work, and commitment to ongoing support, for what is essentially a passion project. (And presumably there’s also the $99/year cost of an Apple developer account, which is beyond the scope of a lot of these projects.)
So in the end, what was the net effect of Apple’s announcement of support for the WebExtensions API in Safari? It’s a work in progress. A very small number of extensions have appeared in the App Store, and it seems quite likely that others will follow at their own pace. Other developers remain utterly unmoved by all the extra work moving to Safari would entail.
It strikes me that Apple could rapidly drive adoption of Safari extensions if it would finally bring that technology to iOS. Targeting the Mac is nice, but if they could target iPads and iPhones, we might really have something.