I tried to create a content blocker for Safari and did it through Safari App Extension and Safari Web Extension. The XCode project for Safari Extension creates 2 applications: the “Main Application” (which is compiled into ".app") and the “Safari Extension” itself (which is compiled into ".appex"). If you want to create a content blocker, you must add “Content Blocker Extension” from the “File → New → Target” menu. This will be the third application in the group, which is also compiled into "*.appex". And now about differences... The first difference is that Web Extension does not have the right to work on any domains by default, unlike App Extension. For the App Extension, in the "info.plist" in the "SFSafariWebsiteAccess" section, we can remove "Allowed Domains" and in "Level" replace "Some" to "All". This is important because the content blocker should work on any domain, and not be turned on manually for each individual. This will not work in Web Extension and will have to be activated for each domain separately. The second significant difference between Web Extension and App Extension is that for security reasons it is more limited in page management. Web Extensions are supposedly focused on a common API for all browsers (Firefox, Chrome, Opera, Edge, Safari), but if I use Safari and want maximum integration with it, then I don't care about all those browsers. In this case, I don't need Web Extension. App Extension functions as a client-server even within the “Main Application”. This is quite expensive and can be fixed. You can remove the “webView” component from storyBoard and remove this files: “script.js”, “main.html”, “style.css”. After this you will get the pure storyBoard without any tinsel and communication between these layers. That’s will work perfectly because these are native Swift applications. p.s. To show the "Safari Extension" window after clicking on the icon on the toolbar, you need to change key from "Command" to "Popover" in the "info.plist" in the section "SFSafariToolbarItem" in the "Action". write your additions...

Our current iOS application utilizes WKWebView to display a web application. We've observed intermittent deletion of non-expired 1st-party persistent cookies within this web application, leading to session drops. Here are our environment details and specific questions: Environment: App Build: Built with Xcode 16.2. WebView Class: WKWebView. Cookie Type: 1st-Party Persistent Cookie (Explicit expiration set, not a session cookie). Domain Configuration: The content server and the cookie-issuing server are the same (same IP address, same eTLD+1). The Cookie is set via the Set-Cookie HTTP Header on the server side. Questions: Automatic Deletion Policy: Are there any scenarios (e.g., related to iOS system behavior, Safari policies, or Intelligent Tracking Prevention (ITP)) where iOS or Safari might automatically delete non-expired 1st-party persistent cookies used by WKWebView? Deletion Conditions: If the answer to Q1 is Yes, under what specific conditions (e.g., memory pressure, inactivity, storage limits, specific ITP criteria) does this cookie deletion occur, and does the behavior differ significantly across various iOS versions? OS Update Impact: Are there any known specifications or documented cases where an iOS version update itself triggers the mass deletion of existing cookies stored in the WKWebsiteDataStore? Mitigation Strategy: If this automatic deletion is a known behavior, what mitigation strategies are officially recommended to ensure the persistence of essential 1st-party authentication cookies (e.g., manual synchronization with WKHTTPCookieStore or Keychain/UserDefaults)? Official Documentation: If the answer to Q1 is Yes, please provide URLs to any official Apple documentation or technical notes that detail the specifications or behavior of 1st-party persistent cookie deletion within WKWebView.

I recently noticed that putting the app on background for some time, then switching back to it again causes the WKWebView to reload the current page, same with just hitting f5 on it. How do we disable this behavior?

Whenever I make a safari view controller on XCode26 Beta 5, there appears to be a blurry white overlay overtop the controller. This worked fine in XCode26 Beta 2, with no code differences. Anyone have any suggestions?

On an older iPhone I'm testing with (6s, iOS 12.5.7), connected to the same Sandbox Apple ID that I'm using on multiple other devices, the Apple Pay button is not appearing. Neither on my web application, whatever version I set in the PaymentRequest, nor on the official demo site. Further, 2 sandbox cards that were added fine to these other devices are failing to add on this one. Same cards and CVV codes are getting errors. At least "Invalid Card" on one of them. Although the other failed several times, then just worked this time when I tried it again :confused: But on this phone, I have two cards successfully added, so the button should be appearing. On the demo site, whether I select Apple Pay JS API or Payment Request API, the button does not appear.

As of IOS 18.3, there browser.tabs.create methods active property which is supposed to determine whether a tab get open in the active window or not is not working as it should. I have the active property set to false but the tab still gets opened and is active on the window. Tested on older ios versions 18.2 and below and it works as it should. please advise

