These are great points. I'd like to add some more to them:
On minified source code, Extensions/Add-Ons are allowed to be deployed with minified source code as long as you provide the unminified versions to Google/Mozilla during review time.
On chrome vs. browser namespaces, a quick 'let chrome = browser;' can help you keep the diffs small between versions. I have yet to find a complete solution to fixing 'forked code' between Google/Mozilla Extensions/Add-Ons.
Also, storage mechanisms between browsers using the same extension code can be completely different. Beware if you're using caches, navigator.storage, and storage.local.
Finally, extensions don't consider themselves secure, depending on the browser. moz-extension:// is not considered secure for cache access, whereas chrome-extension:// is.
There lots of little 'gotchas' like these when developing browser extensions. :)
> as long as you provide the unminified versions to Google/Mozilla during review time.
I have been publishing extensions for a while and never found Google asking me for the source code, is there any hidden option to submit it?
Another detail I have missed is release notes, Firefox is supposed to provide those but I have never been able to add them, Chrome doesn't seem to display them but I have got my submission rejected just after "improving" the description.
> On chrome vs. browser namespaces, a quick 'let chrome = browser;' can help you keep the diffs small between versions. I have yet to find a complete solution to fixing 'forked code' between Google/Mozilla Extensions/Add-Ons.
Firefox actually supports the chrome namespace but you need to be careful as some other APIs are different, for example, in Chrome the notifications has a richer set of options but you need to be careful to not use the ones not supported by Firefox.
Yeah, on the idea of improving a description when you haven’t updated the extension for a while. My extension also got a reject notice after sitting in the submission queue for a week just because I capitalized one letter in the app description.
YC W19 Sapling here. We have a freemium browser extension that acts as a grammar checker. Couple thoughts below:
1. Source code. You are allowed to minify source code. Chrome actually recommends minifying source to improve performance. If you require certain permissions you'll have to submit un-minified source for security review.
2. Cloud/subscription based models are the way to go if piracy is an issue, but it doesn't make sense for all products. Licensing hasn't been an issue for Sapling fortunately because the "brains" of our app are in the cloud. I know hacker news is very privacy conscious but our language models are too large to run on a user's end machine right now. Spier Pro seems like a useful web-scraping helper. People who can pirate a chrome extension probably can probably run xpath scripts or a free xpath testing extension themselves so if I were Amy I wouldn't worry _too_ much about piracy.
3. Forked Code. There should be no reason to do it. Firefox and Edge have done a lot of work to support most of the chrome apis. You can handle minor edge cases build time with a variable toggle. Keep the same manifest, even. Browsers are good about ignoring keywords in the manifest they don't recognize. My recommendation is to pretend they are the same platform until you find bugs/issues and hard code around them. Theres a handful but it's very manageable.
Yea, I've seen some some stories around Chrome review problems, most recently around pushbullet. I think it the review outcome depends a little bit on a mixture of reviewer and the permissions required. The more permissions an extension asks for the longer the review process, and unfortunately some false positive flags do happen now and then.
I think an analogy everybody would understand is to think of a regular web app. If you need to add Internet Explorer support to a website that only supports Chrome, does it make sense to fork the website? Almost never. You just inline hardcoded elements and style stuff that only IE browsers understand masquerading as html comments so that other browsers will ignore it. At most, maybe you run/serve a platform specific piece of js/css/html.
Maintaining hundreds of lines of duplicate code can become a logistical mess. Most extensions will see 95-100% shared code between platforms.
As you said, the namespace is not a problem but some APIs definitely are, for example, in Chrome the notifications has a richer set of options but you need to be careful to not use the ones not supported by Firefox.
For those curious, Gumroad does offer support for generating license keys which they state "are primarily used for creators selling software." From my own experience implementing this and having used other extensions that also relied on this system, I think it works well for bringing monetization to browser addons/extensions.
EDIT: just wanted to add that you don't need to distribute your extension through Gumroad (though you can). You just make it so that anything behind a paywall requires adding the license key which is generated by Gumroad upon purchase and later verified via their licenses API.
> You just make it so that anything behind a paywall requires adding the license key which is generated by Gumroad upon purchase and later verified via their licenses API.
This is what I did. I also had to create a licensing backend to handle cases such as only being able to use your license key on a single account, and for verifying that your license key was still valid (in case you cancelled or got a refund).
> Lots of people are interested in using Gumroad for their extension, and here are my two cents: Gumroad is designed to work best for digital goods such as ebooks, photoshop brushes, and software that can be downloaded and owned. However, I'd not recommend it for selling browser extensions because of: 1. It doesn't make sense to download extensions and manually install them. (The first version of Spider Pro worked that way, and lots of customers find it confusing). 2. There's no easy way to distribute post-installation updates.
> However, I'd not recommend it for selling browser extensions because of: 1. It doesn't make sense to download extensions and manually install them. (The first version of Spider Pro worked that way, and lots of customers find it confusing). 2. There's no easy way to distribute post-installation updates.
What's wrong with putting your extension on e.g. the Chrome and/or Firefox web store where purchasing via your own site gives a login that unlocks paid features within your extension? That gets around 1 and 2, plus you gain organic traffic from being in the stores.
This is what I do for https://www.checkbot.io/, which is on the Chrome Web Store but I use Paddle for payments. This also means purchases aren't tied to the Chrome Web Store.
I went with Paddle over Gumroad as Gumroad seemed less flexible for team based subscriptions. Is anyone doing something like the above with Gumroad? How did it work out?
- When a purchase is complete, Paddle can send a web hook to your own server that stores the subscription data e.g. username, subscription expiration date.
- In the extension, get the user to log-in via your server, which includes checking the subscription is still valid e.g. log-in can be via email which you can link to the email used to buy the subscription.
- When the subscription expiration date changes, Paddle will send another web hook to your server to update the subscription data.