Your Chrome extension doesn’t work in Safari. I fix that.
Apple’s converter gives you an Xcode project that compiles. It doesn’t give you a working extension, and it won’t get you through App Store review. I’ve shipped Safari and iOS extensions used by millions of people at Honey and at Pie. I’ll port yours, make it work, and hand your team a project they can maintain.
Sound familiar?
- You ran xcrun safari-web-extension-converter, and half your extension silently does nothing.
- Your webRequest-based blocking or rewriting has no Safari equivalent, and nobody on the team knows DeclarativeNetRequest.
- The Xcode project builds on one machine, won’t archive on another, and code signing errors mean nothing to your JS team.
- App Store review keeps rejecting the extension with guideline citations that don’t explain what to change.
- It works on macOS Safari but breaks on iPhone, and you can’t tell if it’s your bug or Apple’s.
- Users keep asking "when is this coming to Safari?" and you keep not answering.
I've hit every one of these already — first at Honey, then again at Pie.
Why me
At Honey I designed and built the company’s first iOS browser extension, led a second PayPal-branded one, and ported the deprecated Safari classic extension to Apple’s Safari App Extension API — JavaScript and Swift, through PayPal-scale review processes. At Pie I owned everything Safari and iOS: the Swift and SwiftUI app shells, Xcode project configuration, Xcode Cloud deployment, and the content-blocking work Safari forces through DeclarativeNetRequest. The converter tool leaves a gap between WebExtension JavaScript and Apple’s toolchain. Not many engineers work on both sides of it. I’ve spent years there.
Start small: know exactly what a port will take
Safari Port Assessment
$2,500- I run your extension through conversion and catalog every API that breaks, with the Safari-equivalent approach for each
- DeclarativeNetRequest migration plan if you do content blocking or request interception
- App Store review risk assessment — what will get flagged and how to preempt it
- Effort estimate and fixed-bid quote for the full port (macOS and iOS separately)
- A written go/no-go recommendation you can take to your team — even if the answer is "don’t port"
If we continue to a full engagement, the entire fee is credited toward the project.
Start with the safari port assessmentHow working with me goes
- Assessment
Fixed price, one week. You get the full technical picture and a quote before committing to anything.
- The port
Fixed bid based on the assessment. I build the Safari macOS and/or iOS extension, handle Xcode and signing, and set up CI (Xcode Cloud or your choice).
- App Store & handoff
I drive App Store submission through approval, document the Safari-specific parts, and hand off to your team — with an optional maintenance retainer.
Questions clients ask
Do we need our own Apple Developer account?
Yes — the extension ships under your account and your brand, which you keep full control of. If you don’t have one, setting it up is part of the engagement (it takes Apple a few days, so we start early).
Our extension uses webRequest to block or modify traffic. Is a Safari port even possible?
Usually yes, but not as a straight translation — Safari requires DeclarativeNetRequest for content blocking, which is a rules-based model rather than code that inspects requests. I’ve shipped this migration at production scale at Pie. The assessment tells you exactly which behaviors survive, which need redesign, and which are dead ends before you spend real money.
How long does a full port take?
Most extensions land between four and ten weeks, depending on how much of the API surface needs redesign and whether iOS is included. The assessment gives you a number for your codebase specifically.
Can your team maintain it after handoff?
That’s the goal. Your JavaScript stays the source of truth wherever possible, the Swift layer stays thin and documented, and I set up CI so releases don’t depend on one person with a Mac. Teams without Apple experience often keep a light retainer for App Store and Xcode upgrades.
Who owns the code? Will you sign an NDA?
Everything is work-for-hire, in your repos from day one. You own all of it. NDAs are fine — I’ll sign yours or provide a mutual template.
Your users are already on Safari and iPhone.
Send me your extension's Chrome Web Store link and a sentence about what it does. I'll tell you within a day whether a port is worth exploring.