Hello, I am trying to package and distribute a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. My Apple Developer Program membership is active, and I have already completed the following: Created an explicit Bundle ID. Created an iOS app record in App Store Connect named Kuzey SGK. The app is currently in Prepare for Submission status. I can access the app's Xcode Cloud tab. I can also access Users and Access > Xcode Cloud. According to Apple's documentation: “After creating an app record, navigate to the Xcode Cloud tab. Under Safari Web Extension Packager, click Upload.” However, there is no “Safari Web Extension Packager” section at all under the Xcode Cloud tab for my app. The page only displays the standard Xcode Cloud information and “Get started in Xcode.” I am using App Store Connect from Windows in a web browser. My understanding from Apple's Safari Web Extension documentation is that the web-based packager should allow packaging an existing web extension without requiring a Mac or Xcode. I have not configured a standard Xcode Cloud workflow or connected a source repository, because the Safari Web Extension Packager documentation does not list those steps as prerequisites. Apple Developer Program Support reviewed my request and referred me to the Developer Forums because this appears to be a technical issue. My support case number is 102956602442. Could someone please clarify: Is there an additional step required to enable the Safari Web Extension Packager for a newly created developer account or app? Is a standard Xcode Cloud workflow required before the Packager becomes visible? Is the Packager currently available to all Apple Developer Program members? Thank you.

Hello, I am trying to package and distribute a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. My Apple Developer Program membership is active, and I have already completed the following: Created an explicit Bundle ID. Created an iOS app record in App Store Connect named Kuzey SGK. The app is currently in Prepare for Submission status. I can access the app's Xcode Cloud tab. I can also access Users and Access > Xcode Cloud. According to Apple's documentation: “After creating an app record, navigate to the Xcode Cloud tab. Under Safari Web Extension Packager, click Upload.” However, there is no “Safari Web Extension Packager” section at all under the Xcode Cloud tab for my app. The page only displays the standard Xcode Cloud information and “Get started in Xcode.” I am using App Store Connect from Windows in a web browser. My understanding from Apple's Safari Web Extension documentation is that the web-based packager should allow packaging an existing web extension without requiring a Mac or Xcode. I have not configured a standard Xcode Cloud workflow or connected a source repository, because the Safari Web Extension Packager documentation does not list those steps as prerequisites. Apple Developer Program Support reviewed my request and referred me to the Developer Forums because this appears to be a technical issue. My support case number is 102956602442. Could someone please clarify: Is there an additional step required to enable the Safari Web Extension Packager for a newly created developer account or app? Is a standard Xcode Cloud workflow required before the Packager becomes visible? Is the Packager currently available to all Apple Developer Program members? Thank you.

I am trying to use Safari Web Extension Packager to upload a web extension ZIP through App Store Connect, following this documentation: https://developer.apple.com/documentation/safariservices/packaging-and-distributing-safari-web-extensions-with-app-store-connect However, I cannot find the Packager upload section at all. Steps to reproduce: Sign in to App Store Connect as the Account Holder of an active Apple Developer Program membership. Open an existing app, then select Xcode Cloud. Scroll to the bottom of the page. Actual result: The page only shows the standard Xcode Cloud introduction, with “Get started in Xcode” and an “Open Xcode” button. There is no Safari Web Extension Packager section or ZIP upload control. Another app under the same team shows the same introduction page. Additional details: The existing Safari extension was previously distributed as an iOS app using Xcode. I want to use the Packager for the next update while retaining the existing app identity. The source is a WXT project and the Safari ZIP has been generated. I cannot reach the upload or build-validation step. During my September 6 checks, the Developer Program and App Store Connect agreements were accepted, with no pending agreement prompt. Apple Developer Support's account-support team directed me to the Developer Forums because they could not diagnose this technical issue. Could an Apple engineer clarify: Is Packager available to all eligible teams, or still being rolled out? Are there country/region restrictions, including mainland China? What prerequisites control the upload section? Must a team first enable a conventional Xcode Cloud workflow through local Xcode, even if the intended input is only a web extension ZIP? Can Packager update an existing app previously built with Xcode, or does initial setup require a new app record? What is the correct page or navigation path when only the Xcode Cloud introduction is visible? This question concerns access to the web-based packaging UI. A documented activation step or confirmation of availability requirements would be helpful. Screenshot of the missing upload section:

Hi! I've successfully uploaded my web extension using the Web Extension Packager. However, there was a build error. When I review the list of cloud builds and click "view issues" for the failed build, I get the message: "Exporting for App Store Distribution failed. Please download the logs artifact for more information." However, I can't find any link in the app store connect web UI for viewing the logs artifact for Web Extension Packager builds.

I’m packaging a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. The ZIP uploads successfully, the manifest is accepted, and the Packager automatically creates the related Extension identifier. However, every build fails during export with: Exporting for App Store Distribution failed. Please download the logs artifact for more information. It also shows: Exporting for Development Distribution failed. Please download the logs artifact for more information. There is no Logs, Artifacts, or Download button on the build or issue page. To isolate the problem, I tested: Manifest V2 and Manifest V3 A minimal extension containing only HTML and icons No JavaScript, permissions, host permissions, APIs, or external dependencies A completely new App Store Connect app A new explicit Bundle ID A name-matched extension ZIP Multiple version and build numbers Every test produced exactly the same export errors. The App Store Connect agreement is active, and the Account Holder has access to cloud-managed distribution certificates. Because even a clean minimal extension and a newly created app fail identically, this appears to happen during cloud signing, provisioning, or archive export—not while parsing the extension. Questions: How can I download the logs artifact requested by the error when the Packager interface does not provide it? Can Apple confirm whether the web-based Packager currently has an export or automatic-signing issue? Is there any required certificate, provisioning profile, App ID configuration, or account permission that the Packager does not create automatically?