I have a web extension that I want to send data to, and receive a response containing modified data. My understanding is that the native app is only contactable by a background script. How does a webpage contact the background script? One answer is by adding a content script, which is able to communicate with the background script using browser.native.sendMessage(). Unfortunately this triggers a warning that "this extension can read and alter web pages". I do not want to read and alter web pages, nor do I want users to be concerned about a permission the app doesn't need. I just want to receive data, and then return a response. What API should I be using to achieve this?

I don't think the issue is specific iOS 18. We have a web application that runs with IIS Authentication of Windows and Anonymous. Initially the app opens and the user clicks a button and triggers the "401 Challenge" via ASP.NET. The browser presents the Active Directory login, user enters credentials, clicks Sign In, and the browser hangs (may actually be negotiating something). After a few minutes the user is logged into the application. We have done a number of google searches/AI to try to determine what to change and there is no clear solution. Is there anything else to try? This problem is not seen in Chrome on iOS or on a Windows machine. Strangely it is also not seen using BrowserStack with one of their "real" devices. We have other apps that run with just Windows Authorization and this problem is not observed.

Dear Apple Developer Experts, We're experiencing an intermittent issue with WKWebView in our macOS application where local HTML file access is occasionally denied by the sandbox, despite proper implementation and permissions. We seek your guidance in understanding and resolving this issue. Issue Description: The WKWebView occasionally fails to load local HTML files stored in the app's Contents/Resources directory Error occurs in WebKit Networking Process with sandbox denial Issue is intermittent and can be resolved by app restart or WebKit Networking Process restart Affects all local HTML files in the same directory once the issue occurs Technical Details: Error from Kernel Log: 2025-02-07 14:57:17.179821 +0800 kernel Sandbox: com.apple.WebKit.Networking(58661) deny(1) file-read-data /Applications/DingTalk.app/Contents/Resources/webcontent/contact-2024.html WKWebView Delegate Error (captured in WKNavigationDelegate method): (void)webView:(WKWebView *)webView didFailProvisionalNavigation:(WKNavigation *)navigation withError:(NSError *)error Error Details: Domain: NSPOSIXErrorDomain Code: 1 Description: "Operation not permitted" UserInfo: { networkTaskMetricsPrivacyStance: Unknown, _NSURLErrorFailingURLSessionTaskErrorKey: LocalDataTask <3694CA1E-481B-4E06-975D-E3A56AD56C0F>.<1>, _kCFStreamErrorDomainKey: 1, _kCFStreamErrorCodeKey: 1 } Key Observations: Error is captured in WKNavigationDelegate's didFailProvisionalNavigation method The issue affects all local HTML files in the same directory once it occurs Temporary workarounds we've discovered: Restarting the application completely resolves the issue Without restarting the application, terminating the "WebKit Networking Process" via Activity Monitor causes the process to automatically restart, and this resolves the issue and load works again Additional Information: We've collected complete system diagnostics (system_logs.logarchive) at the time of failure The issue appears similar to discussions in Apple Developer Forums (https://developer.apple.com/forums/thread/110072), though we're uncertain if it's the same root cause We've prepared a minimal demo project demonstrating: Our release version app can be downloaded from: https://dtapp-pub.dingtalk.com/dingtalk-desktop/mac_dmg/Release/M1-Beta/DingTalk_v7.6.45_43521682_universal.dmg?spm=0.0.0.0.UuwovG&file=DingTalk_v7.6.45_43521682_universal.dmg for examining our app's codesign, sandbox, and entitlements configurations if needed Important Investigation Finding: We attempted to simulate the issue by using chmod 000 /path/to/test.html, but this produces a different error: CopyError Domain=NSURLErrorDomain Code=-1102 Description="You do not have permission to access the requested resource." UserInfo={ NSLocalizedDescription=You do not have permission to access the requested resource., NSErrorFailingURLStringKey=file:///Users/sunus/Library/Developer/Xcode/DerivedData/WKWebViewLocalDemo-eumardnlfbmwgnhkaadglsrrhzhs/Build/Products/Debug/WKWebViewLocalDemo.app/Contents/Resources/test.html, NSUnderlyingError=0x600003aedc50 {Error Domain=kCFErrorDomainCFNetwork Code=-1102 "(null)"} } This error is distinctly different from our original issue's "Operation not permitted" error, suggesting that the sandbox denial we're experiencing is not a simple file permission issue. Questions: Is this a known issue with the WebKit sandbox in recent macOS versions? Are there recommended best practices or workarounds to prevent this sandbox denial? Could this be related to the WebKit Networking Process's sandbox configuration? Are there additional diagnostics or logs we should collect to help investigate this issue? We appreciate your assistance in investigating this issue. Please let us know if you need any additional information or clarification. STEPS TO REPRODUCE Open App Then loads the local file in /WKWebViewLocalDemo.app/Contents/Resources/test.html PS, We also submit a DTS & Feedback DTS:Case-ID: 11876957 Feedback-ID: FB16493282 sysdiagnose is in the Feedback-ID: FB16493282 is uploaded

