Interesting, I had not heard about this (looks like it was announced at the most recent WWDC), but the Vimium devs already have![1]
Vimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari.
Given all the hype around Safari’s performance on new M1 Macs (and the fact that only Safari supports Apple Pay), I’d love to have parity on these two extensions extensions. It seeems like Web Extensions will not provide enough to fully support uBlock Origin, but maybe their Content Blockers will be a close enough approximation.
At the very least, I hope that Safari will gain a larger userbase from these changes, regardless what I choose to use. Having multiple large, evenly distributed userbases will only make web developers think more about Chrome-first or Chrome-only development.
I was under the impression that certain functions required by uBlock Origin still weren't available even though Apple embraced WebExtensions. I may be wrong.
You are correct. Safari does not support webRequest blocking and will almost certainly never support it. Indeed, Google Chrome has already announced its deprecation of this API.
That's almost certainly what it is, in addition to performance. Apple supports ad-blockers, but they work by providing a list of rules to Safari, which uses the rules to filter resource loading (rather than allowing the ad-blocker to intercept individual requests).
It should be noted that there's a significant difference between Safari and Chrome in this respect, however. Safari content blockers are not actually JavaScript at all, they're nothing more than JSON rules, so content blockers have no webRequest API usage whatsoever. Whereas Chrome extensions are JavaScript, with webRequest capabilities.
Safari Mac does have JavaScript extensions too (iOS only supports content blockers), and everything gorhill says does apply to them. And indeed some vendors ship both a content blocker and a Safari JavaScript extension in the same Mac app (though each one has to be enabled separately in Safari). Thus, it could be argued that this is a distinction without a difference. But from a technical perspective they're entirely different technologies.
The macOS 10.15 SDK did add an API for a Safari JS extension to receive information from a content blocker embedded in the same Mac app, allowing for example the extension to show stats for blocked resources:
https://developer.apple.com/documentation/safariservices/sfs...
My personal theory is that Safari content blockers were designed primarily for iOS, which has no Safari web extensions, and the Mac side was a bit of an afterthought.
for what it's worth I've got a Pi-Hole running on my local network instead of in-browser adblock, and it's pretty good, and before that i had some success with 1Blocker, which IIRC uses the same lists as uBlock Origin.
YMMV (probably depends on the subset of the web that one visits) but I've had good luck with Wipr under Safari. Once in a while something slips through but it's generally ~99% as effective as uBO when it comes to visible ads. The difference is small enough that I'm not inclined to use a different browser.
Also, generally speaking, the way Safari implements this means that the extension passes on the block list to the browser and Safari itself implements the blocking. This means,
1. It is more private since the extension does not have access to your webpage.
2. It is faster because Safari can do it natively and it is not done in JavaScript.
Too true. I have Safari with 1Blocker / Wipr, through a PiHole that uses NextDNS for DNS resolution. All other browsers feel like wading through treacle. Whenever I'm forced to use Chrome on someone else's device I'm gobsmacked at how anyone could put up with something so slow and clunky.
Never. The Safari team already (wrongly) feels that their Safari-specific "content blocker" API is adequate, and moreover, Google Chrome has announced the deprecation of the webRequest blocking API used by uBlock Origin, so it almost certainly won't be ported to Safari, and it's an open question how long uBlock Origin will even last on Chrome in the future.
This is unhelpful quibbling over the semantics of one word. You know what I meant. Everyone knows what I meant. I even explained in more detail what I meant. You're also wrong about the word, but I'm not going to bother arguing that here.
Please refrain from writing "this meat smells funny" comments on HN. You could go around commenting on typos too, which happen all the time, but that's not at all helpful.
Definition of adequate
1 : sufficient for a specific need or requirement
adequate time
an amount of money adequate to supply their needs
also : good enough : of a quality that is good or acceptable
a machine that does an adequate job
: of a quality that is acceptable but not better than acceptable
Her first performance was merely adequate.
Plenty of developers use inadequate tools every day, as evidenced by the population of Mac owners. The success of deeply flawed languages like Java and Javascript are also good examples. Ultimately though, using Safari is no laughing matter. Any browser without uBlock Origin is off to a pretty terrible start, and since Big Sur, Apple has made it impossible to browse the web without them phoning home and farming analytics from your machine. Ironically, Safari has become one of the least private browsers available, simply by the virtue of it's presence on Big Sur.
That one's really simple, but doing the Firefox port first seems to have ironed out most of the compatibility issues. Mostly APIs with newer versions where Chrome is the only one to support the old API.
But just exploring web extensions a bit (this was my first time interacting it), it feels like supported features differ quite a bit between browsers. Chrome has the lead here, and Safari seems 'minimal' in comparison. UI elements can also behave very differently between browsers.
Apple is dead-set on having you use the App Store to distribute even web extensions. The converter works fine, but just this way of doing things does bring along a bunch of frustration for unfamiliar devs. There was a Twitter thread on this recently started by a member of the Safari team, which gives an idea: https://twitter.com/jensimmons/status/1338558758025367553
It's nice that it uses a standard API now. But it seems to me that the long tail of one-person-developed hobby extensions will still be completely turned off by the prospect of paying $99/yr indefinitely to be able to distribute the extension (App Store membership).
Yeah, this baffles me. I can't figure out why this still exists. I've got to imagine the volume of people paying that fee specifically to develop Safari extensions has to be low.
Thing is Safari is a nice browser to use, but without uBlock Origin it's a non-starter for me, all these 'content blocker' solutions are either bloated or nowhere near as good as uBlock Origin.
the fee exists, at least from what I have gleaned historically, to provide some mild barrier to people who would otherwise spam the App Store with crap. By building a modest amount of hoops, it keeps the laziest spammers out. (Also something about "paying to keep the lights on", as if AAPL needs money these days)
In practice, well, just search this site for threads about it. I'm not sure, like you indicate, it's worthwhile for the browser ecosystem.
The irony of calling content blockers, which provide prebuilt block lists to the browser, to compile into an efficient format, “bloated” while suggesting that JavaScript extensions running before every single resource request to check if it should be blocked are not, is beyond ridiculous.
Most extensions could likely be built and tested just fine on a ~$250-$350 used Mac mini. That's probably still more money than should need to be spent, but a brand new machine probably isn't necessary in this particular case.
I was thinking on that. You still need peripherals if you're using a Mac Mini, though that's no different than if you were using another desktop. Still though, if you don't use, or don't want to use a Mac as your daily driver, that's a dedicated machine just to build/publish an extension for a browser. IMO, there's a slightly stronger case for iOS apps, but requiring that for a browser extension is much harder to justify.
However, if you're the creator of a Firefox/Chrome extension, and want to utilize the WebExtension support in Safari, your deployment workflow can no longer be platform agnostic.
I've done this to build for MacOS, and it still becomes like a tax as the hardware ages out and Apple insists you have the latest OS to publish to their stores.
I just tried converting our Chrome Extension and the process on the surface seemed pretty seamless. It doesn't seem like Safari supports web Bluetooth yet though, so aside from displaying my icon and accessing my config page, I can't really do much else.
Safari have been messing extension developers around for ages now. It's been hugely frustrating. When you dig into the data, most of Safari traffic is from iOS so most devs just can't be bothered to port to Safari. The $99 is just another kick in the face. You might think it's quick and easy to convert, but Safari has all sort of annoying inconsistencies that make it a huge amount of work. For any small software company it's just not worth the effort. Safari should incentivize people not disincentivize them.
Yes, it's also really buggy. One of the API calls return bad data (after the mac wakes from sleep). Side loaded extensions get corrupted on some macOS/Safari updates requiring the user to fully reinstall apps.
They make reporting bugs impossible because you can't just reproduce it by updating your OS again. Native app messaging is done through shared data which forces you to poll for updates.
Urggh. I wish they could just own up to the mess (like Microsoft did) and fully move to Web Extensions, including native app messaging.
The webRequest API is not supported in Safari, so extensions like uBlock Origin cannot be ported in their current form. It's unfortunate that Apple is not embracing the webRequest API, since it's so much more than a tool for content blocking. Requests are a core feature of any browser, and not allowing extensions to control and edit requests hinders innovation among browser extensions.
The notifications API is also missing in Safari, so extensions must use the native messaging API to show notifications from the native app extension.
I am not a browser developer, but the impression I get is that the issue with the webRequest API is that the amount of overhead that can be added to a function that's invoked extremely frequently (loading resources) is unbounded and difficult to optimize. It entrusts a pillar of browser performance to extension developers, which is a dicey proposition.
This leads me to think that if Apple were to add support for something like the webRequest API, it'd likely be via the native half of the extension API and potentially even Swift-only so there can be stronger guarantees on things like execution time. This may also allow users of the API to better take advantage of multithreading for more complex operations.
I may be misunderstanding something about how the webRequest API is traditionally implemented that deals with these concerns however, in which case feel free to correct me.
Chrome will also drop that soon and only allow a tiny fraction of extensions to continue using it.
This is in the name of security. Whether you believe that is up to you, but personally I don’t even install extensions that require access to all of my tabs, let alone something that can read pure requests (with the exception of uBlock)
I'm glad to see that certain extensions are what's stopping people from switching to Safari.
For me the issue is that Safari garbles the sound when using Google Hangouts and Whereby. Having to open another browser just to use those services, is pretty annoying.
I wanted to point out that it is Apple sharing how to modify your extensions to work with Safari, as opposed to Apple sharing how they modified Safari to work with WebExtensions.
Speaking of web extensions, one thing I’ve been missing from iOS is a convenient way to turn JavaScript on or off on a page-by-page basis.
uBlock Origin makes this trivial—it’s literally a click on the extension logo and then one more tap.
iOS Safari already has “Turn off Content Blockers” and “Website Settings” per website, but I haven’t been able to find a menu or app that makes it convenient to toggle JavaScript on a page.
I use a 4 year old iPhone with a dying battery and aging processor. The web is slow and made much faster without JavaScript. It’d be great to have a toggle for this.
Requiring app-based distribution feels like a perversion of the entire premise of WebExtensions. I understand why Apple wants to reuse its existing development, review, and distribution platforms, and it makes sense for some apps, but it's simply not reasonable to expect cross-platform browser extension developers to go through the hassle of building and distributing Mac apps just to support Safari users.
If you have an existing Mac app, it might be worth it, but personally, there's no chance that I would bother porting my own standalone WebExtensions to Safari under the current system, whereas I went to the trouble of doing so ($99/year fee and all) for the legacy framework, even though I don't really use Safari. Maybe Apple is OK losing large numbers of smaller extensions, but for me, it just means I'd never seriously consider Safari as an alternative to Firefox or Chrome.
I hate pooping where I eat since I’m trying to finally move to Safari, but all the writers saying how easy it is to port an extension now still have no idea.
Here’s what I need to port Chrome extension to Firefox:
1. Upload a zip file
2. Fill in very few additional details
3. Wait for review
Here’s what it takes for Safari:
1. Own a Mac
2. Download 12GB of XCode
3. Run the conversion tool (this is the point that everyone talks about)
4. Well done, now you have an XCode project you’ll have to maintain
5. Pay $99/yearly
6. Fill pages of senseless details and read scary-sounding notices about encryption because your extension is enabled on HTTPS
7. Wait for review
8. Get denied because of an “entitlement” that the conversion tool added for you
9. Wait for review
10. Fix a number of slight incompatibilities you’ll find over time, from basic features that other browsers have had for a long time to the APIs actually not being standard.
I was really excited to try this after the WWDC announcement. Apple was not joking about how easy the conversion is [1]. It took me 15 minutes and 1 command to port my extension [2], and I didn't even need to install Big Sur!
But when the Safari 14 GM release came around, I couldn't justify spending $100 per year just to get my extension on Safari. My goal is to test my product ideas. Chrome gives me plenty of installs to do that, and Safari's user base is too small on the desktop. Adding Safari also means that I have to manage another release system, deal with all of Apple's app store approval quirks, and support customers on a new platform. The added $100 / year just adds to the trouble.
I still think Safari supporting WebExtensions is a big win for the web platform. When I do scale and when Apple sorts out the new platform quirks, I think I will pay the $100 per year and all the added time and technical costs.
I similarly have an iPhone app I built and have been enjoyably using on my iPhone for years and slowly iterating on. I'd happy give it away for free and pay the associated increase in web service costs just so others can enjoy it. But the thought of paying $100/year (and having to deal with App Store review) is a bit much for a hobby app...
I'm surprised Apple put this barrier up since it certainly would have scared me away from iOS development as a poorer/newer developer. I guess Apple's happy with amateurs building but doesn't want to deal with their apps in the store. Maybe a compromise would be letting people self-distribute free apps without paying the $100?
Google's webstore for extensions charges a one-time fee of $5 to mitigate the abuse problem. I think it's a reasonable compromise. Apple's $100 per year is also keeping my hobby extensions off Safari as well.
I was more than happy to pay $5, but I don't think it helps with abuse at Chrome's scale. The abuse got so bad that Google is forcing Manifest v3 [1] on developers to seriously limit what extensions can do. Beyond the abuse, most of the extensions in all the stores, Chrome, Firefox, Edge and especially Opera, are not designed and maintained well.
Is the abuse because $5 is too little or because the initial permissions and policies too lax?
Not sure what you mean about poor design or maintenance. The lower barrier to entry means there are many more options and often unmaintained extensions get forked. (If their license is permissive, which is more often the case when the creator doesn't have to pay $100 per year.)
Nothing stops you putting the code on GH and let people self deploy it.
However I’d also wondered if there’s a scenario where several independent devs might band together and use a single organisational dev account to ship their own apps. Obviously trust (between devs who are otherwise strangers to each other) is an issue here but I’m sure you’re not the only one in that scenario.
I'm into the shared account / shared cost idea for small side projects. But the reality is that managing an app store account for a popular app can be its own full time job. I spent weeks tinkering with account settings, exchanging dozens of app store support emails, and managing the release process. A lot of unexpected things. A lot went wrong. And it's not just Apple. The Chrome Web Store has plenty of quirks too. I trust my fellow devs but I don't trust myself to not screw up a shared account.
Agree with the $100/year just to be able to do what other browsers allow for free (AFAIK). Used to be that Apple offered free extension hosting, even with a free certificate.
Forcing developers to pay is the most developer- and user-hostile thing they could do, and is the main reason I don’t use Safari anymore (there just isn’t any worthwhile extensions for it).
IMHO, it is the reason to use Safari. The $100 and the registration process is a high barrier that helps keep out junk extensions. Even better, in some cases I can pay the creators of the extensions I rely on which makes the ecosystem more sustainable.
I’m sure as a percentage of extensions you’re probably right, but who installs extensions by browsing the entire catalog of extensions?
What I’d bet most people (including myself) do is search for extensions (assuming you don’t already know the exact one you want). My experience has almost always been that the extension I want isn’t available for safari (just chrome and Firefox), or is a shitty/old version of the chrome one.
So even if the $100 keeps some more junk out than on chrome, I still don’t get to use the extensions I want and the ones that are available aren’t great (albeit better than junk).
FWIW your homepage looks super distorted on my iPhone (11 Pro). I realize this is a web browser extension for desktop, but if folks get linked to it on social media or something, there’s a good chance they’ll be on mobile.
I maintain a small extension focused around Competitive Programming niche. I often get requests from users asking if there's a safari version available. As much as I would love to add support, I'm not paying 99$/year as I don't make any money from the product.
I'm going through converting a Chrome extension to Safari 14, and the process isn't nearly as seamless as shown, although it's nice to have the converter tool.
Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'. So our extension had been using the 'chrome' namespace which worked under Firefox, but now needed to be converted. 'chrome' uses callback functions, while 'browser' uses Promises. So you have to port your Chrome extension to use 'browser' and use the following polyfill: https://github.com/mozilla/webextension-polyfill
Ah, well that may have well been a recent update. I'll have to try it again under chrome.* It didn't used to work at all unless I replaced chrome.* with browser.
IIRC this is possible but violates their EULAs for MacOS and likely the DMCA. So if you plan on using it commerically then you may be risking the entire business.
This motivated me to finally port Wappalyzer to Safari. It was fairly straight-forward but Safari doesn't implement every API that Chrome, Firefox and even Edge support, so I had to do a bunch of work to get a single version of the extension to work consistently in all four browsers. I'm glad it's finally here though.
87 comments
[ 4.3 ms ] story [ 153 ms ] threadVimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari.
Given all the hype around Safari’s performance on new M1 Macs (and the fact that only Safari supports Apple Pay), I’d love to have parity on these two extensions extensions. It seeems like Web Extensions will not provide enough to fully support uBlock Origin, but maybe their Content Blockers will be a close enough approximation.
At the very least, I hope that Safari will gain a larger userbase from these changes, regardless what I choose to use. Having multiple large, evenly distributed userbases will only make web developers think more about Chrome-first or Chrome-only development.
[1] https://github.com/philc/vimium/issues/3610
+1, especially uBO
Does anyone know the latest on uBO coming to Safari (or not)?
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
I could see a privacy case in not letting any and every extension have access to all requests.
People keep making that argument, and I keep having to correct this.
Their webRequest is not blocking but it does support _observing_ all network requests[1], just as is planned with ManifestV3.
The privacy argument can't and shouldn't be used to justify the removal of the blocking capability from the webRequest API.
---
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
What reason does Apple give for not allowing blocking, then?
Safari Mac does have JavaScript extensions too (iOS only supports content blockers), and everything gorhill says does apply to them. And indeed some vendors ship both a content blocker and a Safari JavaScript extension in the same Mac app (though each one has to be enabled separately in Safari). Thus, it could be argued that this is a distinction without a difference. But from a technical perspective they're entirely different technologies.
The macOS 10.15 SDK did add an API for a Safari JS extension to receive information from a content blocker embedded in the same Mac app, allowing for example the extension to show stats for blocked resources: https://developer.apple.com/documentation/safariservices/sfs...
My personal theory is that Safari content blockers were designed primarily for iOS, which has no Safari web extensions, and the Mac side was a bit of an afterthought.
I can also choose to enable an extension that does have JavaScript and know that it could observe what I browse.
I am unfamiliar, so please feel free to correct me. Thanks for uBO!
Documentation about what can be observed or not is all available online, there is no need to make any assumption:
Firefox: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Chromium: https://developer.chrome.com/docs/extensions/reference/webRe...
That should answer all questions regarding what can be observed.
https://github.com/el1t/uBlock-Safari/issues/158
[1] https://github.com/el1t/uBlock-Safari/issues/158
Also, generally speaking, the way Safari implements this means that the extension passes on the block list to the browser and Safari itself implements the blocking. This means,
1. It is more private since the extension does not have access to your webpage. 2. It is faster because Safari can do it natively and it is not done in JavaScript.
The only extension I truly need before I use safari again.
Never. The Safari team already (wrongly) feels that their Safari-specific "content blocker" API is adequate, and moreover, Google Chrome has announced the deprecation of the webRequest blocking API used by uBlock Origin, so it almost certainly won't be ported to Safari, and it's an open question how long uBlock Origin will even last on Chrome in the future.
Ad/tracker blockers based on Apples content blocker framework absolutely do work.
So when I said funny, I meant funny as in, “this meat smells funny”.
Please refrain from writing "this meat smells funny" comments on HN. You could go around commenting on typos too, which happen all the time, but that's not at all helpful.
That one's really simple, but doing the Firefox port first seems to have ironed out most of the compatibility issues. Mostly APIs with newer versions where Chrome is the only one to support the old API.
But just exploring web extensions a bit (this was my first time interacting it), it feels like supported features differ quite a bit between browsers. Chrome has the lead here, and Safari seems 'minimal' in comparison. UI elements can also behave very differently between browsers.
Apple is dead-set on having you use the App Store to distribute even web extensions. The converter works fine, but just this way of doing things does bring along a bunch of frustration for unfamiliar devs. There was a Twitter thread on this recently started by a member of the Safari team, which gives an idea: https://twitter.com/jensimmons/status/1338558758025367553
Thing is Safari is a nice browser to use, but without uBlock Origin it's a non-starter for me, all these 'content blocker' solutions are either bloated or nowhere near as good as uBlock Origin.
In practice, well, just search this site for threads about it. I'm not sure, like you indicate, it's worthwhile for the browser ecosystem.
They make reporting bugs impossible because you can't just reproduce it by updating your OS again. Native app messaging is done through shared data which forces you to poll for updates.
Urggh. I wish they could just own up to the mess (like Microsoft did) and fully move to Web Extensions, including native app messaging.
The notifications API is also missing in Safari, so extensions must use the native messaging API to show notifications from the native app extension.
This leads me to think that if Apple were to add support for something like the webRequest API, it'd likely be via the native half of the extension API and potentially even Swift-only so there can be stronger guarantees on things like execution time. This may also allow users of the API to better take advantage of multithreading for more complex operations.
I may be misunderstanding something about how the webRequest API is traditionally implemented that deals with these concerns however, in which case feel free to correct me.
This is in the name of security. Whether you believe that is up to you, but personally I don’t even install extensions that require access to all of my tabs, let alone something that can read pure requests (with the exception of uBlock)
For me the issue is that Safari garbles the sound when using Google Hangouts and Whereby. Having to open another browser just to use those services, is pretty annoying.
I wanted to point out that it is Apple sharing how to modify your extensions to work with Safari, as opposed to Apple sharing how they modified Safari to work with WebExtensions.
uBlock Origin makes this trivial—it’s literally a click on the extension logo and then one more tap.
iOS Safari already has “Turn off Content Blockers” and “Website Settings” per website, but I haven’t been able to find a menu or app that makes it convenient to toggle JavaScript on a page.
I use a 4 year old iPhone with a dying battery and aging processor. The web is slow and made much faster without JavaScript. It’d be great to have a toggle for this.
If you have an existing Mac app, it might be worth it, but personally, there's no chance that I would bother porting my own standalone WebExtensions to Safari under the current system, whereas I went to the trouble of doing so ($99/year fee and all) for the legacy framework, even though I don't really use Safari. Maybe Apple is OK losing large numbers of smaller extensions, but for me, it just means I'd never seriously consider Safari as an alternative to Firefox or Chrome.
Here’s what I need to port Chrome extension to Firefox:
Here’s what it takes for Safari:But when the Safari 14 GM release came around, I couldn't justify spending $100 per year just to get my extension on Safari. My goal is to test my product ideas. Chrome gives me plenty of installs to do that, and Safari's user base is too small on the desktop. Adding Safari also means that I have to manage another release system, deal with all of Apple's app store approval quirks, and support customers on a new platform. The added $100 / year just adds to the trouble.
I still think Safari supporting WebExtensions is a big win for the web platform. When I do scale and when Apple sorts out the new platform quirks, I think I will pay the $100 per year and all the added time and technical costs.
[1] https://twitter.com/rayshan/status/1292270249362956288
[2] https://finance.shan.io/stock-inspector-discover-new-compani...
I'm surprised Apple put this barrier up since it certainly would have scared me away from iOS development as a poorer/newer developer. I guess Apple's happy with amateurs building but doesn't want to deal with their apps in the store. Maybe a compromise would be letting people self-distribute free apps without paying the $100?
[1] https://developer.chrome.com/docs/extensions/mv3/intro/
Not sure what you mean about poor design or maintenance. The lower barrier to entry means there are many more options and often unmaintained extensions get forked. (If their license is permissive, which is more often the case when the creator doesn't have to pay $100 per year.)
However I’d also wondered if there’s a scenario where several independent devs might band together and use a single organisational dev account to ship their own apps. Obviously trust (between devs who are otherwise strangers to each other) is an issue here but I’m sure you’re not the only one in that scenario.
Forcing developers to pay is the most developer- and user-hostile thing they could do, and is the main reason I don’t use Safari anymore (there just isn’t any worthwhile extensions for it).
What I’d bet most people (including myself) do is search for extensions (assuming you don’t already know the exact one you want). My experience has almost always been that the extension I want isn’t available for safari (just chrome and Firefox), or is a shitty/old version of the chrome one.
So even if the $100 keeps some more junk out than on chrome, I still don’t get to use the extensions I want and the ones that are available aren’t great (albeit better than junk).
Google requires developers to pay them $5, once, before they can upload extensions to the web store.
They’re just covering the fees to prove you’re a person/developer, and basically nothing more.
Thank you!
My extension for those interested: https://github.com/nishanthvijayan/CoderCalendar-Extensions/
Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'. So our extension had been using the 'chrome' namespace which worked under Firefox, but now needed to be converted. 'chrome' uses callback functions, while 'browser' uses Promises. So you have to port your Chrome extension to use 'browser' and use the following polyfill: https://github.com/mozilla/webextension-polyfill
Here's some incompatibilities between Chrome and Firefox to consider: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Also had some html/css glitches to fix in Safari. Some other issues others have mentioned such as notifications and webRequest APIs.
According to the documentation, "Safari web extensions support both the chrome.* and browser.* namespaces." https://developer.apple.com/documentation/safariservices/saf...
https://apps.apple.com/app/wappalyzer/id1520333300
1. https://free.law/recap/