
Safari adopts the Chrome/Firefox extension model - soheilpro
https://developer.apple.com/news/?id=kuswih5l
======
jhatax
I think this was only a matter of time. The Chrome extension model has become
the de facto standard, has a large existing extension ecosystem and huge user
base, and other browsers have adopted this model. While sticking to their own
extension model would ensure that they remained in control, this is the right
thing for users, both current and possible switchers. Here’s why:

\- Current Safari users can get the goodness of Chrome extensions,
specifically the ones focused on privacy such as NoScript and uBlock.

\- Switchers from Chrome can feel familiar with Safari if their Chrome
extensions are available to them in the new browser.

\- New macOS users don’t need to select a browser based on whether extensions
are available for it or not.

With extension availability out of the way, the discussion on macOS browsers
is going to come back to UX, speed, and battery usage. UX is a personal
choice. Based on my experience, Safari is the fastest and least battery hungry
browser on macOS. Syncing using iCloud Just Works (TM) for my devices and
account. YMMV.

Net-net, kudos to the team for getting past their “Not Invented Here”
instincts and going with the market flow.

~~~
lapcatsoftware
NoScript and uBlock Origin will not be happening for Safari. The API is
missing and won't be implemented. Safari does not have the same full API as
Chrome or Firefox. Instead, Safari relies on a more limited, Apple-specific
content blocking API.

~~~
zerocrates
Isn't it along the lines of what Chrome's been talking about moving to, where
you basically get to tell the browser what to block but not get at the
requests in the way you can now?

~~~
saagarjha
Pretty much.

------
shpx
> BlockingResponse not supported.

> Blocking requests not supported.

so uBlock Origin is not going to happen.

