Engineering service
Safari Browser Extension Development
We build and convert Safari Web Extensions inside the native app shell Apple requires, from the Xcode project through signing and App Store Connect distribution.
- 15+ years of experience
- 300+ projects delivered
- Clients worldwide
- NDA available
Overview
What this is, and when it is the right call
Safari supports Web Extensions, which follow much of the same API as Chrome and Firefox. The difference is that a Safari extension does not ship alone. It is packaged inside a native app, and it is signed, tested and distributed through Apple's tools.
We convert existing extensions or build new ones for Safari, set up the Xcode project, and work through the API and permission differences. Users enable the extension in Safari settings and grant access to sites there, so the design has to handle the case where access has not been granted yet.
Who this is for
- Teams with a Chrome or Firefox extension who need it available to Safari users on Mac, iPhone and iPad.
- Companies that want an extension to ship together with a native macOS or iOS app.
- Developers who ran Apple's converter and hit APIs that do not work as expected.
- Products that already have an Apple Developer account and want help with signing and distribution.
How it works
From a Chrome or Firefox extension to Safari
Apple's converter gives a starting point, not a finished port. Most of the effort is in the adapt and test steps.
Convert
Run Apple's converter, xcrun safari-web-extension-converter, on the existing extension.
You get: A generated Xcode project
Xcode project
The project holds an app target and an extension target, and the extension files sit inside the app.
You get: App and extension targets
Adapt
Replace or rework unsupported or different APIs, and adjust for Safari's permission model.
You get: Code that runs in Safari
Sign and test
Sign with an Apple Developer Program account and test on macOS, iPadOS and iOS.
You get: Signed builds tested on each platform
Distribute
Ship through the App Store or TestFlight. On macOS, distribution outside the store is also possible with Developer ID signing and notarization.
You get: A released app with the extension
What we offer
What we engineer: Safari Browser Extension Development
Safari Web Extension architecture
Structure extension logic with web technologies inside a Safari Web Extension target, wired to a macOS or iOS app host with clear separation between native shell and web content.
Xcode, signing & entitlements
Configure Xcode projects, capabilities, entitlements, and team signing so your extension builds cleanly and passes App Store review requirements.
App Store Connect & distribution
Prepare listings, versioning, and submission assets for macOS and iOS Safari extensions, aligned with Apple’s guidelines for extension apps.
Popovers, toolbars & options UI
Build toolbar items, popovers, and options experiences that feel native to Safari while keeping your UI maintainable and accessible.
Porting from Chrome or Firefox
Start from Apple's safari-web-extension-converter output, then rework the APIs and permission checks that do not carry over as-is.
Permissions, privacy & review readiness
Minimize host permissions, document usage, and harden messaging between native code and the web extension for better privacy posture and fewer review surprises.
Deliverables
What you get
- 01
Converted Xcode project
A working Xcode project with the app and extension targets, built from your existing extension source.
- 02
Safari API adaptations
Code changes for APIs that Safari does not support or handles differently, with the gaps listed.
- 03
Permission and onboarding flow
Interface that guides users to enable the extension in Safari settings and grant per-site access.
- 04
Container app
The native app that carries the extension, kept simple or extended with features, depending on what you need.
- 05
Signing and distribution setup
Signing configured with your Apple Developer account, and a release path through TestFlight, the App Store or Developer ID on macOS.
- 06
Platform test notes
Results from testing on macOS, iPadOS and iOS, with the differences between them documented.
Compare
Where Safari differs
Check Apple's current documentation for supported APIs, since coverage changes between Safari versions.
| Area | Chrome and Firefox | Safari |
|---|---|---|
| Packaging | A standalone extension package uploaded to a store. | The extension ships inside a native app built in Xcode. |
| Accounts | A store developer account. | An Apple Developer Program account is needed for signing and distribution. |
| Permissions | Access is granted at install or through prompts in the browser. | Users enable the extension in Safari settings and grant access per site, so the extension must work before access is granted. |
| API coverage | Broad coverage of the WebExtensions APIs. | Most common APIs are present, but some are missing or behave differently, and each one needs checking. |
| Platforms | Desktop browsers, with limited mobile support. | Safari extensions run on macOS, iPadOS and iOS, so touch and small screens need to be handled. |
Why it matters
What this gives you
Apple-native delivery
We work in the model Apple expects: native host app plus Safari Web Extension, ready for TestFlight and App Store distribution.
WebKit-first engineering
We respect WebKit capabilities and limits — no “Chrome-only” assumptions that break on Safari.
Clear upgrade path
Documentation and structure so your team can ship updates as Safari and Xcode evolve.
Security-conscious design
Thoughtful use of native messaging, storage, and permissions to keep user data safe.
Our approach
How a Safari extension project runs
Audit the extension
We run the converter on a copy and list every warning and unsupported API before writing code.
You get: A gap list
Set up Xcode
We configure the app and extension targets, bundle identifiers and signing for your Apple Developer account.
You get: A project that builds and installs
Adapt the code
We rework the unsupported parts and build the flow that helps users turn on the extension and grant site access.
You get: A Safari build with a setup flow
Test on each platform
We test on macOS, and on iPadOS and iOS where your extension targets them, on real devices where possible.
You get: Test notes per platform
Release
We prepare the App Store or TestFlight submission, or the Developer ID and notarization route on macOS, and help with review feedback.
You get: A submitted or notarized release
When this is not the right fit
A few cases where this approach may not be the best choice for you.
- You want a Safari extension without a native app. Safari extensions ship inside an app, so that is not possible.
- You do not want to maintain an Apple Developer account. Signing and distribution both depend on having one.
- Your extension relies on APIs Safari does not offer and cannot be rebuilt another way. We would say so early.
Tech stack
Technologies we use
The engines, APIs and tools behind our safari browser extension development work.
Safari Web Extension
WebKitXcodeSwift
JavaScript
TypeScriptHTML & CSSApp Store ConnectmacOSiOSFAQ
Questions engineers ask before starting
Yes. We start from Apple's converter, then rework the APIs and permissions that do not carry over and build the Xcode project around it. Converted extensions usually need adjustment, and we list the gaps first.
Our services
Related services
Explore more services that work alongside this one.
Talk to a Browser Engineer
Ship a Safari Web Extension
Send us your Chrome or Firefox extension or your Safari requirements. We will plan the native shell, signing and App Store path.
