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 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?
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).
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.
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.
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
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.
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.
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
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.
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.
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)
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.
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.
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.
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.
[+] [-] jez|5 years ago|reply
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.
[1] https://github.com/philc/vimium/issues/3610
[+] [-] jumpman500|5 years ago|reply
[1] https://github.com/el1t/uBlock-Safari/issues/158
[+] [-] Merman_Mike|5 years ago|reply
+1, especially uBO
Does anyone know the latest on uBO coming to Safari (or not)?
[+] [-] rayshan|5 years ago|reply
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...
[+] [-] wayne|5 years ago|reply
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?
[+] [-] sebastien_b|5 years ago|reply
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).
[+] [-] gnicholas|5 years ago|reply
[+] [-] chrisdbanks|5 years ago|reply
[+] [-] fbelzile|5 years ago|reply
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.
[+] [-] carl8|5 years ago|reply
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.
[+] [-] _qulr|5 years ago|reply
According to the documentation, "Safari web extensions support both the chrome.* and browser.* namespaces." https://developer.apple.com/documentation/safariservices/saf...
[+] [-] frou_dh|5 years ago|reply
[+] [-] krbzsq|5 years ago|reply
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.
[+] [-] caffeinewriter|5 years ago|reply
[+] [-] dstillman|5 years ago|reply
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.
[+] [-] asiando|5 years ago|reply
Here’s what I need to port Chrome extension to Firefox:
Here’s what it takes for Safari:[+] [-] kosinus|5 years ago|reply
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
[+] [-] nishanth_v|5 years ago|reply
My extension for those interested: https://github.com/nishanthvijayan/CoderCalendar-Extensions/
[+] [-] jez|5 years ago|reply
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.
[+] [-] vimy|5 years ago|reply
[+] [-] dessant|5 years ago|reply
The notifications API is also missing in Safari, so extensions must use the native messaging API to show notifications from the native app extension.
[+] [-] kitsunesoba|5 years ago|reply
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.
[+] [-] asiando|5 years ago|reply
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)
[+] [-] ElbertF|5 years ago|reply
https://apps.apple.com/app/wappalyzer/id1520333300
[+] [-] system16|5 years ago|reply
[+] [-] akasian_1973|5 years ago|reply
[+] [-] ffpip|5 years ago|reply
[+] [-] diebeforei485|5 years ago|reply
1. https://free.law/recap/
[+] [-] shash7|5 years ago|reply
[+] [-] paulryanrogers|5 years ago|reply
[+] [-] adamhearn|5 years ago|reply
The only extension I truly need before I use safari again.
[+] [-] fdalvi|5 years ago|reply
[+] [-] gardaani|5 years ago|reply
[+] [-] dotemacs|5 years ago|reply
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.
[+] [-] forgotmypw17|5 years ago|reply
[+] [-] forgotmypw17|5 years ago|reply
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.