I am a developer working on a Safari extension that handles video playback, and I’ve encountered an issue with Safari version 18.2. When I open the developer tools to inspect the browser, videos fail to play as expected. It worked well on safari version 18.1. Details: Safari Version: 18.2 Operating System: macOS Sequoia v15.2 Additional Information: I’ve tested the extension with various video formats and sites. Clearing the cache and disabling other extensions did not resolve the issue. There are no error messages displayed in the console related to the extension. If I close inspecting, then extension(video playback) works well. I would appreciate any insights or suggestions on how to address this issue, as it impacts the functionality of my extension. Thank you for your help!

在 iOS 平台使用 WKWebView 通过file://协议加载本地 HTML 文件时，存储在localStorage中的数据会在 App 后台切换、进程重启后偶尔丢失；但相同代码在安卓 / 鸿蒙平台无此问题。 现在的文档 仅明确了「默认数据存储（defaultDataStore）可将网站数据持久化到磁盘，非持久化存储（nonPersistent）仅存内存」的基础规则； 未提及「file://协议内容即使使用默认持久化存储，也会被归为临时内存存储」这一关键场景限制； 仅在WKURLSchemeHandler关联说明中隐含「自定义 URL 协议可处理 WebKit 原生不支持的 URL 方案」，但未直接关联file://的存储问题。 我找不到如何处理这个问题的官方文档，仅仅有其他的博客说需要增加http/https加载就没有这个问题。 请提供给我官方文档或者官方回复 关于出现这种file:/加载html出现问题的处理办法

I'd like to know the install state of my iOS safari extension in the associated swift app. Is there any way to get this? As we have seen it is available for macOS here, is there anyway to know iOS Safari extension is enabled or not? Thanks

Even default Safari Web Extension project is not displayed on iOS 18.4 simulator ("No extensions installed"), so it's not possible to test extensions in simulator, only on real device.

I’m currently developing an application using WKWebView. After updating to iOS 26.2 Developer Beta, the following Web API started returning false: isUserVerifyingPlatformAuthenticatorAvailable MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static This issue did not occur on iOS 26.1 — it only happens on the beta version. Has anyone else encountered this problem or is aware of any related changes? OS: iOS 26.2 beta 3 (23C5044b)

I'm converting a Chrome Extension to a Safari Web Extension, I found it's not easy to get favicon of current tab/url natively. The tab object in Safari doesn't have favIconUrl. { 	"id": 121, 	"index": 6, 	"active": true, 	"width": 1324, 	"audible": false, 	"url": "https://github.com/", 	"mutedInfo": { 		"muted": false 	}, 	"windowId": 2, 	"title": "GitHub", 	"incognito": false, 	"pinned": false, 	"height": 935, 	"highlighted": true, 	"status": "complete" } 		 2. I didn't find Safari has similar thing like chrome://favicon 3. I found Safari's favicon caches in ~/Library/Safari/Favicon Cache/favicons but have no idea how to use them in Safari Web Extension.

Ever since the iOS and iPadOS 26.2 beta I can’t open Safari at all. Safari tries to open but crashes and goes back to my home screen. I’ve restored my devices and restarted everything and the same issue occurs. I didn’t have this problem on the beta 26.1 but this whole thing started on 26.2.

I reported this bug one year ago in https://developer.apple.com/forums/thread/746406, but as it is not been fixed yet, I'm going to try by opening this new incident report. iOS is not working for the Unicode Variation Selector-15 (U+FE0E) for all the characters. Can you please apply that variation selector to all your Unicode characters? I) Steps to reproduce the issue: navigate in safari to the page https://eurovot.com/vs.htm II) Expected result: as the 1st column of characters have the Variation Selector-15 (U+FE0E) applied, and the 2nd column have the Variation Selector-16 (U+FE0F) applied, the first column should always display text characters (in orange) and the second column emoji characters. III) Error result: some characters are working fine in the 1st column and displayed as text (in orange colour), but some other aren't displayed as text, they wrongly displayed as emojis instead.

