Browser Extension Development Company

Production Chrome extensions built on Manifest V3 with a clean service worker architecture, declarativeNetRequest for any network-level behaviour, and content scripts isolated from page JavaScript via the standard isolated world. Popup UI built in React or Svelte with TypeScript throughout, sharing types between the service worker, the content scripts, and the popup so the IPC bridge between them is type-checked at compile time rather than discovered at runtime.

Permission model designed around the principle of least privilege from day one. Optional permissions requested at point of use via chrome.permissions.request rather than declared upfront in the manifest, which both improves the install experience (users see a shorter permission list on install) and reduces the rejection risk during Web Store review. host_permissions scoped to the specific origins the extension actually operates on, not <all_urls> unless the extension genuinely needs to run everywhere. CSP configured to disallow inline scripts and remote code execution, which both improves security and is now a hard requirement for MV3 store submission.

Chrome Web Store submission handled end to end. We write the store listing copy, produce the screenshots and the promo tile at the required dimensions, draft a privacy policy that accurately reflects what the extension does with user data, and submit through your developer account (or set up the developer account if you don't have one). If the first submission is rejected, we read the rejection email, identify the specific policy section cited, revise the submission, and resubmit, typically within 48 hours.

Edge and Firefox extensions built from the same Manifest V3 codebase as the Chrome build, with the smallest possible per-browser delta. Edge accepts a Chrome MV3 build almost verbatim because it's a Chromium fork: the same manifest, the same content scripts, the same service worker. We submit through the Microsoft Partner Center to the Edge Add-ons store, which reviews extensions on a separate but similar policy to the Chrome Web Store.

Firefox needs slightly more care. The WebExtensions API uses the browser.* namespace where Chrome uses chrome.*, which we resolve cleanly with the webextension-polyfill so the application code stays unified. Firefox's MV3 implementation supports event-page-style background scripts as well as service workers, which we use when the extension needs persistent state that's hard to reconstitute on every service worker wake. Permission declarations differ in small ways (Firefox requires host_permissions to be granted at install time rather than via optional runtime requests in some scenarios) and we handle those per-manifest rather than per-codebase.

Firefox add-on review by Mozilla is generally faster than the Chrome Web Store but stricter on remote code execution and obfuscation. Mozilla reviewers will read minified source if the extension uses a bundler, and they expect unminified source provided alongside the submission for the review to complete. We ship source maps and unminified source as part of the submission package by default.

Safari Web Extensions built as macOS and iOS apps via Xcode, wrapping the same Manifest V3 codebase used for Chrome and Firefox in a native Swift shell. This is the part of cross-browser extension development that surprises teams the most: Safari extensions don't distribute through a web store, they distribute through the Mac App Store and the iOS App Store as native apps that happen to contain an extension. That means an Apple Developer Program membership ($99/year) is required, the app review process applies (which is slower and stricter than browser extension review), and the build pipeline involves Xcode and notarisation as well as the standard webpack or vite bundle.

We handle the Safari conversion as a defined scope: Xcode project setup, the Swift wrapper that loads the extension into Safari, the iOS Safari extension shell for mobile, code signing with your Apple Developer certificate, notarisation, and submission through App Store Connect. The shared TypeScript codebase stays the source of truth, so when you ship a feature update it propagates to Chrome, Edge, Firefox, and Safari from one set of commits rather than four separate codebases drifting apart over time.

Browser extensions that put an AI assistant inside the user's existing workflow rather than asking them to context-switch to a separate tab. Sidebar UI injected via content scripts that opens beside whatever page the user is on, with the page content available as context to the model. Selection-based prompting where the user highlights text on any page and triggers a prompt from a keyboard shortcut or context menu. Output insertion back into the page via DOM manipulation, supporting editable surfaces like Gmail composers, Google Docs, Notion, Linear, and Salesforce text fields, each of which has its own quirks for programmatic text insertion.

LLM API calls routed through a backend service rather than direct from the extension, for three reasons: API keys never ship in the extension bundle (where they'd be trivially extractable), usage limits and cost controls live server-side, and the backend can cache prompts and responses to reduce both latency and cost. The backend exposes a thin auth-protected API to the extension and handles the actual model calls, prompt construction, and response streaming back to the extension via Server-Sent Events or WebSockets.

Productivity extensions follow the same architecture: tab management, snippet expansion, form auto-fill, screenshot annotation, link organisation. The shared pattern is a small, focused extension that does one thing well, lives in the toolbar or sidebar without getting in the way, and respects user data by storing as much as possible locally via chrome.storage rather than syncing to a server the user didn't ask for.

Extensions for sales prospecting, CRM integration, and pipeline workflows that live where the sales team already works. LinkedIn prospecting extensions that enrich profile data, push contacts into Salesforce or HubSpot with one click, and log activity automatically. Gmail and Outlook sidebar extensions that surface CRM context (deal stage, last contact, owner) next to every email thread without the rep switching tabs. Browser-based dialer integrations for sales engagement platforms (Outreach, Salesloft, Apollo) that turn any phone number on a page into a click-to-call.

Architecture for sales extensions has two patterns we use depending on the integration. For CRMs with public OAuth APIs (Salesforce, HubSpot, Pipedrive), we use OAuth 2.0 with PKCE so the extension authenticates the user against the CRM directly without needing a server-side credential exchange, and the access token is stored encrypted in chrome.storage.local with refresh handled in the service worker. For sales platforms without public APIs or with rate-limited APIs that don't scale per-user, we route through a backend that holds the platform credentials and proxies requests on behalf of the user, with the extension authenticating against our backend rather than the third-party platform directly.

Data sync designed around the reality that sales reps work fast: prospect data is loaded eagerly when the user opens LinkedIn or Gmail rather than on demand, so the sidebar surfaces context within 200ms of the page rendering rather than after a second of spinner. Background sync via service worker keeps the local cache fresh without blocking the UI. Bulk operations (push 50 prospects to the CRM at once) queued in the service worker and processed with exponential backoff on rate-limit errors so the operation completes successfully even when the CRM throttles.

End-to-end submission handling for Chrome Web Store, Microsoft Edge Add-ons, Firefox Add-ons (AMO), and the Mac and iOS App Stores for Safari Web Extensions. Each store has its own policy framework, its own review criteria, and its own appeals process, and the differences are material. We've shipped enough extensions across all four to know which submission will pass on the first round and which will need a revision cycle before approval.

The submission package for Chrome includes: a privacy policy that accurately reflects the extension's data practices, a justification for every requested permission (the "Why do you need this permission?" field is required for any sensitive permission and is the most common rejection trigger when filled in vaguely), store listing copy that describes the single purpose of the extension without overpromising, screenshots at the required resolution showing the extension actually in use, and a promo tile if the extension is going on the front page of any category. We write all of it.

If a submission is rejected, the rejection email cites a specific policy section number. We read the cited policy, identify the change required in the manifest or the listing, make the revision, and resubmit. Most rejections we encounter are resolved on the next review cycle, within 48-72 hours of the original rejection. For extensions previously rejected by other developers before we took the project over, we audit the rejection history first to understand the pattern and address the underlying cause rather than just the cited symptom.