Hacker News new | comments | show | ask | jobs | submitlogin
Things I wish I knew before making a paid extension (2019) (www.amie-chen.com)
127 points by luu 13 days ago | hide | past | web | 20 comments | favorite





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'm curious how they could know that the source code is the same


Firefox asks you to provide the source and the instructions to get the same build you are submitting to the store.

They ask for the minification command that was used as well I believe.

> 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.

I definitely wish I would have known that.


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.

[0] https://blog.chromium.org/2018/10/trustworthy-chrome-extensi...

[1] https://stackoverflow.com/questions/37649620/does-chrome-mar...

[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...


I've had some extensions that were approved, had no changes, then suddenly disapproved because someone on the chrome team decided to re-review it and didn't understand webpack / minification.

I've been so busy I haven't bothered to go try and "fix" the extensions. These are OSS extensions, nothing paid, so I all the code is available for the reviewer to read by the way.


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.

> 3. Forked Code. There should be no reason to do it

The actual problem is that some 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.

> Keep the same manifest

Actually, it depends on which options you use, for example, i18n placeholders aren't supported in Firefox while they are in Chrome, in Edge, the manifest is drastically different.


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.


Browser vs chrome point is moot. Both namespaces exists in Firefox and there’s a polyfill to bring the browser namespace into chrome if you want to use promises over function callbacks. https://github.com/mozilla/webextension-polyfill

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.

Is there other examples beyond notifications?

I guess there are, sadly I don't have an example at hand, I haven't been working much on extensions lately, sadly, the official docs doesn't state these kind of incompatible APIs.

For those curious, Gumroad does offer support for generating license keys which they state "are primarily used for creators selling software."[0] 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.

[0]: https://help.gumroad.com/article/76-license-keys


> 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?

Also, I haven't used Chrome Web Store payments but I would steer well clear of integrating it. They've been disabling payment functional for various reasons the last few months as if it's not business critical to people: see https://www.theregister.co.uk/2020/01/27/google_disables_web... and more recently https://groups.google.com/a/chromium.org/forum/#!topic/chrom.... I wouldn't be surprised if they cancelled Chrome store payments soon.


Would you mind giving a few more details about how your setup with Paddle and the extension works?

- 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.

More integration info here: https://paddle.com/docs/reference-using-webhooks/

Hope that helps!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: