Currently I am struggling to find a way to read the status of Safari Web Extension from settings as I can not find any public api listed for iOS as it is already available for macOS.

We are experiencing an issue with Safari in all versions from 18.0 to 18.5 that does not occur in version 17. It affects both iPhones and Macs. And does not happen in Chrome or Windows. The problem is impacting our customers, and our monitoring tools show a dramatic increase in error volume as more users buy/upgrade to iOS 18. The issue relates to network connectivity that is lost randomly. I can reliably reproduce the issue online in production, as well as on my local development environment. For example our website backoffice has a ping, that has a frequency of X seconds, or when user is doing actions like add to a cart increasing the quantity that requires backend validation with some specific frequency the issue is noticable... To test this I ran a JS code to simulate a ping with a timer that calls a local-dev API (a probe that waits 2s to simulate "work") and delay the next HTTP requests with a dynamic value to simulate network conditions: Note: To even make the issue more clear, I'm using GET with application/json payload to make the request not simple, and require a Pre-flight request, which doubles the issue. (async () => { for (let i = 0; i < 30; i++) { try { console.log(`Request start ${i} ${new Date().toLocaleString()}`); const res = await fetch(`https://api.redated.com:8090/1/*****/probe?`, { method: 'GET', mode: "cors", //headers: {'Content-Type': 'text/plain'}, headers: { 'Content-Type': 'application/json' }, }); console.log(`Request end ${i} ${new Date().toLocaleString()} status:`, res.status); } catch (err) { console.error(`Request ${i} ${new Date().toLocaleString()} error:`, err); } let delta = Math.floor(Math.random() * 10); console.log("wait delta",delta); await new Promise(r => setTimeout(r, 1000 - delta)); } })(); For simplicity lets see a case where it fails 1 time only out of 10 requests. (Adjusting the "delta" var on the time interval create more or less errors...) This are the results: The network connection was lost error, which is false, since this is on my localhost machine, but this happens many times and is very reproducible in local and production online. The dev-tools and network tab shows empty for status error, ip, connection_id etc.. its like the request is being terminated very soon. Later I did a detailed debugging with safari and wireshark to really nail down the network flow of the problem: I will explain what this means: Frame 10824 – 18:52:03.939197: new connection initiated (SYN, ACK, ECE). Frame 10831 – 18:52:04.061531: Client sends payload (preflight request) to the server. Frame 10959 – 18:52:09.207686: Server responds with data to (preflight response) to the client. Frame 10960 – 18:52:09.207856: Client acknowledges (ACK) receipt of the preflight response. Frame 10961 – 18:52:09.212188: Client sends the actual request payload after preflight OK and then server replies with ACK. Frame 11092 – 18:52:14.332951: Server sends the final payload (main request response) to the client. Frame 11093 – 18:52:14.333093: captures the client acknowledging the final server response, which marks the successful completion of the main request. Frame 11146 – 18:52:15.348433: [IMPORTANT] the client attempts to send another new request just one second later, which is extremely close to the keep-alive timeout of 1 second. The last message from the server was at 18:52:14.332951, meaning the connection’s keep-alive timeout is predicted to end around 18:52:15.332951 but it does not. The new request is sent at 18:52:15.348433, just microseconds after the predicted timeout. The request leaves before the client browser knows the connection is closed, but by the time it arrives at the server, the connection is already dead. Frame 11147 – 18:52:15.356910: Shows the server finally sending the FIN,ACK to indicate the connection is closed. This happens slightly later than the predicted time, at microsecond 356910 compared to the expected 332951. The FIN,ACK corresponds to sequence 1193 from the ACK of the last data packet in frame 11093. Conclusions: The root cause is related to network handling issues, when the server runs in a setting of keep-alive behavior and keep-alive timeout (in this case 1s) and network timming issue with Safari reusing a closed connection without retrying. In this situation the browser should retry the request, which is what other browsers do and what Safari did before version 18, since it did not suffer from this issue. This behaviour must differ from previous Safari versions (however i read all the public change logs and could not related the regression change). Also is more pronounced with HTTP/1.1 connections due to how the keep-alive is handled. When the server is configured with a short keep-alive timeout of 1 second, and requests are sent at roughly one-second intervals, such as API pings at fixed intervals or user actions like incrementing a cart quantity that trigger backend calls where the probability of failure is high. This effect is even more apparent when the request uses a preflight with POST because it doubles the chance, although GET requests are also affected. This was a just a test case, but in real production our monitoring tools started to detect a big increment with this network error at scale, many requests per day... which is very disrupting, because user actions are randomly being dropped when the user actions and timming happens to be just near a previous connection, where keep alive timeout kicks-in, but because the browser is not yet notified it re-uses the same connection, but by the time it arrived the server is a dead connection. The safari just does nothing about it, does not even retry, be it a pre-flight or not, it just gives this error. Other browsers don't have this issue. Thanks!