[https://developer.apple.com/documentation/safariservices/saf...](https://developer.apple.com/documentation/safariservices/safari_web_extensions/assessing_your_safari_web_extension_s_browser_compatibility)

[https://www.reddit.com/r/uBlockOrigin/comments/hdz0bo/will_u...](https://www.reddit.com/r/uBlockOrigin/comments/hdz0bo/will_ublock_origin_back_to_macos_big_sur/fvoc7wk/)

~~~
nuker
Im using "AdGuard For Safari". Its open source, in Mac App Store and works
well enough to keep using Safari. Trick is to disable two out of 8 extensions
that require full page access, leaving on only passive, content blocking ones.

~~~
michelb
Good deal here, no affiliation/affiliate link:
[https://stacksocial.com/sales/adguard-family-plan-
lifetime-s...](https://stacksocial.com/sales/adguard-family-plan-lifetime-
subscription)

Best purchase I've made in a long time.

~~~
nuker
This is different thing to one i posted above, just a note.

------
saagarjha
To summarize a couple of points about Safari's extension functionality for
those that are not familiar with it:

* Safari used to have a "legacy" (and proprietary) web extension API that was essentially a bundle of HTML/CSS/JavaScript and was (usually) distributed through the Safari Extensions Gallery. Distributing extensions this way was free. While never a huge platform due to Mac Safari's relatively low market share, it had a number of fairly decent extensions.

* In OS X El Capitan Apple rolled their extensions signing program into the Apple developer program, which costs $100/year. Extensions that were not signed would be "untrusted" and would be quite annoying to install. Many extension developers openly criticized the move–some refused to continue supporting Safari.

* Almost simultaneously, Apple introduced their content blocking API, where extensions could declare a list of what are essentially regular expressions to block content. This model is quite similar to Chrome's declarativeWebRequest API in that extensions have little flexibility at runtime to vet requests. This API works in Safari on macOS as well as 64-bit iOS devices.

* With Safari 12 Apple deprecated the old web extensions model (no longer loading these) and introduced a new extensions model, App Extensions. These are native bundles that run out-of-process and communicate with JavaScript that you can inject into the page. Again, these bundles must be signed with a (paid) developer ID certificate and be sandboxed. Distribution via the App Store is recommended but not required. Any remaining extensions that share code across browsers (i.e. not using native code) are now locked out of the platform.

* (This announcement, which is a rehash of the one at WWDC from this June) In Safari 14 Apple is supporting a conversion tool that converts your standard WebExtension into something that Safari can load, with the same signing and distribution restrictions as app extensions (costs money, sandbox). Many simple APIs are available, but there is the notable absence of the ability to block requests–so uBlock cannot be ported, for example. NoScript does not seem possible to implement either.

* Safari on iOS has never supported extensions–this hasn't changed. The only extensibility available there is still just content blockers using declarative lists.

~~~
mekster
Is $100 a year that big of a deal?

It also blocks out anonymous developers.

~~~
Mindwipe
It's the perfect storm of being very affordable for scammers as a cost of
business but being attached to a fundamental lack of anonymity and a single
point of control that makes it so dangerous for anyone developing tools to
fight oppressive governments etc.

------
fancy_pantser
This is really exciting for me! Apple reached out earlier this year to ask if
they can use my own extension to test the conversion tool (porting from the
Chrome version) and to demo it during WWDC. Of course, now I have to convert
it myself for Safari 14 and distribute, but it seems straightforward. I hope
RecipeFilter can expand to the major mobile browsers one day as well...

Here's a clip from WWDC where they demo the ported extension:
[https://www.youtube.com/watch?v=Kwh2y6VkzoA](https://www.youtube.com/watch?v=Kwh2y6VkzoA)

Chrome Web Store for it: [https://chrome.google.com/webstore/detail/recipe-
filter/ahlc...](https://chrome.google.com/webstore/detail/recipe-
filter/ahlcdjbkdaegmljnnncfnhiioiadakae)

Source code: [https://github.com/sean-
public/RecipeFilter](https://github.com/sean-public/RecipeFilter)

The original HN comment that caused me to create the extension almost 3 years
ago!
[https://news.ycombinator.com/item?id=15745914](https://news.ycombinator.com/item?id=15745914)

~~~
saagarjha
Cool! Did they have you sign a bunch of NDAs; did they end up working with you
at all?

~~~
fancy_pantser
I did, yes. It was maybe a month in advance of WWDC and I wasn't able to talk
about the coming changes to Safari with anyone.

The couple of biz dev/relations/acquisitions people I met via email and video
calls were very nice, but they didn't give me much at all in return for
releasing permission for the recording and a quick-turnaround change to the
extension to fix a couple things.

------
erikrothoff
It's going to be an interesting war to follow, but not to be in the middle of.
Chrome is already nuking the current state of things by introducing sweeping
changes in Manifest V3. The one that caught the mainstream was webRequests and
breaking content blockers. What's not talked about is how moving the
"background" process from a long lived hidden web page to a short lived, event
based service worker, breaks the actually useful cases of extensions.

For our RSS extension it breaks a bunch of things, like polling for updates in
feeds, removes any sort of complex persistent storage like IndexedDB, the
ability to open a websocket connection for a realtime connection to backend
infrastructure (if the user chooses to use our cloud syncing).

Now Chrome has also made a sweeping change by hiding all extensions you
install by default. Hiding away the main interface element of the extension.
This breaks the "unread" count or the point of the browser action. How many
users will actually understand that they need to "pin" extensions to the
toolbar? How many extensions will you have installed that you forgot to
remove?

It's like the 90s again. All other browsers have moved to Chrome's extension
system, which by no means is a standard. Firefox has explicitly said they will
support content blockers in their current form, but not their stance on
Manifest V3. Safari has disabled a large portion of the API's, and being just
released, what's their story for MV3? Since there is no standard there is no
work to keep the API's in sync. Firefox throws exceptions on parameters that
Chrome supports. It's really demoralizing.

~~~
jerrygoyal
how long will it take chrome team to introduce manifest v3 and drop support
for v2? I hope they give sufficient time to devs for migration.

~~~
erikrothoff
Nobody knows. Their stated goal was release in 2020 with 1 year deprecation
for MV2. Corona might have changed this. Their is no good source of
information and the Chrome extension devrel team is woefully understaffed.

------
chrisbolt
Announced back at WWDC: [https://techcrunch.com/2020/06/25/apple-will-let-you-
port-go...](https://techcrunch.com/2020/06/25/apple-will-let-you-port-google-
chrome-extensions-to-safari/)

------
jonny383
No uBlock, no thanks. Any battery saving improvements given by Safari is
probably negated by the volume of ads getting thrown down my throat.

~~~
kitsunesoba
Just curious, what sites aren’t taken care of by a decent Safari content
blocker extension? I’ve been using content blockers on both macOS and iOS for
years now, and for 99% of sites I visit look barely different from FF/Chrome
w/uBO. If I run into weirdness with sites loading it’s usually due to
something like the site doing something funky like piping content through a
web worker.

~~~
soraminazuki
For me, Safari content blockers work very well except for a single website:
mobile Reddit. Blocking the Reddit app promotion banner disables scrolling,
and Safari content blockers aren't flexible enough to prevent this AFAIK.

------
mey
If they are distributing via the App Store, I assume this means requiring the
publisher to be paying the yearly $99 developer fee?

~~~
dguo
Yes, and that is actually already the case. When Apple finished deprecating
.safariextz extensions in favor of Safari App Extensions, they also killed the
Safari Extensions Gallery in favor of distribution through the App Store. And
as you assumed, the developer does have to pay the annual fee.

See
[https://lapcatsoftware.com/articles/decimation.html](https://lapcatsoftware.com/articles/decimation.html)

~~~
giancarlostoro
This is just ridiculous on the one hand it consolidates their existing tech.
On the other hand it gives them too much control over web extensions as a
result and they dont seem to have the nicest rep running the iOS app store.

------
disparate_dan
I’ve unfairly disregarded Safari on MacOS for years because it didn’t have
parity with chrome/FF in terms of extensions. There’s uBlock of course, but I
spend a lot of time on Reddit, and I can’t bear it without the RES extension.
So now there’s hope.

~~~
ComputerGuru
> I’ve unfairly disregarded Safari on MacOS for years because it didn’t have
> parity with chrome/FF in terms of extensions.

That seems like a very fair reason to disregard a browser, imho.

------
shivenigma
IMHO, Safari is a restrictive browser. Even if they start using chrome models,
their approval process and permission process can be a nightmare and may not
be actually something that small/free extension makers should be doing.

------
aasasd
To my knowledge, Safari already had Chrome extensions working fine (before
some conversion to native programs apparently). The problem wasn't in the
extension support or even in the 100 bucks fee, but in their extension store's
ineptitude in publishing whatever developers were trying to ship. ‘Reddit
Enhancement Suite’ (iirc) stopped supporting Safari for that reason.

Edit: not RES, they cite the move to native code as their point of divergence.
But I remember reading somewhere about Safari store's unenthusiastic
publishing of extensions.

------
koolba
Does this mean I can have them on an iPhone one day too?

A true NoScript alone would be awesome.

~~~
Eric_WVGG
I’m dying to write an iOS Safari extension that will skip over Google AMP
pages to real web.

~~~
NegativeLatency
This is what drove me to switch to duck duck go

~~~
Eric_WVGG
Yeah, I’ve been on DDG for a couple years now. It has not grown on me.

------
skinnymuch
Safari versions can never work on older Mac OSes, correct? I would love to
stay on High Sierra or Mojave and get Safari 14. I’m assuming since it is so
integrated into the OS, it uses Big Sur specific APIs and references.

Too bad. I am happy enough with any macOS from a couple of years ago, but this
Safari change is the first thing I can readily recall caring about for an
upgrade.

A lot of my reasoning is liking Safari being lightweight. Upgrading to Big Sur
would probably far more than cancel out any gains of using Safari more.

Safari still doesn’t appear to have profiles or an easy way to hack it. Good
Safari web extensions that can help toward that might not come out that
quickly if the extensions need some rework and packaging and be published with
the $100/year fee.

~~~
valleyer
Updates of Safari are made available for the two preceding releases of macOS.
For example, Safari 13 shipped with Catalina, but it's also available for
Mojave and High Sierra.

Any OS features not available on those earlier OSes are disabled, of course,
but Web features tend to be unaffected. For example, Safari 13 doesn't support
dark mode on High Sierra.

~~~
skinnymuch
Oh awesome. I never noticed or thought about it before. Seems like this means
web extensions will be available on Mojave. Looks like that’ll be my OS until
I upgrade computers.

Thanks.

------
Animats
But not for IOS?

They want you have to have an Apple developer account, even though the
extension is cross-platform. We need a separate "WebExtensions Store" that's
cross-browser.

------
dvduval
It seems feasible within a reasonable amount of time that the browser could
have everything that an app would have, or at least close. But to me for
reasons of profit, not user experience, companies like apple choose not to
make this possible. I'm sure there's always a reasonable explanation of why
I'm wrong. But I'd love to hear why.

------
whywhywhywhy
Really hoping this means I can use uBlock Origin again, the adblocker
selection for Safari is currently extremely poor.

~~~
saagarjha
Sadly not at the moment :(

------
The_rationalist
I wonder when will webkit devs face their mediocrity and the reality of their
Haiti level human resources poorness and make the not dumb move of switching
to improving chromium just like microsoft do. It's only a matter of time
before major webapps stops working on webkit

------
ho_schi
The most interesting thing here is, that this could bring support for
WebExtensions to WebKitGtk! Therefore to Epiphany, which really need
Extensions. Interestingly enough, I have the feeling leaving Gecko as
foundation was a wise decision years go.

And other webbrowsers like Midoria, Otter, Qute.

------
whereistimbo
my god. even for something simple you need xcode and join the apple developer
program. $$$ for sure.

------
mumblerino
This is pretty useless if developers have to pay $99/year and a Mac to
publish. Most extensions still won’t appear on the Safari store.

~~~
kkarakk
just realized i've had a mac since 2017 and only visited the safari store once

------
mullingitover
Safari _still_ can't use uBlock, so I _still_ can't use Safari.

The content blockers on Safari on iOS are pretty much worthless. Mobile web on
iOS is easily the worst part of the iPhone experience, but at least on MacOS
there are other browsers. I can't fathom why Apple cripples Safari this way on
the desktop. It's at a huge disadvantage, and remains so. Literally the only
advantage for Safari in my experience is that it can actually play full-HD
Netflix streams, where other browsers can't.

~~~
kalleboo
> _I can 't fathom why Apple cripples Safari this way on the desktop_

Privacy. For every person installing uBlock Origin, there are going to be 10
people install SuperBlock WowBlocker which is actually just harvesting all the
URLs they visit and sending them to some data farm.

~~~
mullingitover
Saving me from myself is not the greatest strategy when all it accomplishes is
to make me use a different browser that avoids this type of nanny treatment.

------
rvba
Meanwhile Firefox alienates its current users by killing extensions and
publishing an unfinished product.

------
Pesthuf
But only on macOS. That literally would be the one change that would make me
adopt iOS, you know. I NEED userscripts.

------
dozzman
Waiting for moderators to change the post title to the original but less
descriptive "Easily create web extensions for Safari."

~~~
saagarjha
Hacker News does not like title editorialization, but it does not like
information-light marketing titles either. I suspect it might stick around.

------
zappo2938
To develop a large extension consider using webext-redux[0] and react-
extension-boilerplate [1]

[0] [https://github.com/tshaddix/webext-
redux](https://github.com/tshaddix/webext-redux)

[1][https://github.com/kryptokinght/react-extension-
boilerplate](https://github.com/kryptokinght/react-extension-boilerplate).

~~~
sb8244
Webext redux is one of my favorite libraries. I've built some great stuff with
it (and its predecessor).

One use case is to create a single page app feel on websites that aren't
single page. We use it in Salesforce, specifically.

~~~
zappo2938
Can you share some solutions to pain points you encountered developing an
extension?

~~~
sb8244
There's a lot that goes into it. Can you help guide the question a bit more
and I'll be happy to give it a go?

