Ok… but the following topics in your list have nothing to do with an API specification, which is what they say their goals is on the Goals section:
>
“A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser.
- UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials.
- Huge huge difference between publishing on chrome vs on firefox
- Safari requires xcode, and therefore macos to publish”
Bottom line is I don’t think there is going to be an api standard around “distribution and publishing areas”
Plus, you probably still need a Mac or a virtualized Mac (for automated tests, for example) because you’ll want to test your extension with Safari to ensure it works correctly.
I don’t get your comment. You just confirmed that, indeed, you need a specific computer to publish Safari extension, which isn’t the case for Firefox and Chrome extensions.
It is a limitation and it’s completely unnecessary for the end user.
If they’re so lazy to have a extensions-specific store they could at least offer an automatic wrapper that they run before publishing. I should not need XCode anywhere in my build to publish web extensions.
But you need Safari to test the extension and Safari only has these extensions on a Mac? This is Apple’s way of avoiding their store getting cluttered with extensions that haven’t been tested to work on Safari. And yes, it also encourages developers to buy Macs. It can do both…
Can you explain what you mean by “literal dumpster fire” because this doesn’t align with my own experience. I’ve used it for purchasing a number of apps recently and I saw nothing eyebrow-raising. So long as the app you want has been uploaded to the store, it works perfectly fine.
That’s true of pretty much any App Store that isn’t strictly invitation only. If you have an app follows Apple’s rules, it gets listed. Whereas Steam, by comparison, exercises editorial control over all of its content. The solution for a better Mac App Store would require Apple to be similarly dictatorial about content.
In that sense I agree with you; personally I think it was a mistake of Apple to have the Mac App Store so closely mirror the iOS App Store. They should have made it a more aggressively curated experience.
And before anyone claims u can just buy time on a cloud Mac... The cost for these and requirement from Apple for a min. period of 24 hours rental (something to do with Mac stadium?) mean you're funneled towards making the $2000 "investment" in a iDevice.
If you can't afford to cross-browser test, and you don't have a Mac, I'm not sure why you're building an extension for a Mac-only browser then? Someone has to test it on a Mac, register for a certificate with Apple, etc. In the end, buying a Mac is the easy part?
And there are services like https://www.browserstack.com/docs/automate/selenium/add-plug... where you can basically rent Mac VMs on cheap monthly plans. Or GitHub Actions, as I pointed to earlier, has a free tier with free minutes on an automated Mac terminal.
On one side Apple says they now offer a compatible API, on the other side you’re telling me dropping a minimum of $800 on a computer (+$100 annually) to release a free extension is the easy part.
BrowserStack would be a good solution to test it, but unfortunately you also need a lot of preparation and XCode-specific knowledge to even get to a testable point, which you don’t get unless you own a Mac.
The browsers that Apple claims to be compatible with don’t require anything more than WinZip.
Apple added requirements for their store to publish extensions, yes. They also added more privacy prompts. If you don’t test on MacOS in Safari, how would you know if your extension works correctly?
Why not ask Apple to release macOS for any computer like Windows on x86? Why not ask for Safari to be published for and API compatible with Windows as on macOS? Why not ask Apple to ship Windows since mac-only APIs would be problematic?
Fact is, Apple requiring a Mac to publish for a Mac-only browser is not a problem. It’s not even true. You can code sign for Mac from Linux[1], as I understand it. Worst case, a third-party service will step in to handle packaging and publishing the way we already do for cross-platform native apps and yet Apple will continue to expect devs to test on their Apple devices.
I can run Firefox or Chrome on my Mac so it’s not like I’m missing out if you choose to not develop an extension for Safari and test it in Safari. I feel like you’re arguing that testing isn’t required if you have the right web standards, which is pretty much always false when there are privacy or other implementation details that vary by browser…
- webextensions specific storage apis to return promises but chrome still needs callbacks
- A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser.
- csp policies differs between chrome and firefox(and cors too I think)
- UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials.
- Difference between how permissions are interpreted on different browsers
- Huge huge difference between publishing on chrome vs on firefox
- Safari requires xcode, and therefore macos to publish