Hi! My team and I are developing an education platform. One of our features is a auto-play flashcard feature where users can listen to their flashcards hands free. We are having an issue where the autoplay wont work for users with iPhone's. I think the rule is that user's are supposed to give consent to the auto-play. We do make the user hit play before it starts so that should be the "constent" but it's still not working. Anyone have ideas?

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.

Safari is acting up. It’s appearing on my screen as a blank black screen, and then it’s retreating to the homepage.

As of iOS 26.1, Safari and WebKit views have an issue when rendering the <details> html tag. The disclosure-closed icon / character appears as an emoji arrow ▶️ instead of the unicode character ▸ (U+25B8 - Black Right-Pointing Small Triangle) For example: <details> <summary>Summary</summary> <p>Additional details....</p> </details> This wasn't the case in iOS 26.0 / iOS 18. From what I can observe it seems ▶ (U+25B6 - Black Right-Pointing Triangle) may be used in iOS 26.1 which renders as the emoji ▶️ on iOS (at least as far back as iOS 18). The only workaround I found for the moment is to specify explicit CSS to revert back to using the ▸ (U+25B8 - Black Right-Pointing Small Triangle) details > summary { list-style-type: "▸ "; } details[open] > summary { list-style-type: "▾ "; } Is this expected? I've filed a feedback for this FB20997955. Thanks!