Instead of rejecting the extension with a reasonable, polite error, Safari on Tahoe crashes when the manifest.json file is properly formatted for Firefox instead of Chrome. ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Safari [88741] Path: /Volumes/VOLUME/*/Safari.app/Contents/MacOS/Safari Identifier: com.apple.Safari Version: 26.4 (21624.1.16.11.4) Build Info: Safari-7624001016011004~1 Code Type: X86-64 (Native) Role: Background Parent Process: launchd [1] Coalition: com.apple.Safari [97627] User ID: 503 Date/Time: 2026-07-19 21:54:12.9042 -0700 Launch Time: 2026-07-18 10:38:48.3440 -0700 Hardware Model: MacBookPro16,2 OS Version: macOS 26.4.1 (25E253) Release Type: User Bridge OS Version: 10.4 (23P4242) Crash Reporter Key: E10AFED8-44D7-B68A-A06B-6237E159410E Incident Identifier: 0E512E91-4C4E-4D10-9518-6F0757C5E943 Sleep/Wake UUID: 5396E9EB-E238-4D56-BE08-D966DCE12528 Time Awake Since Boot: 580000 seconds Time Since Wake: 12175 seconds System Integrity Protection: enabled Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: UNKNOWN_0xD at 0x0000000000000000 Exception Codes: 0x000000000000000d, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11 Terminating Process: exc handler [88741] VM Region Info: 0 is not in any region. Bytes before following region: 4311683072 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 100ff1000-100ff2000 [ 4K] r-x/r-x SM=COW /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/MacOS/Safari Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libunwind.dylib 0x7ff821b974b0 _Unwind_RaiseException + 240 1 libc++abi.dylib 0x7ff811ba5db4 __cxa_throw + 61 2 libobjc.A.dylib 0x7ff8117b8131 objc_exception_throw + 317 3 CoreFoundation 0x7ff811c832b7 -[__NSDictionaryM setObject:forKeyedSubscript:] + 1215 4 SafariSharedUI 0x7ffa19bdc6b5 -[WBSSafariExtensionStateObserver _addNamesForExtension:toMap:] + 205 5 SafariSharedUI 0x7ffa19bdc22d -[WBSSafariExtensionStateObserver _handleExtensionWasAdded:] + 208 6 CoreFoundation 0x7ff811cb1434 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 137 7 CoreFoundation 0x7ff811d388da ___CFXRegistrationPost_block_invoke + 88 8 CoreFoundation 0x7ff811d3882d _CFXRegistrationPost + 540 9 CoreFoundation 0x7ff811c8131c _CFXNotificationPost + 769 10 Foundation 0x7ff812ed3cd1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 82 11 SafariSharedUI 0x7ffa19b769b8 -[WBSExtensionsController _loadExtensions:skipEqualityCheck:] + 2505 12 SafariSharedUI 0x7ffa19b74ec7 __59-[WBSExtensionsController loadSuitableDiscoveredExtensions]_block_invoke + 62 13 SafariSharedUI 0x7ffa19b74da0 -[WBSExtensionsController loadSuitableDiscoveredExtensions] + 133 14 SafariSharedUI 0x7ffa19c5cdd2 -[WBSWebExtensionsController loadSuitableDiscoveredExtensions] + 46 15 SafariSharedUI 0x7ffa19b7490f -[WBSExtensionsController _beginMatchingExtensionsWithAttributesCompletedWithMatchingExtensions:] + 537 16 SafariSharedUI 0x7ffa19b7460f -[WBSExtensionsController _extensionDiscoveryHasNewResults:] + 331 17 libdispatch.dylib 0x7ff811a47616 _dispatch_call_block_and_release + 12 18 libdispatch.dylib 0x7ff811a5d8b2 _dispatch_client_callout + 6 19 libdispatch.dylib 0x7ff811a78679 _dispatch_main_queue_drain.cold.6 + 842 20 libdispatch.dylib 0x7ff811a53dc4 _dispatch_main_queue_drain + 107 21 libdispatch.dylib 0x7ff811a53d4b _dispatch_main_queue_callback_4CF + 31 22 CoreFoundation 0x7ff811cf66b3 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 23 CoreFoundation 0x7ff811cbb15c __CFRunLoopRun + 2382 24 CoreFoundation 0x7ff811d828b7 _CFRunLoopRunSpecificWithOptions + 496 25 HIToolbox 0x7ff81e9f1b8b RunCurrentEventLoopInMode + 283 26 HIToolbox 0x7ff81e9f4c4d ReceiveNextEventCommon + 599 27 HIToolbox 0x7ff81eb7d0ba _BlockUntilNextEventMatchingListInMode + 37 28 AppKit 0x7ff816236d34 _DPSBlockUntilNextEventMatchingListInMode + 172 29 AppKit 0x7ff815b2c9d5 _DPSNextEvent + 800 30 AppKit 0x7ff8167dab53 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1265 31 AppKit 0x7ff8167da629 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 67 32 Safari 0x7ff927853839 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 214 33 AppKit 0x7ff815b1d868 -[NSApplication run] + 472 34 AppKit 0x7ff815af34cd NSApplicationMain + 800 35 Safari 0x7ff92783fac1 SafariMain + 529 36 dyld 0x7ff81182abb8 start + 3240 Thread 1:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x7ff811bbcb4e mach_msg2_trap + 10 1 libsystem_kernel.dylib 0x7ff811bcaf49 mach_msg2_internal + 83 2 libsystem_kernel.dylib 0x7ff811bc3b64 mach_msg_overwrite + 586 3 libsystem_kernel.dylib 0x7ff811bbce54 mach_msg + 19 4 CoreFoundation 0x7ff811cbc2bf __CFRunLoopServiceMachPort + 145 5 CoreFoundation 0x7ff811cbad58 __CFRunLoopRun + 1354 6 CoreFoundation 0x7ff811d828b7 _CFRunLoopRunSpecificWithOptions + 496 7 AppKit 0x7ff815c7e6a0 _NSEventThread + 158 8 libsystem_pthread.dylib 0x7ff811c00d49 _pthread_start + 115 9 libsystem_pthread.dylib 0x7ff811bfc82f thread_start + 15 ...

Hello, I am developing a Safari extension that uses service workers and all works well. When the extension is updated, a new content script is injected into the current open tabs however the service worker connection with the new content script does not get established. I confirmed both the old content script and new one is on the page, but the new one just doesn't execute which means it will not connect to the service worker. In Chrome a newly injected content script does work and in FireFox it is handled by FireFox automatically. How can this be done in Safari? Any help would be appreciated.

A customer of my Safari app extension is reporting a strange interaction with a 3rd party content blocker that causes Safari to hang, apparently in code signing. Spindumps of Safari show this: Dispatch Thread Soft Limit Reached: 80 (too many dispatch threads blocked in synchronous operations) Each spindump has over 20 DispatchQueue "Content Blocker Containing App Validation Queue" In one spindump, it seems to be triggered by this: -[WBSExtensionsController _extensionDiscoveryHasNewResults:] + 244 (SafariSharedUI + 149396) In another: __114-[WBSExtensionsController(SafariExtras) safari_validateContainingAppOfExtensionIfNecessary:attemptRetryOnFailure:]_block_invoke.44 + 52 (Safari + 5305260) I can't reproduce the issue, however, so I'm baffled. The actual code signature of the app, which comes from the Mac App Store, appears to be fine, as verified with the codesign command-line utility.

In 2018, Apple staff noted that Safari App Extensions had no direct API to communicate with the containing app, and suggested app groups or opening a custom URL scheme as workarounds. On iOS Safari Web Extensions, app groups work for persistence, but opening the containing app from the native extension/background flow does not appear reliable. iOS launch policy seems to require a direct user gesture, and I have not found a documented way for the extension flow to reliably continue into the containing app. Is there a supported iOS architecture for completing an extension-initiated workflow in the containing app, or is the intended model to persist data and require the user to manually open the app? My current architecture is: JavaScript in the Safari Web Extension extracts article content from the page. The native Extension Handler receives that content via native messaging. The Extension Handler writes an encoded request into the App Group container. The containing app watches the App Group container using DispatchSource.makeFileSystemObjectSource and processes new requests. This works on macOS. It also works on iOS when the containing app is already running. The problem is that on iOS, if the containing app is not already running, there is no app process to observe the filesystem event or process the request. I have tried treating the Extension Handler as the place to do more work, but in practice it seems suited only for short-lived relay/persistence work. It is not a reliable place for my app’s main processing pipeline, which includes rendering article content and uploading it to a third-party service. My app is a Safari-native “read later” style tool that uploads simplified articles to the reMarkable Cloud. The containing app contains most of the functionality: SwiftUI UI, WebKit/WebPage rendering, account/cloud logic, and upload orchestration. The Safari extension captures the article, but the app needs to run to complete the user-visible workflow. From a user’s perspective, tapping the Safari extension toolbar button is the action that initiates the workflow. Is there any supported way for that user-initiated extension action to launch or wake the containing iOS app so it can process pending App Group requests? Or should Safari Web Extensions on iOS be designed only to persist work and then ask the user to manually open the containing app? If manual app launch is the intended model, it would be helpful for the documentation to state this explicitly. The current tripartite model strongly suggests that the JavaScript extension, native handler, and containing app can collaborate as parts of one workflow, but on iOS the containing app appears to be available only out-of-band unless already running.

I'm distributing a Safari Web Extension iOS app via TestFlight (built from a Chrome MV3 extension via xcrun safari-web-extension-converter on Xcode 26.0.1). The extension installs and registers correctly, but its popup never opens when the toolbar item is tapped. The behavior is silent — no error, no flash of UI, no console output. The Safari "ᴀA" menu just closes and the user is back at the article. WHAT WORKS: Extension appears in Settings → Safari → Extensions, can be enabled Permissions can be granted ("Always Allow on Every Website") Extension appears as expected in Safari's "ᴀA" address-bar menu WHAT DOESN'T WORK: Tapping the extension item in the AA menu produces no popup, no error, no visible response of any kind. Same on iPhone and iPad, both on iOS 26. WHAT I'VE VERIFIED VIA IPA INSPECTION: Extension .appex contains: manifest.json, popup.html, popup.js, background.js, content.js, and images/ with all icons _CodeSignature/CodeResources files2 lists 11 entries — every web extension resource is signed manifest declares: "action": { "default_popup": "popup.html", "default_icon": {...} } Extension Info.plist has standard NSExtension dict: NSExtensionPointIdentifier = com.apple.Safari.web-extension NSExtensionPrincipalClass = (My)_Extension.SafariWebExtensionHandler ISOLATION TEST: To rule out my popup code, I replaced popup.html with a 506-byte file containing only a static green box and "Hello World" text — no scripts, no images, no external references. This minimal popup ALSO fails to open with the same silent behavior. So this is not a script error or content issue. MANIFEST DETAILS (relevant excerpts): { "manifest_version": 3, "action": { "default_popup": "popup.html", "default_icon": {...} }, "background": { "scripts": ["background.js"], "persistent": false }, "content_scripts": [{ "matches": ["<all_urls>"], "js": ["content.js"] }], "permissions": ["activeTab", "storage", "scripting"], "host_permissions": ["<all_urls>"] } I previously had "background": { "service_worker": "background.js", "type": "module" } and switched to scripts/non-persistent based on prior forum advice about iOS Safari incompatibility with module-type service workers. No change in behavior either way. ENVIRONMENT: iOS 26 (iPhone and iPad — both affected) Built on macos-15 GitHub Actions runner with Xcode 26.0.1 Distribution via TestFlight Manifest version 3 Extension target produced by xcrun safari-web-extension-converter I cannot easily provide a focused Xcode test project as my entire build pipeline runs on GitHub Actions (no local Mac access at this time). I can share the IPA, build pipeline configuration, and source repository. Has anyone else seen silent popup failures on iOS 26 from converter-built Safari Web Extensions? Is there an Info.plist key, build setting, or NSExtension attribute the converter is missing that's needed for popups to render on iOS 26? Thanks for any insight.

I'm building a macOS safari extension and porting its functionality from a chrome extension. The chrome extension uses native messaging hosts to communicate with another process using IPC and holding a persistent connection. To use the same functionality in Safari, I understand that will need to use the handler to communicate it to the containing app, and the app will have to hold the persistent IPC connection. My question derives from that concept: should the app be running in a long-lived state? And if so, how can I ensure that app be running 100% of the time. Also is there any way I can control it's lifecycle with the Safari browser's lifecycle? I will not be using XPC here, but a different UDS to make the connection. Also in addition to that, what would you recommend the best approach is the communicate between the extension and it's handler? -> should it be again a UDS or userDefaults +darwin notification be enough? Also I wouldn't want the inter-message relayed between components to be dropped, is there a fault tolerant architecture you would recommend?

If the extension uses manifest v3 and a background script in the form of a service worker, then in Safari it is not possible to open the background script debugging window. If I expand the Developer menu in Safari, there is nothing under Web Extension Background Data (or disappear after click), which is an error. In other browsers (Edge, Chrome, Opera, Firefox) this works correctly. If I switch the background script back to non-persistent script mode, everything works fine and from the Developer menu and the Web Extension Background Data submenu I am able to open the background script debugging window for the extension. Am I doing something wrong?

To provide users the ability for a keyboard shortcut to open extensions, you can define this in manifest: "commands": { "_execute_browser_action": { "description": "Open extension popup" } }, This doesn't set a keyboard shortcut yet allows the user to assign one. However, in iOS safari, when two extensions offer this functionality, the browser warns about it. See screenshot:

I have an app which has at least two extensions: A Content Blocker extension with a request handler that returns an appropriate NSExtensionItem as part of beginRequest. A different file URL is returned depending upon if the content blocking is on or off by a user setting A Safari Web Extension that includes a toolbar button and popover that enables users to enable or disable the ad blocking of the content blocker extension All three targets (App, Content Blocker appex and Web Extension appex) use an App Group default to read and set the on or off status of the content blocking. When the user changes the content blocking status, the app group default is updated and SFContentBlockerManager.reloadContentBlocker(...) is called. The Content Blocker extension reads the default and then returns the appropriate file URL. The issue is, I have noticed that whenever SFContentBlockerManager.reloadContentBlocker(...) is called from the app, Safari always applies the correct rules from the returned file URL. However sometimes when SFContentBlockerManager.reloadContentBlocker(...) is called from the Safari Web Extension using native messaging, Safari does NOT apply the correct rules from the returned file URL. Using logging I have confirmed that the Content Blocker extension always returns the appropriate file URL irrespective if called as a result of the app or the web extension. Despite this, Safari does not seem to always apply the returned file URL rules when it is called from the Safari Web Extension appex. In these cases, quitting Safari and relaunching it seems to make it apply the rules correctly (obviously this is applying it due to its launch state, not due to the Web extension appex asking it to do so at that point). All targets have access to the App Group location where the active content blocking file URL belongs and the inactive content blocking file URL is within the Safari content blocker target as a resource. I don't think this is a memory status issue as I cannot see the Content Blocker extension being killed when it returns complex rules --- the fact it always works when called via the app also seems to rule this possibility out. This brings up a number of questions: Is calling SFContentBlockerManager.reloadContentBlocker(...) from a different appex, of the same app target and app group supported? (it seems to work sometimes and did work in previous versions of the app). Is there an issue that the Content Blocker extension sometimes returns a file URL that perhaps the calling Web Extension appex may not have access to (even though Safari should via the Content Blocker extension)? Any other ideas of why this may not be working correctly? Has anyone else experienced this? It seems to happen on both iOS and macOS Safari using the same codebase.

There does not appear to be any way to use or create iCloud passkeys with a Safari Web Extension, either using the navigator.credentials API in an extension origin webpage such as the popover, or using the AuthenticationServices framework in the SafariWebExtensionHandler. I've setup an associated domain for my plugin, and I know it works for the host application. But I get errors trying to do so in the web extension target. createCredentialRegistrationRequests results in the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier <ID> is not associated with domain <RPID> The other problem, assuming the entitlement works correctly for the web extension, is that there is no NSWindow to use as the presentation target from the SafariWebExtensionHandler. Trying to use the navigator.credentials.create JS API (which is the preferred method, frankly, in a web extension) results in the following error: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Chrome has a great solution for this that I believe should be adopted by Safari. If an extension has host permissions for a relying party it wants to claim, or if it has an associated domain entitlement for it, webauthn operations should be allowed.

I would like to script my Mac to close a specific iCloud Tab of my choice that is open on my iPhone. This is for Accessibility reasons. Ideally, I’d prefer to do this without using GUI scripting. AppleScript methods only seem to see tabs in Windows Extensions also do not seem to have visibility of the other types of tabs I've tried many options so far, but all seem to not work and are also far too brittle even if they did. I have a feeling I'm missing something! 1. Toolbar Dropdown In Desktop Safari you can enable a toolbar button “iCloud Tabs” which when clicked shows a list of the tabs currently open on your other devices. If you hover one, an X appears which can be clicked to close the tab. When you next use Safari on the remote device that tab will be closed. If it’s already open and awake then the removal happens around one second later. It’s quick. (But I did try GUI scripting and I can get to the row in the outline in the popup, but I can’t get the cross to appear to click it) 2. Start Page they’re also listed on favorites:// “start page” but there are issues viewing all and no way to search them. There used to be a search field until Safari ~15. 3. Omnibar They’re also shown in omni/address bar, but getting the correct item to appear at all or in a predictable position is fragile. 4. Sidebar Another alternative to the favorites/"start page" layout. Same issues. 5. Modifying Safari Database directly Changes are not mirrored to the cloud. It seems Safari does a cloudd request that I can't do.

Hello Apple Developer Community, I currently have a Safari Web Extension on iOS that blocks certain URLs for users. I would like to provide the same functionality for Chrome on iOS. I understand that Chrome on iOS uses WebKit under the hood, and Safari Web Extensions can run in Safari, but I am unsure whether there is any way to implement URL blocking in Chrome for iOS—either via an extension, API, or other supported mechanism. Specifically, I’m looking for guidance on: Whether any browser extension (Safari, Chrome, or otherwise) can intercept or block web requests in Chrome on iOS. If not, what Apple-supported alternatives exist for implementing URL-blocking functionality for users of Chrome on iOS. Any best practices for maintaining a cross-browser URL-blocking solution for iOS users. I want to make sure my approach is aligned with Apple’s policies and platform capabilities. Any guidance or official references would be greatly appreciated. Thank you!

Hi, after upgrading MacOS (MB Air M1 Version 26.2 (25C56)) & Safari (Version 26.2 (21623.1.14.11.9)) to latest versions, we are experiencing a new bug occurring with our web extension (Click & Read) on local storage writing and getting this error : Invalid call to browser.storage.local.set(). Disk I/O error. This doesn't happen on other browsers (chromium, Firefox). export const setLocalStorage = async (value: object) => { try { await browser.storage.local.set(value); } catch (error) { console.error("[Click & Read] Error setting local storage", error); } };

I’m a developer working on a Safari Web Extension that’s distributed via the App Store and also tested locally through Xcode. I’m running into an issue that’s affecting my ability to debug errors reported to my Sentry error logging instance from production. The Problem When an error is thrown in one of my extension scripts (e.g., background.js, popup.js, or content.js), the error is sent to Sentry but the captured JavaScript error stack trace replaces the file paths with the webkit-masked-url://hidden placeholder like this: ReferenceError: Cannot access uninitialized variable. at ? (webkit-masked-url://hidden/:14677:28) at ? (webkit-masked-url://hidden/:16307:3) This happens consistently across both App Store builds and local Xcode runs. It prevents me from seeing which script the error came from or resolving the actual source code lines using uploaded source maps in Sentry. My Setup Safari Version: 18.5 (Stable on macOS) Distribution: App Store and local Xcode development Extension Type: Safari Web Extension Error Reporting: Sentry (@sentry/browser SDK) Bundler: Webpack with inline-source-map What I’ve Confirmed I can see the actual source files in Safari’s Web Inspector under the Sources tab when the extension is running. My source maps are uploaded to Sentry correctly and are associated with the matching release. Errors from Safari are being captured by Sentry, but the file URLs are masked, so stack traces cannot be resolved against my original source. My Question Is this behavior (masking file URLs in stack traces with webkit-masked-url://hidden/) intentional for Safari Web Extensions? If so, is there any supported method or workaround to allow exception stack traces to reveal the original script path (e.g., popup.js, background.js) so tools like Sentry or even console logs can point to real locations? I fully understand the privacy/security rationale behind the masking, but as the extension developer, this is making it extremely difficult to debug runtime issues in production. I’d really appreciate any insight into: Whether this masking is expected and permanent behavior If there are any entitlements, debug settings, or Info.plist keys that can alter this behavior for development or for trusted/own extensions If Apple recommends a different way to log extension errors that includes script name or source references Thanks in advance for your help! I’m happy to share more technical details or try out suggestions.

I develop a tab manager extension: https://apps.apple.com/ua/app/tab-finder-for-safari/id6741719894 It's written purely in Swift. All Safari interactions are done solely inside a SFSafariExtensionHandler . But now i'm considering adding some features from Google Chrome's Extension API like window switching. Is it possible to add a background.js worker to my existing Safari App Extension to have access to the beginRequest method override inside SFSafariExtensionHandler? Without converting my extension from Safari App Extension to Safari Web Extenion?