I've been developing a Safari web extension for MacOS and iOS, and I'm running into a very strange issue. I ported over my Chrome extension to Safari, and for several days as I was iterating on the extension (change code, build, run, test in Safari), everything worked perfectly fine. Once I was finished with the extension, I followed the instructions on how to prepare to submit the Safari web extension (and it's containing MacOS and iOS apps) to the App Store for review. For the MacOS app and Safari web extension on Mac, I changed my target from "My Mac" (which I'd been using for testing), to "Any Mac". I then went to the "Product" menu in Xcode and selected "Archive" That's when things started to go wrong. The next time I went to Safari, my web extension could no longer find critical files to run the extension (such as background.js, popup.html, etc.) This was despite there being no code changes before or after me creating a build archive. When I restarted Safari, the extension no longer appeared in the list of extensions within preferences. No matter what I do (clean build folder and re-run, restart Safari, restart Xcode, restart computer), nothing will get my extension to show up in Safari again. Note that this does not happen with the Safari web extension in the iOS simulator. It only happens on Mac. I was confident that my extension was working, so I submitted my extension to the Mac App Store for review. It was approved, and a few users have downloaded it and it works totally fine. To further try to figure out what's going on, I created a new sample Xcode project. From the new project screen, I chose the "Safari web extension" under "Multiplatform". Without making any code changes, I build and run that project, and the default MacOS app and Safari web extension from the template. I then immediately create an archive (with no code changes). Once I try to run the project for my Mac again, the extension no longer works. So I have verified that this problem does not have to do with my extension's code, but I cannot for the life of me figure out what is wrong. I have examined every possible build setting, but given that I ran a default project template, made no changes, and it still had this problem, I'm not sure what else could be wrong.

TLDR: I’m searching for a possibility to allow the usage of passkeys and hardware keys for any website in a wkwebview INFO: The browser is macOS ONLY Hi, I couldn’t really find documentation or forums posts on how to implement Webauthn for signin or hardware security keys for a second factor. Or rather where those events are triggered to be handled. In Safari you have that popover, that lets you either authenticate through Passwords or with a security key. When I visit webauthn.io for testing and click either register or authenticate I get Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" If I add func webView(_ webView: WKWebView, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping @MainActor (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) and func webView(_ webView: WKWebView, authenticationChallenge challenge: URLAuthenticationChallenge, shouldAllowDeprecatedTLS decisionHandler: @escaping @MainActor (Bool) -> Void) it doesn’t seem to change anything. I found something about the ASWebAuthenticationSessionWebBrowserSupported entitlement, but by my understanding this is used so a browser can get opened upon some other app calling a ASWebAuthenticationSession. Has anyone some guidance for me? I feel like webauthn and yubikey support are important security measures for our users. https://codeberg.org/miakoring/Amethyst/src/branch/main/Amethyst/Shared/ViewComponents/WebKit/WebViewModel.swift is the code for my webviewmodel. Delegates are in the Delecate folder https://codeberg.org/miakoring/Amethyst/src/branch/main/Amethyst/Shared/ViewComponents/WebKit

A DNR rule with lower priority is being applied before a DNR rule of higher priority on Safari. Specifically, a low-priority DNR block rule that matches a request is being applied before a high-priority DNR redirect rule that matches the same request, preventing the redirect from occurring. The only way to get the high-priority redirect rule to occur is to remove the DNR block rule. This does not occur on other browsers. I have already submitted a Feedback Assistant report about this bug: FB16535579 How to reproduce: Create/install a web extension on Safari with the declarativeNetRequest and declarativeNetRequestWithHostAccess permissions Open the Web Extension Background Content console and add a redirect rule with a high priority number. For example: await chrome.declarativeNetRequest.updateDynamicRules({addRules: [ {id: 5000, condition: {urlFilter: "||www.google-analytics.com*/ga.js", resourceTypes: ["script"], domainType: "thirdParty"}, priority: 80, action: {type: "redirect", redirect: {url: “http://www.apple.com/”}}} ]}) Add a block rule of lower priority for the same urlFilter: await chrome.declarativeNetRequest.updateDynamicRules({addRules: [ {id: 5001, condition: {urlFilter: "||www.google-analytics.com^", domainType: "thirdParty"}, priority: 1, action: {type: "block"}} ]}) Visit https://efforg.github.io/privacybadger-test-fixtures/html/ga_surrogate.html Check the network tab and see that neither a request to Google Analytics nor apple.com appear. This means that the request to Google Analytics was blocked instead of being / before being redirected Remove the block rule: await chrome.declarativeNetRequest.updateDynamicRules({removeRuleIds: [5001]}) Reload https://efforg.github.io/privacybadger-test-fixtures/html/ga_surrogate.html. Check the network tab and confirm that there is a request to apple.com, showing that the redirect rule is only applied if the lower-priority block rule is removed. The priority of the DNR rules should handle this without having to remove a DNR rule. I have confirmed that the incorrect application of DNR rule priority happens on other top level domains, with other urlFilters, and with other redirect URLs. I confirmed that this is happening while I’ve granted my extension permissions on all websites.