When using iOS 26.2 (23C55) Safari, the following can occur. The current tab (A) opens a new tab (B) via window.open(url, target, windowFeatures). The user clicks the "back" button to close tab B, and returns to tab A. Tab A attempts to open tab B again at a later point, using the same "target" as before, and fails (no window object is returned by window.open). This bug only occurs when the target is the same as the previously closed tab (which was closed via the back button). If a new target is specified, the new tab opens as expected. This bug is also limited to the back button. If the user manually closes tab B, then it can be re-opened by tab A using window.open using the same target as before.

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?

We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.

//Is my post method correct because google and claude are telling me I must use content type for the json and use .setvalue. I thought that my process was correct because I encode the data to turn into json and then make the request func createTask(_ task: Task) async throws -> Task { if let url = URL(string: "(baseURL)/todos"){ var request = URLRequest(url: url) request.httpMethod = "POST" let encoder = JSONEncoder() do{ let data = try encoder.encode(task) request.httpBody = data let (data, response) = try await URLSession.shared.data(for: request) return task //we want to make encoder and then turn the data into json and put it in body } catch{ throw JSONErrors.encodingFailed } } else{ throw URLError(.badURL) } }

When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?

We have written a PAC script that blocklists certain domains and whitelists others. We went to Settings > Network > Wi-Fi (the network we are using), then clicked on Details, and under Proxies, we added the PAC file URL in the Automatic Proxy Configuration section. We tried hosting the PAC file both on localhost and on a separate HTTP server. After saving the settings, we tested several URLs. The blocking and allowing behavior works correctly in all browsers except Safari. Below is the PAC script we are using for your reference. The script works as expected in browsers other than Safari. This is how the PAC script URL looks: http://localhost:31290/proxy.pac function FindProxyForURL(url, host) { var blacklist = new Set(["facebook.com", "deepseek.com"]); var b_list = [...blacklist]; for (let i = 0; i < b_list.length; i++) { let ele = b_list[i] + "*"; if (shExpMatch(host, ele) || shExpMatch(url, ele)) { return "PROXY localhost:8086"; } } if (isIPBlocked(whitelist_subnet, hostIP)) { return "PROXY localhost:8087"; } if (isIPBlocked(blacklist_subnet, hostIP)) { return "PROXY localhost:8086"; } return "PROXY localhost:8080"; }

I recently updated my iPhone 12 to iOS 26. It seems there is a bug rendering Safari unable to "add to home screen" any website. Clicking the button displays a blank modal with Add button greyed out.

After App uses Network.framework PrivacyContext Api, dns has been encrypted, that is good. But when using wkwebview to load web page, wireshark captures normal dns request sent by wkwebview. Does wkwebview use DoH to resolve domain? if can, how to config params? If can not, is there anyway to stop wkwebview sending normal dns, such as local proxy.

