Apple's docs doesn't seem to have any mention of self-hosted extensions (unlike safariextz), so it's most likely only available through the Mac App Store.
Because of the distribution method mentioned above, packaging a Safari WebExtension won't be as straightforward as zipping the extension unlike Chrome/Firefox as you (most likely) need to face the intricacies of Xcode signing.
The distribution method is similar with Safari App Extensions, the user needs to download a wrapper app that provides the Safari extension inside.
The user needs to explicitly grant each extension access to a specific website in order for the extension to function, this is something that Chrome is also trying to do but probably quite hard without breaking existing extensions.
Safari extensions always run on Private Browsing windows, unlike Chrome and Firefox which disables all extensions on incognito by default.
Devtools extensions such as React Developer Tools or Vue.js devtools.
Ad blockers because webRequestBlocking isn't supported, but Safari has their own content blocker solution.
Overriding the new tab, but then, Safari already has a built-in setting to change the new tab anyway.
Not every type of extension is possible:.
Safari's WebExtensions implementation isn't feature-parity (and they most likely don't intend to be), so it's important to check Apple's docs, plus reference the browser compatibility tables for manifest.json and the various JavaScript APIs.
The official guides provided by Apple (a bit buried): Safari 14 now supports WebExtensions, in addition to Safari App Extensions and after killing off Legacy Safari Extensions (.safariextz)
0 kommentar(er)
