Browser Extensions People Actually Install and Keep

Chrome, Edge, Brave, Opera and Arc all run on the same engine, so a single Chrome extension covers them with very little extra work. Firefox uses a close variant of the same format and usually needs modest changes plus its own store listing. Safari is the outlier: it needs a wrapper built with Apple tooling, an Apple developer account and a separate review. We normally build for Chrome and Edge first, add Firefox where the audience justifies it, and treat Safari as its own decision with its own budget.

Manifest V3 is the current extension platform, and Chrome no longer accepts the old one. Three changes matter in practice. The persistent background page became a service worker that shuts down when idle, so an extension can no longer hold things in memory indefinitely. Remotely hosted code is banned, so everything ships inside the reviewed package. And blocking or modifying network requests now goes through a declarative rules system rather than inspecting each request in code. Any extension written before that shift and never migrated is either broken already or heading that way.

Because the browser shows your permission list at install time, in blunt language. An extension that asks to read and change all your data on every website converts far worse than one that asks for a single site, or for nothing until you use it, and it also attracts a slower and more sceptical store review. We scope permissions to what the feature genuinely needs, request the wider ones at the moment the user triggers the feature rather than up front, and treat the install screen as part of the design work.

A content script runs inside the page the user is looking at. It can read and change what is on that page but only has limited access to browser APIs. The service worker runs in the background with the wider privileges, has no access to the page at all, and is shut down whenever it is idle. The two talk by passing messages. Almost every extension of any substance uses both, and knowing which half a piece of logic belongs in is most of the craft.

Usually a few days, occasionally longer, and a first submission is far more likely to be held than a later update. The common causes are permissions broader than the described functionality, a missing privacy policy or one that does not match what the extension does, a listing that promises something the code does not do, code minified beyond readability with no readable source provided, and collecting any user data without disclosing it. We prepare the listing copy, the privacy disclosures and the permission justifications as part of the submission rather than scrambling after a rejection.

Yes, and it is the usual arrangement. The extension authenticates against the same backend as your web application, holds a short-lived token and refreshes it quietly in the background. Signing in through a normal browser tab rather than a login form inside the popup is both safer and less work, and it means someone already signed in to your product is signed in to the extension too.

They can. Chrome ships a new version every few weeks, platform rules and permissions change, and an extension that depends on the structure of a third-party page will break when that page is redesigned. It is why we suggest a small maintenance arrangement rather than treating an extension as finished: a periodic check against the current browser release, and a fix turned around before your install base starts writing one-star reviews.