What Apple Gives You for $100 as a Safari Extension Developer(medium.com)
medium.com
What Apple Gives You for $100 as a Safari Extension Developer
https://medium.com/@honestbleeps/what-apple-gives-you-for-100-as-a-safari-extension-developer-and-why-reddit-enhancement-suite-6e2d829c2e52
75 comments
Hey HonestBleeps,
I will gladly pay if you start charging. I'd pay in the neighborhood of $15 for Safari RES. Would love to pay for you to host my RES tags, too.
I will gladly pay if you start charging. I'd pay in the neighborhood of $15 for Safari RES. Would love to pay for you to host my RES tags, too.
Having developed a safari extension for my mac app I have to agree. Compared to the app store process, safari extensions feel like an afterthought to Apple. For instance to update the app, you have to go to the submission page and resubmit your app, filling in all the details over again.
duplicate post: https://news.ycombinator.com/item?id=13306964
Biggest surprise: "Developers are paying $100 a year and Apple doesn’t even host the extension themselves."
They do, actually. Not that hosting a few dozen kilobytes makes it any better.
Has Google dropped the requirement to pay for your Chrome Extention? I remember having to register and pay a fee to publish my Chrome extention [1] last year.
From the article: "The $100 per year fee, which doesn’t have to be paid to publish to any other browser."
[1]: https://chrome.google.com/webstore/detail/nkcss-funda-images...
[edit]
Found it ([2]): "Before you publish your first app, you must pay a one-time $5 developer signup fee. A reminder in the dashboard will appear until you pay the fee."
It's not $100, but I remembered having to pay 'something'.
[2]: https://developer.chrome.com/webstore/publish#pay-the-develo...
From the article: "The $100 per year fee, which doesn’t have to be paid to publish to any other browser."
[1]: https://chrome.google.com/webstore/detail/nkcss-funda-images...
[edit]
Found it ([2]): "Before you publish your first app, you must pay a one-time $5 developer signup fee. A reminder in the dashboard will appear until you pay the fee."
It's not $100, but I remembered having to pay 'something'.
[2]: https://developer.chrome.com/webstore/publish#pay-the-develo...
Pretty sure Google Chrome's dev fee is a $5 one time per account charge from when I was using it last year...
It's basically an anti spam charge
Weird, I have several Chrome extensions published and I've never paid anything.
Older dev accounts did not have this fee.
All this from one of the largest tax evaders in the world.
Is this $100 per extension or $100 per developer? If the latter, make a non profit organisation as 3rd party who pays the fee and allow others to join it for free.
Is this $100 per extension or $100 per developer? If the latter, make a non profit organisation as 3rd party who pays the fee and allow others to join it for free.
The cost doesn't appear to be the actual problem. It's more a case of "adding insult to injury".
The problem is basically one of jumping through hoops - but the hoops are poorly defined, poorly maintained, constantly moving and often nonsensical.
Having to pay for the privilege is just the icing on the cake.
The problem is basically one of jumping through hoops - but the hoops are poorly defined, poorly maintained, constantly moving and often nonsensical.
Having to pay for the privilege is just the icing on the cake.
> All this from one of the largest tax evaders in the world.
Where did you get that from? Or are you mixing up utilizing existing tax laws and legal loopholes with evasion? Or is it a reference to the EU tax ruling of $14 billion that's still in courts?
Wikipedia says, "Tax evasion is the illegal evasion of taxes by individuals, corporations, and trusts."
Where did you get that from? Or are you mixing up utilizing existing tax laws and legal loopholes with evasion? Or is it a reference to the EU tax ruling of $14 billion that's still in courts?
Wikipedia says, "Tax evasion is the illegal evasion of taxes by individuals, corporations, and trusts."
If you use legal methods to reduce your tax burden then that would make you as much of a "tax evader" as Apple.
Ah, the Dallas Buyers Club.
Apple will stomp on that shit hard though.
Per developer
I see... There must be a lot of people developing RES which would cost much.
No, it's per Apple developer account which will be publishing the extension. So RES only needs one.
If the person who publishes RES also publishes others, that person still only needs one.
If the person who publishes RES also publishes others, that person still only needs one.
Just drop safari support. Vote with your feet, so to speak.
> they will not auto update when you release new versions
Wouldn't it be possible to do the auto-updating logic yourself? Is there something preventing this? I assume extensions can store stuff with localStorage, so what's to stop you downloading the code and eval'ing it?
Wouldn't it be possible to do the auto-updating logic yourself? Is there something preventing this? I assume extensions can store stuff with localStorage, so what's to stop you downloading the code and eval'ing it?
Out-of-band updates sound like a hole Apple would want to plug in the near future. The review process is entirely pointless when the the developer can bypass it via subsequent updates.
So... This last year in Safari Extension world:
* $100 buy in. Yearly. (Firefox, Edge, Chrome, Opera... No license fees.)
* Long, bug-prone, and somewhat idiotic review process.
* No way to charge for an extension, to recoup that $100. So its ads or nothing.
* Installation page only. No reviews. No real information.
Caveat: You can develop for free, without getting listed, but then you can't automatically update the extension.
What's coming in Safari Extension world:
* The $100 fee is staying.
* Xcode requirement. You'll need a Mac to publish.
* Swift/Objective-C requirement. No more HTML/JS/CSS only.
* Mac store listing, which means you can charge for extensions. But the Mac Store isn't known for a nice review process.
* Hugely lacking documentation. Hopefully this'll change... But Apple doesn't have a good track record here.
Result:
Reddit Enhancement Suite has to decide between not publishing for one of the major browsers, or paying out for a longer, harder to maintain process, to achieve the same thing as they already do for Firefox, Chrome, Edge and Opera.
Personal anecdote:
Apple seems to hate their own developers. This story, others, and my own experiences tell me that Apple makes everything more difficult than need be to put together a program, small or large, that actually runs on their platform.
Swift was a step in the right direction, a nice language, a decent Open Source effort, and cross platform to boot.
But Safari... Safari lacks in so many areas that it's progress on JS doesn't matter much. Isolating those who build for it is unhelpful.
It almost seems like Apple want Safari to die.
* $100 buy in. Yearly. (Firefox, Edge, Chrome, Opera... No license fees.)
* Long, bug-prone, and somewhat idiotic review process.
* No way to charge for an extension, to recoup that $100. So its ads or nothing.
* Installation page only. No reviews. No real information.
Caveat: You can develop for free, without getting listed, but then you can't automatically update the extension.
What's coming in Safari Extension world:
* The $100 fee is staying.
* Xcode requirement. You'll need a Mac to publish.
* Swift/Objective-C requirement. No more HTML/JS/CSS only.
* Mac store listing, which means you can charge for extensions. But the Mac Store isn't known for a nice review process.
* Hugely lacking documentation. Hopefully this'll change... But Apple doesn't have a good track record here.
Result:
Reddit Enhancement Suite has to decide between not publishing for one of the major browsers, or paying out for a longer, harder to maintain process, to achieve the same thing as they already do for Firefox, Chrome, Edge and Opera.
Personal anecdote:
Apple seems to hate their own developers. This story, others, and my own experiences tell me that Apple makes everything more difficult than need be to put together a program, small or large, that actually runs on their platform.
Swift was a step in the right direction, a nice language, a decent Open Source effort, and cross platform to boot.
But Safari... Safari lacks in so many areas that it's progress on JS doesn't matter much. Isolating those who build for it is unhelpful.
It almost seems like Apple want Safari to die.
> Reddit Enhancement Suite has to decide between not publishing for one of the major browsers, or paying out for a longer, harder to maintain process, to achieve the same thing as they already do for Firefox, Chrome, Edge and Opera.
Just stop supporting Safari. It's more trouble than it's worth and, generally, the type of person that runs RES isn't running something has uncustomizable as Safari.
Just stop supporting Safari. It's more trouble than it's worth and, generally, the type of person that runs RES isn't running something has uncustomizable as Safari.
I was, up until recently, running Safari as my main browser just to avoid the cost in battery life; I'm also an avid RES user. I finally bit the battery life bullet and moved to Firefox for my personal browsing, but it was a hard choice to make. The battery savings (until recently) were non-trivial; giving those up was a hard decision.
It depends on what facets you're speaking of, but some parts of Safari are more customizable than equivalent parts of Chrome. Safari still allows you to customize your toolbar, for instance, which unless my memory is failing me was never an option in Chrome.
Of course Firefox beats both Chrome and Safari out in this aspect, but you trade off things like the battery life you mentioned as well as compatibility with OS X services and general native-ness (Firefox has always felt odd and foreign under OS X due to using XUL for its UI). For someone like myself whose extension needs stop at Stylish and a good adblocker, the trade off isn't worth it.
Of course Firefox beats both Chrome and Safari out in this aspect, but you trade off things like the battery life you mentioned as well as compatibility with OS X services and general native-ness (Firefox has always felt odd and foreign under OS X due to using XUL for its UI). For someone like myself whose extension needs stop at Stylish and a good adblocker, the trade off isn't worth it.
> Firefox, Edge, Chrome, Opera... No license fees.
I think Google charges like a $5 one-time fee to publish a browser extension, as a way of discouraging trash extensions.
I think Google charges like a $5 one-time fee to publish a browser extension, as a way of discouraging trash extensions.
> * Mac store listing, which means you can charge for extensions. But the Mac Store isn't known for a nice review process.
Do you know if this will allow companies to install extensions to their employee computers automatically?
I worked on a commercial Safari extension briefly assuming this functionality had to be there, but gave up when I realised there was no way to push it to an employee's computer without a prompt.
Do you know if this will allow companies to install extensions to their employee computers automatically?
I worked on a commercial Safari extension briefly assuming this functionality had to be there, but gave up when I realised there was no way to push it to an employee's computer without a prompt.
Apple seems to hate their own developers. This story, others, and my own experiences tell me that Apple makes everything more difficult than need be to put together a program, small or large, that actually runs on their platform.
Totally disagree. Publishing Safari extensions might be a rubbish experience, but publishing anything else is fine.
Totally disagree. Publishing Safari extensions might be a rubbish experience, but publishing anything else is fine.
Years and years of anecdotes about the app store submission process would suggest otherwise.
* Swift/Objective-C requirement. No more HTML/JS/CSS only.
It almost sounds like they want really fast extensions they can confidently distribute on iOS...
It almost sounds like they want really fast extensions they can confidently distribute on iOS...
> Caveat: You can develop for free, without getting listed, but then you can't automatically update the extension.
There's a comment on the post disputing this possibility.
There's a comment on the post disputing this possibility.
True, I guess one could concievably build your own update mechanism. But that's even more overhead than what is necessary for all the other browsers, who let you use their stores and update mechanism for much less than $100/developer/year.
Sorry, I should have been specific: a comment on the Medium post that is TFA:
This isn’t correct. Without paying the $100, you can’t get a certificate, and
without a certificate, you can’t sign an extension to build a safariextz.So the situation is even worse than I thought? I mean, it is technically possible to install untrusted extensions, using xcode's self signing, but it isn't exactly straight forward and/or easy.
Xcode is used for Safari App Extensions. Safari Extensions like RES are created in Safari's Extension Builder, which apparently balks without a signing certificate.
>So the situation is even worse than I thought?
Or even better? Higher barrier to entry and more protection against crappy extensions, spam extensions, amateur hour, etc?
Or even better? Higher barrier to entry and more protection against crappy extensions, spam extensions, amateur hour, etc?
$100 buy in. Yearly. (Firefox, Edge, Chrome, Opera... No license fees.)
There's a one-off $5 fee to publish things on the Chrome store.[1]
[1] https://developer.chrome.com/webstore/publish#pay-the-develo...
There's a one-off $5 fee to publish things on the Chrome store.[1]
[1] https://developer.chrome.com/webstore/publish#pay-the-develo...
You're right.
But that one off fee seems incredibly negligible against Safari's fee, which is 20x larger... And yearly. For smaller marketshare.
But that one off fee seems incredibly negligible against Safari's fee, which is 20x larger... And yearly. For smaller marketshare.
Yeah, Chrome's fee seems more like a gate-keeping cost to ensure that the store doesn't get spammed or abused, not an attempt of Google by generate revenue.
Swift is a nice language and I applaud all the hard work that people at Apple have put into it. In almost every other respect developing for Apple platforms feels like a marriage to an abusive and indifferent partner. Coding for Android or the web can be frustrating too, of course, but a lot of the complexity there is inevitable given the decentralized nature of those platforms.
Apple controls the entire software and hardware stack so their crappy dev experience is a consequence of either incompetence or arrogance.
Apple controls the entire software and hardware stack so their crappy dev experience is a consequence of either incompetence or arrogance.
Apple seems to hate their own developers. This story, others, and my own experiences tell me that Apple makes everything more difficult than need be to put together a program, small or large, that actually runs on their platform.
To Apple's credit, they are occasionally way ahead of the curve on developer convenience, and have reaped huge benefits from that.
I tried making smartphone apps in 2003-07 for Symbian, Java ME and the very first Android beta (the one that had a traditional keypad phone emulator). The experience was always disheartening. Horrible IDEs that sometimes cost money, awful device feature fragmentation with no standard ways to handle it, inconvenient APIs designed in the style of '90s embedded platform expectations.
If you managed to get a working app together, distributing it was a mystery. On Symbian, you'd have to pay something on the order of $1000+ for certification from a "special Symbian partner", and even after that there was no central app store. There were websites offering downloads (and paid listings), but users would not stumble on those. It was a terrible offering all around.
The native iPhone SDK in 2008 changed all that. Suddenly there was a smartphone with a desktop-class IDE experience and desktop-derived APIs, with easy access to fascinating new multitouch UI possibilities... And there was an integrated Apple-curated store where you could publish any number of apps for only $99 / year! That was an amazing deal compared to anything that came before in this space. Some occasional hassles with Xcode bugs and certificate weirdness was nothing compared to the nightmare of the Symbian/JavaME style mobile dev experience.
Even before that, Apple had done well by its Mac OS X developers by offering the NeXT-originated Cocoa tools for free. Back in 2001, that wasn't the expectation yet. It was a good API, battle-hardened at NeXT already, and much better than anything Microsoft was pushing in that Windows XP timeframe. Apple's efforts to support OS X development had two major benefits: the Mac's resurgence was helped by increasing availability of good 3rd party software created by dedicated developers, and the iPhone global launch was greatly helped by the fact that those same OS X developers were able to easily move to the iPhone.
To Apple's credit, they are occasionally way ahead of the curve on developer convenience, and have reaped huge benefits from that.
I tried making smartphone apps in 2003-07 for Symbian, Java ME and the very first Android beta (the one that had a traditional keypad phone emulator). The experience was always disheartening. Horrible IDEs that sometimes cost money, awful device feature fragmentation with no standard ways to handle it, inconvenient APIs designed in the style of '90s embedded platform expectations.
If you managed to get a working app together, distributing it was a mystery. On Symbian, you'd have to pay something on the order of $1000+ for certification from a "special Symbian partner", and even after that there was no central app store. There were websites offering downloads (and paid listings), but users would not stumble on those. It was a terrible offering all around.
The native iPhone SDK in 2008 changed all that. Suddenly there was a smartphone with a desktop-class IDE experience and desktop-derived APIs, with easy access to fascinating new multitouch UI possibilities... And there was an integrated Apple-curated store where you could publish any number of apps for only $99 / year! That was an amazing deal compared to anything that came before in this space. Some occasional hassles with Xcode bugs and certificate weirdness was nothing compared to the nightmare of the Symbian/JavaME style mobile dev experience.
Even before that, Apple had done well by its Mac OS X developers by offering the NeXT-originated Cocoa tools for free. Back in 2001, that wasn't the expectation yet. It was a good API, battle-hardened at NeXT already, and much better than anything Microsoft was pushing in that Windows XP timeframe. Apple's efforts to support OS X development had two major benefits: the Mac's resurgence was helped by increasing availability of good 3rd party software created by dedicated developers, and the iPhone global launch was greatly helped by the fact that those same OS X developers were able to easily move to the iPhone.
What they did with the iPhone really makes me sad. They had a unique opportunity to completely open up mobile devices. Instead, they stuck with the walled garden approach, but done better. There was huge outcry about this from developers used to PCs, but Apple didn't budge and developers put up with it since, as you say, it was a lot better than other mobile platforms.
If it hadn't been a walled garden, the market would have sucked horribly inside of a year. It would be a steaming cesspool of malware and trickery and junkware. Consumer trust would have been eroded, and the market would have failed.
I think that Apple did absolutely the right thing for a young marketplace. It was bad enough as it was (remember the $1000 app that did nothing? And the game with a $100 in-game purchase of ammo?)
I think that Apple did absolutely the right thing for a young marketplace. It was bad enough as it was (remember the $1000 app that did nothing? And the game with a $100 in-game purchase of ammo?)
The Mac wasn't a steaming cesspool despite having none of these restrictions. I don't think your examples at the end support your point at all. It seems to me that a $1,000 app that does nothing and $100 in-game ammo purchases are only enabled by something like the App Store. The App Store is pretty anti-consumer, really. For example, the freemium craze was partly driven by the fact that Apple forbids free trials, so developers had to come up with other, worse ways to monetize without requiring people to pay up-front for something they didn't know the worth of.
The iOS marketshare is a orders of magnitude larger than that of macOS so the target vector is larger. Malware and the like would be hugely more profitable on iOS than macOS.
I have no doubts that if Apple had been more open in terms of publishing apps for iOS, the App Store would closely resemble the current Play Store in terms of malware and junkware. Something as personal and often-used as a smartphone is just too tempting of a target.
It is now, but it wasn't when the App Store was introduced.
In any case, malware is best prevented by strong sandboxing. Forcing everyone to go through the store does approximately nothing to fight malware.
In any case, malware is best prevented by strong sandboxing. Forcing everyone to go through the store does approximately nothing to fight malware.
Sandboxing has proven pretty weak in mobile products (definitely in the case of Android; the iOS sandboxing has had a better track record).
Additionally, not all malware needs to escape a sandbox. For instance, there are a bunch of fake apps that simply capture credentials, or that make expensive phone calls or texts.
A well-run store that can run tools against images is a decent first line of defense against malware. A store also provides reliable information about code publishers. These are not a complete defense, but they appear necessary.
Additionally, not all malware needs to escape a sandbox. For instance, there are a bunch of fake apps that simply capture credentials, or that make expensive phone calls or texts.
A well-run store that can run tools against images is a decent first line of defense against malware. A store also provides reliable information about code publishers. These are not a complete defense, but they appear necessary.
A big part of Android's problem is that the permissions model sucks. Until recently, all permissions requested by an app had to be granted up-front as part of installing the app. Apps tended to request anything and everything for no good reason. This trained users to just click through the permissions screen without paying any attention to it.
The iOS model (and now Android model) of prompting for permission when the app first tries to use it is much more solid. If an app requests access to your contacts for no good reason, you'll get a fairly obvious prompt and you can say no. There's still some trouble with getting users to pay attention, but it's a lot better.
I don't see how this makes a store appear necessary. Android doesn't allow sideloading by default, and iOS can now sort of sideload apps using the new free signing stuff Apple put out. The limits on the number and duration of sideloaded apps make them impractical for selling legitimate software, but are no obstacle to malware.
The iOS model (and now Android model) of prompting for permission when the app first tries to use it is much more solid. If an app requests access to your contacts for no good reason, you'll get a fairly obvious prompt and you can say no. There's still some trouble with getting users to pay attention, but it's a lot better.
I don't see how this makes a store appear necessary. Android doesn't allow sideloading by default, and iOS can now sort of sideload apps using the new free signing stuff Apple put out. The limits on the number and duration of sideloaded apps make them impractical for selling legitimate software, but are no obstacle to malware.
Could you elaborate on what makes you sad about their approach?
We might have been able to have mobile devices that look and act like PCs, with full user control, high customizability, etc. Instead, we get locked-down devices. Android is better, but Google seems to be gradually following Apple's lead on this, and it's sad enough to me that Apple's mobile platform isn't open and customizable the way their desktop platform is.
What's even sadder is that the success of the iPhone has encouraged people to try to lock down what were once more open platforms.
I totally agree. Apple's success with the restrictive model seems to be creating a lot of imitations, which is really terrible. We can handle one or a few platforms being this way, but if they all end up like that....
I think past-apple did do a really decent job and set the stage for many other vendors to follow. Everybody has caught up and surpassed it though.
There was a car commerical which sums up my feelings here pretty well. What do you do when you get a room full of trophies? You think about how to get more.
Apple seems to have gotten their trophies here (no doubt) and then stared at them rather than figured out how to get more.
Apple seems to have gotten their trophies here (no doubt) and then stared at them rather than figured out how to get more.
We also had the same issues with (trying) to publish an extension to the Safari gallery: long waiting times, unclear communication, publishing without notification, etc. Besides that, the move towards the requirement of Xcode does not bode well for managing a multi-browser codebase in JS.
Google and to a lesser extent Mozilla are doing way better on this and seem way more experienced in handling the extension ecosystem.
Google and to a lesser extent Mozilla are doing way better on this and seem way more experienced in handling the extension ecosystem.
I'm wondering if Apple decided to charge the $100 to have a "curated" set of extensions. There are thousand of extensions available for Firefox and Chrome, and most of them are junk.
Maybe the thought that Apple had was that charging the $100 would leave them with a smaller set of extensions, with higher quality. I'm not really sure it's working, sure there's fewer extensions, but still a large number of weird ones.
Maybe the thought that Apple had was that charging the $100 would leave them with a smaller set of extensions, with higher quality. I'm not really sure it's working, sure there's fewer extensions, but still a large number of weird ones.
Apple is headed down the path that the old Microsoft was headed. Which they, Microsoft, have ironically backed away from.
I guess what I'm saying is that in some ways Safari is the new IE, but without the same reach. The same kind of vendor lock in and shitty expensive tooling.
I guess what I'm saying is that in some ways Safari is the new IE, but without the same reach. The same kind of vendor lock in and shitty expensive tooling.
Apple is worse in many ways. The situation with Safari on iOS with it being the only rendering engine you can use is akin to Microsoft forbidding other browsers on Windows and only allowing browser skin UIs that sit atop IE6.
I've reported numerous iOS bugs in the webkit project and most of the times I never get answer.
I also frequently report bugs in the Chromium project and I usually get an answer in less than an hour. Never a bug I reported was ignored, legitimate or not.
Recently I wrote an article criticising iOS from a dev perspective and posted a tweet from a core webkit member:
> that's because they have a lot more engineers and evangelists/dev-rel than Apple
...referring to Google and the Chromium project.
Well, hours after I published the article the Twitter user was deleted.
Here's the article in question: https://medium.com/@Pier/why-i-hate-ios-as-a-developer-459c1...
I also frequently report bugs in the Chromium project and I usually get an answer in less than an hour. Never a bug I reported was ignored, legitimate or not.
Recently I wrote an article criticising iOS from a dev perspective and posted a tweet from a core webkit member:
> that's because they have a lot more engineers and evangelists/dev-rel than Apple
...referring to Google and the Chromium project.
Well, hours after I published the article the Twitter user was deleted.
Here's the article in question: https://medium.com/@Pier/why-i-hate-ios-as-a-developer-459c1...
> Apple is headed down the path that the old Microsoft was headed.
Exactly.
> Which they, Microsoft, have ironically backed away from.
Are you really sure that Microsoft backed away from this path? Just google about "Intel SGX (Software Guard Extensions)" and inform yourself how Windows 10 uses/plans to use them. To help you a little bit for researching on this topic, here are two references:
> https://sec.ch9.ms/slides/winHEC/03_WindowsSecurity.pdf
> http://www.alex-ionescu.com/Enclave%20Support%20In%20Windows...
Exactly.
> Which they, Microsoft, have ironically backed away from.
Are you really sure that Microsoft backed away from this path? Just google about "Intel SGX (Software Guard Extensions)" and inform yourself how Windows 10 uses/plans to use them. To help you a little bit for researching on this topic, here are two references:
> https://sec.ch9.ms/slides/winHEC/03_WindowsSecurity.pdf
> http://www.alex-ionescu.com/Enclave%20Support%20In%20Windows...
Another stupid decision by apple. Next they'll probably go after this party browsers, try and pull some stunt to force people to use Safari- some unique macos feature which only safari can access or something
They already have such a feature: Apple Pay can only be used in Safari for web payments.
All this because many users prefer the Extension Gallery or are unable to install extensions manually. The only way to move away from centralized services is for users to stop using them. Unfortunately, the typical Safari user doesn't seem to me as the tech-savvy person willing to learn how to do this.
> All four of the other browsers use effectively the same APIs — Safari is potentially going to change that in some ugly ways.
I understand a developer’s desire to have more reach with less work. But if all browsers have the same APIs, for the same feature set, with the same UI... then what is the point of having different browsers?
If Safari’s API changes lead to extensions that are better integrated with the underlying platform (and I don’t know if that is the case), I say all the power to them.
I understand a developer’s desire to have more reach with less work. But if all browsers have the same APIs, for the same feature set, with the same UI... then what is the point of having different browsers?
If Safari’s API changes lead to extensions that are better integrated with the underlying platform (and I don’t know if that is the case), I say all the power to them.
Core APIs for common functions (intercept these network requests, inject these stylesheets, etc.) are being standardized so you don't have to reinvent the wheel on every damn browser. Browsers can also freely implement additional, non-standard add-on APIs that make sense for their product, while the APIs that aren't distinguishing features can get out of the way and Just Work, everywhere. For example, Opera has a sidebar API, while Chrome does not.
This is good, and allows browsers to compete on privacy, performance, security, support for web standards, ui/ux, etc.
This is good, and allows browsers to compete on privacy, performance, security, support for web standards, ui/ux, etc.
Just the other day I had a few Chrome extensions stop working and sure enough they're disabled because 'This extension contains malware'. Never had that problem with Safari so maybe the $100 isn't such a bad deal after all.
So you are saying that the exact same thing could not happen on the apple store or whatever it is called? Except then your extension would be disabled _AND_ you'd have lost $100
Same experience here: Lots of confusing mails after my submission, needed to re-submit a few times, and never received a notification about my extension going live. I wouldn't have noticed the Safari Extensions menu item without watching WWDC videos, anyway.
On the Mac App Store, besides copy-pasting some Swift/Objective-C, you also need to come up with a UI for your app. It'll probably be a storyboard with a single window that lets users know how to activate your extension, but getting the details right without prior experience in Cocoa development will eat some of your precious dev time.
On the Mac App Store, besides copy-pasting some Swift/Objective-C, you also need to come up with a UI for your app. It'll probably be a storyboard with a single window that lets users know how to activate your extension, but getting the details right without prior experience in Cocoa development will eat some of your precious dev time.
What happens to your apps if you stop paying the annual fee? Will they be removed from the AppStore? Will there be no auto updates on them?
First, you can auto update extensions distributed via your own web server. It says so right in Apple’s docs how to do it:
https://developer.apple.com/library/content/documentation/To...
Second, he writes:
“Maintenance of Safari Extensions is also about to get even worse”
And then: “All four of the other browsers use effectively the same APIs — Safari is potentially going to change that in some ugly ways” and To develop a Safari extension may eventually require Xcode” (emphasis mine).
So it implies that Apple is forcing a switch to the Safari App Extension model, but there doesn’t seem to be any evidence of that. Both the traditional extension model and the new app extension model are supported side by side right now.
While I agree that the review process is ridiculous, I think the author is disingenuous or uneducated on a few of the key points of the article.
https://developer.apple.com/library/content/documentation/To...
Second, he writes:
“Maintenance of Safari Extensions is also about to get even worse”
And then: “All four of the other browsers use effectively the same APIs — Safari is potentially going to change that in some ugly ways” and To develop a Safari extension may eventually require Xcode” (emphasis mine).
So it implies that Apple is forcing a switch to the Safari App Extension model, but there doesn’t seem to be any evidence of that. Both the traditional extension model and the new app extension model are supported side by side right now.
While I agree that the review process is ridiculous, I think the author is disingenuous or uneducated on a few of the key points of the article.
No.
> First, you can auto update extensions distributed via your own web server. It says so right in Apple’s docs how to do it:
http://i.imgur.com/tOGLKxb.png
---
[0]: https://developer.apple.com/library/content/documentation/To...
[1]: https://developer.apple.com/safari/
[2]: https://developer.apple.com/library/content/documentation/To...
> First, you can auto update extensions distributed via your own web server. It says so right in Apple’s docs how to do it:
Only Safari extensions installed from the Safari Extensions Gallery can be
updated automatically. [0]
The future of extensions development takes place in Xcode [1]
As of Safari 10.0 on macOS 10.11.5, Safari extensions are created as app
extensions in Xcode. New extensions are wrapped in a containing macOS app and
are distributed and sold on the App Store. If you have created an extension
with the methods described in this document, consider transitioning to the new
extensions model. [2]
http://i.imgur.com/tOGLKxb.png
---
[0]: https://developer.apple.com/library/content/documentation/To...
[1]: https://developer.apple.com/safari/
[2]: https://developer.apple.com/library/content/documentation/To...
Conversely, they may want existing iOS and Mac devs to be the ones creating Safari extensions rather than the current crop of multi-browser extension developers. This may be their way of trying to recreate the Mac's propensity to be a host to unique, platform-exclusive apps — in other words, they want Safari to have several prominent exclusives instead of just the same stuff you see everywhere else.
Regardless of the motive I think it's safe to say that it isn't working out as they've planned.