WKWebView has a new property "isBlockedByScreenTime" since iOS 26. But I do not yet understand when exactly this property could be used. When I setup content-based restrictions in the ScreenTime settings then WKWebView reports an error 105 via "webView:didFailProvisionalNavigation:" delegate. The isBlockedByScreenTime property still returns false in this case. If ScreenTime has a time-based limit, the App would not run at all. Under which circumstances would the property "isBlockedByScreenTime" return the value true? When exactly and for what can this property be actually used? The "problem" is that I want to find if a web page is blocked and can not be loaded, why this is the case. By simply trial and error I found out that WKWebView returns error codes 104 and 105 for blocked web sites because of content filters and Screen Time restrictions, however these error codes are not documented at all (at least I've not found any documentation or documentation for these error codes and also some other codes like 100, 102, 204 etc), so I'm not really sure if I handle all cases correctly. I hoped that isBlockedByScreenTime would at least tell me one reason for blocked pages. If there are documents which explain these error codes (100 and above), where I can find these?

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

PLATFORM AND VERSION iOS Development environment: Xcode 16.2, macOS 15.3.2 Run-time configuration: iOS 15-18 This happens in iOS, and leads to to the hybrid home page showing users as wrongly unauthenticated, since the at cookie is missing. For context, we have a JWT token that is stored in the Keychain, and on app launch, before any WKWebViews are created, we synchronize this to the WKWebsiteDataStore as an at cookie. We have analytics instrumentation on our websitef to show that WKWebView randomly refuses to send out any cookies. – The following is a snippet from an explanation to the WebKit Slack: We are having an issue on iOS, in which WKWebView loads pages (and even subsequent reloads) without any cookies, even though we have stored cookies in WKWebsiteDataStore.default() before hand right after application launch and becoming a key window. We reference this object, store it as a singleton, (as well as a process pool), and then all webview configurations are initialized with the same data store, the same process pool, every call on the main thread. From reading the source code, it seems that if the internal IPC logic fails, the APIs for deleting and setting data records and cookies fail without any feedback in completion handlers. This bug often happens when returning from the background on iOS after a few hours. Sometimes it happens on cold launches of the app. We have mitigated a similar issue (no cookies being sent) by implementing webViewWebContentProcessDidTerminate and reloading the webview ourselves, we found that whatever webview does to reload if that method is not implemented leads to cookies not being used. There have been multiple reports of WKWebView losing cookies in recent iOS versions, and we have tried to implement all of the workarounds listed. Setting a maximumAge to the cookies we store, and doing a _ = await websiteDataStore.dataRecords(ofTypes: Set([WKWebsiteDataTypeCookies])) before accessing or modifying websiteDataStore.httpCookieStore Question: is it safe to work with WKWebsiteDataStore before a WKWebView is added as a view, if so are there any timing considerations? Are there any logs that we can take a look at, this issue is very hard to reproduce, about 2% of our users face it at scale? Is there anything that could be happening within our process (runloop issues, timing) that could be causing this issue? See multiple reports from other companies that have faced the issue: "Now the Thermonuclear Problem with WKWebViewDataStorage" https://medium.com/axel-springer-tech/synchronization-of-native-and-webview-sessions-with-ios-9fe2199b44c9 STEPS TO REPRODUCE They don't exist, because the issue only happens at scale. We just know that no cookies are sent for a small percentage of requests. We believe this to be an issue in which Webkit fails to communicate internally with whatever IPC mechanisms it has. We have not been able to reproduce this issue consistently. The best we can give is that it happens after a few hours that the app is in the background. This happens regardless of whether the WKWebsiteDataStore is persistent or not, but seems to be much worse when it is persistent. Thus we have disabled persistnet data stores and relied on nonPersistent. The issue is bad enough that we are trying to move away from relying on cookies for iOS and just use request headers which we can only set on the top level request of WKWebView. DTS Case-ID: 13154329

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.

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.

Since Safari requires a macOS app as a container for Web Extensions, is there a way to establish native messaging directly from SafariWebExtensionHandler using stdin/stdout? Or does Safari enforce a different communication mechanism? I’d like to keep the same approach as other browsers. Any guidance on making this work would be appreciated!

I am new to PHP. I have developed my own web site with a lot of javascript in simple HTML files. I want to do some extensions with PHP but I can't make a simple web page function. I am sure something simple is wrong. Help! Here is the test web page I made: hello.html <html>  <head>   <title>Hello World</title>  </head>  <body>   <?php echo 'Hello World!'; ?>  </body> </html> Pointing Safari at hello.html gives me a new tab with the correct title, but no "Hello World" in the page itself. Here is the output of php --version: WARNING: PHP is not recommended PHP is included in macOS for compatibility with legacy software. Future versions of macOS will not include PHP. PHP 7.3.24-(to be removed in future macOS) (cli) (built: Jun 17 2021 21:41:13) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies

Hi there, I have a popular open source app called Foqos. What I'm finding in iOS 26 (might even effect older versions) is that when using the webcontent api within Managed settings as the following: store.webContent.blockedByFilter = .specific(domains) It doesn't work on Safari, but does work on third party applications like chrome, firefox, etc. But when using the all and exception enum like the following store.webContent.blockedByFilter = .all(except: domains) This does work on Safari This is pretty inconsistent behavior of the API and should be fixed to match the documentation. Documentation does not mention anything about Safari limitations Again source code is open: https://github.com/awaseem/foqos You can run the app yourself and find the same issues. Is anyone else experiencing this?

I am developing an SSO Extension so that I can have SSO with Keycloak across applications. OIDC/OAuth2 works very well. But I am struggling with SAML. It works, but it seems that the form submission is always triggered twice. I use decisionHandler(.cancel) to stop the form submission and redirect it to the browser. I still get the form submitted both by the extension and by the browser. At some point I tried to allow the form submission in the Extension so that I get the redirect with the response to the browser. It still triggered another submission. Does anyone experience this issue?

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

Subject: iOS 26 WKWebView: Remote Pages Become Unresponsive After Loading Local HTML Files Description We're experiencing a critical issue with WKWebView in a React Native 0.64.3 application where remote web pages become completely unresponsive after loading local HTML files in iOS 26. It works well before iOS26. Environment: React Native 0.64.3 iOS 26.0 Xcode 26.0.1 Using custom WKWebView implementations in Native modules Problem Details App loads local HTML files using loadFileURL:allowingReadAccessToURL: Later, when loading remote pages via loadRequest:, the remote pages load successfully but become unresponsive to user interactions This occurs even when using different WKWebView instances The issue is reproducible 100% of the time once a local file has been loaded Restarting the app and loading remote pages directly works fine Code Example: // Loading local file (works fine) [self.webView loadFileURL:localFileURL allowingReadAccessToURL:accessURL]; // Later, loading remote page (loads but becomes unresponsive) NSURLRequest *request = [NSURLRequest requestWithURL:remoteURL]; [self.webView loadRequest:request]; What We've Tried: Using different WKWebView instances for local vs remote content Comprehensive cleanup in dealloc (removing all user scripts and message handlers) Loading blank HTML before switching to remote content Using shared WKProcessPool (understanding its limitations in iOS 15+) Ensuring proper decisionHandler management in navigation delegates Resetting WKWebView configuration settings Clearing cookies and cache between loads Using loadFileRequest:allowingReadAccessToURL: instead of loadFileURL: Key Observations: The remote page renders correctly and network requests complete No JavaScript errors in console The view hierarchy appears normal in Debug View Hierarchy Touch events seem to be delivered but not processed by the web content Questions: Has Apple introduced new security restrictions in iOS 26 that affect the transition from file:// URLs to http:// URLs? Are there specific WKWebView configuration changes required for React Native applications in iOS 26? Could this be related to the React Native bridge or JavaScript context persistence? Any insights or workarounds would be greatly appreciated, as this is blocking our iOS 26 compatibility.

I have a Safari extension that plays audio via the javascript AudioContext API. It was working fine under iOS 17 and is now broken under iOS 18. It does not play audio at all. I've tried in both the iOS 18 public beta and the iOS 18.1 developer beta. It is broken in both of them. I've also created Feedback item FB15170620 which has a url attached to a page I created which demonstrates the issue.