[1]: https://bartsolutions.github.io/2020/11/20/safari-extension/
Probably less annoying, but there's still a time and effort cost to publishing on both Chrome and Firefox as well. They don't have the same policies, the APIs have differences, they have their own bugs, and the submission/review process is different for each. It's a real drag, compared to pushing updates to a website.
Also, with the Chrome store right now, once you push an update for review, there's no way to replace it with a newer update until the (up to 3 weeks) review process finishes so say goodbye to pushing quick fixes, automated deploys and fast iterations. It's ridiculous.
But, it's not so annoying that the entire platform is being abandoned. This is a matter of degree, but there's a point where the effects of that annoyance become very obvious.
If publishing on Apple devices was just a tiny bit more annoying, devs would complain and then still publish their extensions. But that doesn't seem to be what's happening, it seems Apple has crossed a line where extension devs have decided to just ignore the entire thing.
Apple requires a thousand clicks, a 11GB app on your computer and the manual review every time.
Maybe it's because I don't have many users, or don't use any minification, or something else?
I'd like to publish for Safari but it's a much higher bar. Similar to the old Edge extensions which required Microsoft Store hoop jumping.
Do you automated this or are there manual steps?
> Updates for me take less than five minutes to upload and appear within an hour or so.
https://developer.chrome.com/docs/webstore/faq/#faq-listing-...
"Review times vary; some reviews complete in a few hours, others take many days, and in some cases a review can take several weeks. ... If your item's status says "pending review" for more than three weeks, you should contact support."
Reviews are meant to take longer if you ask for e.g. permission to all URLs (which a large number of popular extensions need to because of lack of permission granularity). Maybe your extension isn't impacted here? There's no guarantee the next update won't get trapped in the review queue either, which is not going to be fun when a critical fix is pending.
Manual for the time being.
> Maybe your extension isn't impacted here? There's no guarantee the next update won't get trapped in the review queue either,...
Mine does need all URLs, though it is possible the next review could take days or weeks. Yet it's all still so much simpler a process than Safari.
I've shipped an extension like this, and it took me an hour to build (which included testing), and then I hit "archive" and submitted it.
The signing pieces "just work" in modern Xcode if you have a developer account associated.
Apple has no issues putting 200 hoops in front of you to get a simple thing done.
This is just another one of those hoops, and another reason developers don't like doing things with Apple-technologies.
With most browsers it's clear, you open a specific file with the browser, the browser loads it and that's it. To update, you open the updated version of the file.
With these apps it doesn't even seem like the app itself is doing any work - there's no code in there to for example connect to an internal socket or do some IPC to notify the browser and supply it with extension files - instead it seems to be handled out-of-band by "magic".
Since extensions are made available via app extensions, it is:
- installation of an app from the app store
- first run of an app which is not from the app store
This is actually the big reason why they require you to use apps - all system customizations (device drivers, web extensions, photo plugins, fonts, etc) are supported with an application life cycle, and support appstore-style review and updates.
I haven't done enough development of safari app extensions in particular to fully understand how _live_ updates work. I typically just enabled the extension with Safari Tech Preview as the only extension, loaded on a test page, and would restart. There may well be logic now to do a page refresh when an enabled extension is updated, however.
> With these apps it doesn't even seem like the app itself is doing any work - there's no code in there to for example connect to an internal socket or do some IPC to notify the browser and supply it with extension files
The app extension has a global JS file loaded, and the safari.extension object allows one to send IPC to the corresponding native Mac app. This is (for example) how 1Password and other password managers integrate with the native password store.
The native app is a pretty good place to put all the configuration options for your extension, which may eliminate the need to surface browser-bar buttons and the like.
(FWIW: my Safari extension was a prototype that was abandoned because Safari didn't surface enough HTTP request/response access in their old API. I haven't checked yet if their Web Extension API surface includes what I needed.)
Nope, which is why uBlock Origin is still not possible.
I have an extension idea; it's literally a single line of JS. However, to get it into Safari, I need to create a (useless, and empty) Mac app with a specific configuration in Xcode that'll allow it to appear in the "extensions" list in Safari. Then I need to deal with all the signing & App Store distribution stuff if I actually want to distribute it.
The money isn't even an issue (I have a developer license for other reasons - creating actual apps), it's just the annoyance and insane barrier of entry when the majority of extensions don't need anything but JS.
There's also the issue of how Safari discovers extensions and what actually causes your extension to appear in its list. Is it opening the associated "app"? Not always as I've had trouble with that before - the app is compiled, it's open, but the extension is nowhere to be seen in Safari's preferences. It mysteriously self-resolved after some more trial and error. Updating the extension's JS while developing is also unclear. Does it happen upon app recompile? App relaunch? Who knows - I gave up before even reaching this stage - this whole process is bullshit.
The whole idea that browser extensions are "apps" is stupid and annoying. They should be separate, and while apps install on your OS, browser extensions install in your browser. They should have their own file format (openable directly by Safari, with optional code signature checks) and their own Store (a website within Safari). At least that would solve the problem above - you open an extension file in your browser and it installs in your browser - no ambiguity there. To update you open a new file (which overwrites the previous one based on a potentially signed Bundle ID or similar) and it updates.
The worst is that they had all of the above already and then decided to shit all over it about 2 years ago (in addition to removing much-needed APIs that allowed uBlock Origin to work and replaced it with something way less powerful).