We attempted to perform automated testing (using Python) on an 11th generation iPad (iPad A16) using Selenium 4.38.0, but we were unable to capture webpage screenshots using the function "driver.save_screenshot(filename)". However, this issue did not occur on an iPad Air 4. During our debugging of the "WebDriver.py" script, we found that after issuing the screenshot command, a status value of 500 was returned, accompanied by an "unknown error". We have communicated with the Selenium team and provided the main Python code(https://github.com/SeleniumHQ/selenium/issues/16555). They suggested that the problem likely lies within the SafariWebDriver, rather than in the "remote_webdriver.py" file. Additionally, we tried using the SafariWebDriver provided by Safari Technology Preview, but the problem persisted.

My app has been published by 2 months now I still I cant get Universal Links to work. I checked a lot of docs as well as videos about setting up universal links. Everyone with clear steps: Add the well-known json file to the server. Already validated by AASA web validator. Add the Associated domain on project capabilities, with the Web page root only. Eg: applinks:example:com. Install the app and trying clicking a link from notepad. Or instead make a long press to deploy contextual menu to see if my app is on the selectable options to open the link. My app is not been open in any of my attempts and the console always trying to use safari. I had a couple of screenshots of my testing. I really need help with this.

Hello We've encountered an issue with WKWebView in the latest iOS 26 beta. When loading a PDF URL, the background of the PDF viewer now displays as a dark gray instead of the expected white. Device: iOS 26 Simulator/Device Component: WKWebView Issue: The background color of the loaded PDF is gray. Expected Behavior: The background should be white, as it has been in all previous iOS versions. Link for Testing: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf We confirmed that the same PDF and code render with a white background on iOS 26 and earlier. Questions: Is this an intentional change in iOS 26's WKWebView? If so, is there a new property or configuration setting available to control the background color of the PDF viewer within WKWebView? We would like to have the ability to set it back to white. Any insights, workarounds, or information on this matter would be greatly appreciated. Thank you.

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.

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?

Hi. With update to 26.2 on my iPad the Favorites Bar has gone missing in Safari. "Show Favorites Bar" is selected in Apps -> Safari. I've emptied cache, deleted all history, etc in Safari. Restarted the iPad multiple times, but issues prersists. This issue is limited to my iPad. Favorites appear in both my iPhone and MacBook. Any ideas?

Reproducibility 100% on iOS 15.4 and iOS 16.6 Zero crash on iOS 18.6 Xcode 26.1 Steps to Reproduce Xcode 26.1 → New iOS App Replace ViewController.swift with the 20-line code below Run on real device • iPhone XR iOS 15.4 • iPhone 13 iOS 16.6 Tap the link → breakpoint in decidePolicyFor lldb → po navigationAction.sourceFrame Actual Result (lldb) po navigationAction.sourceFrame nil Swift declaration lies: public var sourceFrame: WKFrameInfo { get } // non-optional → Instant EXC_BREAKPOINT libswiftFoundation.dylib`URLRequest._unconditionallyBridgeFromObjectiveC Objective-C tells the truth: po [(WKNavigationAction *)navigationAction fixedSourceFrame] nil iOS 18.6 → same code prints a valid WKFrameInfo, no crash. Expected sourceFrame must be declared WKFrameInfo? in Swift or at least documented “can be nil on iOS 15–16”. Impact Every WKWebView app that touches sourceFrame on iOS 15.4 & 16.6 ships with a latent crash. Production Workaround @implementation WKNavigationAction (Safe) (WKFrameInfo *)fixedSourceFrame { return self.sourceFrame ? self.sourceFrame : nil; } @end Minimal Test (copy-paste) import UIKit import WebKit class ViewController: UIViewController, WKNavigationDelegate { lazy var web = WKWebView(frame: view.bounds) override func viewDidLoad() { super.viewDidLoad() web.navigationDelegate = self view.addSubview(web) web.load(URLRequest(url: URL(string: "https://www.apple.com")!)) } func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, preferences: WKWebpagePreferences, decisionHandler: @escaping (WKNavigationActionPolicy, WKWebpagePreferences)->Void) { print(navigationAction.sourceFrame) // ← crashes on 15.4 & 16.6 decisionHandler(.allow, preferences) } }

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?

Hello Apple Developer Community, I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26. Problem Description: I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior: PDF links should remain clickable and functional across all iOS versions. What I've Tried: Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps: Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment: Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2 Questions: Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity? Any guidance or suggestions would be greatly appreciated!

Hey Guys My PWA video playback and even youtube videos stopped working after updating iOS to 26.0.1. The video thumnails appear fine and if i try to play the video, it remains stuck. If i restart the phone, the video plays for a second in the PWA and then stops again and entire app gets stuck. Request apple team to fix this issue at the earliest. This is hampering all my iOS users who install the PWA on their device homescreen and use it as app. FYI strangely EVERYTHING WORKS FINE ON iOS SAFARI browser including videos playback If i open it as a web app. so this seems like a specific PWA issue on latest ios 26.0.1

We have a SAML-based SSO App Extension that uses WKWebView to load the SAML login request. This implementation has been working correctly on iOS versions prior to 26. However, starting with iOS 26, the extension consistently crashes when calling WKWebView.load(_:). The crash occurs inside WebKit, specifically in: /Library/Caches/com.apple.xbs/Sources/WebKit/Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp at WebKit::WebPageProxy::loadRequest(...) No app-level exception is thrown, and the extension terminates with: Thread 10: EXC_BREAKPOINT (code=1, subcode=0x1a31dbe00) It appears that WKWebView initialization or WebsiteDataStore creation is now restricted in extension contexts on iOS 26, but this change is not documented in the SDK release notes. Could you please confirm if this is an intentional sandbox restriction in iOS 26 or a regression in WebKit? Steps to reproduce: Implement an App Extension using ASAuthorizationProviderExtensionAuthorizationRequest. Create a WKWebView instance in the extension. Attempt to load a SAML login request (POST request with headers). Observe immediate crash on iOS 26 (works fine on earlier versions). Expected behavior: WKWebView should load the request or fail gracefully as in prior releases, without crashing the extension process. Request: Please clarify if WKWebView usage inside extensions is officially unsupported as of iOS 26, and if so, recommend an alternative approach for handling SSO flows.

Could somebody provide hello world example of Safari Extension which is able to call on-device Foundation Model (Apple Intelligence)? I cannot find any examples yet

As the title suggests, given today’s overpowered device performance, shouldn’t Safari and WKWebView allow repainting during window resizing? Currently, all WKWebView-based apps pause page rendering during resize. When a user double-clicks the drag region, the sequence goes: pause rendering → enlarge or shrink the window → leave a blank area → repaint the page. The whole process feels inelegant—especially on devices that support ProMotion.

YouTube now requires a Referer to be sent to be able to embed Youtube videos, otherwise the videos won't work. But WKWebView doesn't send a Referer when using a custom scheme, so Youtube videos stopped working in that case. This affects Ionic apps, both using Cordova or Capacitor. There's an open issue for Cordova and another one for Capacitor. In these apps, the app is served using a custom scheme like capacitor://localhost or ionic://localhost. I tried modifying the Ionic WebView source code to force adding a referrer to the URL loaded using WKWebView's loadRequest: [request addValue:@"https://my.test.app" forHTTPHeaderField:@"Referer"]; [_engineWebView loadRequest:request] But the Referer is still not sent in the Requests, I guess because the app is using a custom scheme (e.g. capacitor://localhost). However, if I modify this code to force loading an "online URL" (using https) instead of capacitor://localhost, then the my.test.app Referer is sent to the requests. Is there any way to make WKWebView send a Referer when using a custom scheme?