It seems Safari 18's fetch() does not include credentials even credentials: include and safari extension has host_permissions for that domain. Is there anyone has this problem? I try to request in popup.js like this: const response = await fetch( url, { method: 'GET', mode: 'cors', credentials: 'include', referrerPolicy: 'no-referrer', } ); and it does not include the cookie from host_permissions. Those code worked in Safari 17 (macOS Sonoma).

Since Xcode 26 our tests are crashing due to the Main Thread not being able to deallocate WKNavigationResponse. Following an example: import Foundation import WebKit final class WKNavigationResponeMock: WKNavigationResponse { private let urlResponse: URLResponse override var response: URLResponse { urlResponse } init(urlResponse: URLResponse) { self.urlResponse = urlResponse super.init() } convenience init(httpUrlResponse: HTTPURLResponse) { self.init(urlResponse: httpUrlResponse) } convenience init?(url: URL, statusCode: Int) { guard let httpURLResponse = HTTPURLResponse(url: url, statusCode: statusCode, httpVersion: nil, headerFields: nil) else { return nil } self.init(httpUrlResponse: httpURLResponse) } } import WebKit import XCTest final class ExampleTests: XCTestCase { @MainActor func testAllocAndDeallocWKNavigationResponse() { let expectedURL = URL(string: "https://galaxus.ch/")! let expectedStatusCode = 404 let instance = WKNavigationResponeMock() // here it should dealloc/deinit `instance` automatically } Here the call stack: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x101f3dd54 CFRetain.cold.1 + 16 1 CoreFoundation 0x101e14860 CFRetain + 104 2 WebKit 0x10864dd24 -[WKNavigationResponse dealloc] + 52

Hi there! I'm new to App Development and I'm running into the following error when playing audio on a website loaded through a WKWebView: 0x112000cc0 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'WebKit Media Playback' for process with PID=70.197, error: Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)" UserInfo={NSLocalizedFailureReason=(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)} Looking through this forum, it seems more people have this issue, yet no one has found a solution (or posted it...). The solutions that I did find (Background Modes capability, webView.configuration.allowsInlineMediaPlayback = true), did nothing. To make sure the issue had nothing to do with my own code, I created an empty project to reproduce the issue. I'm not sure on the best way to share it, but it's a small file (forgive me, I have no clue what it does, actually chatGPT made it for me. My real application is a WebApp wrapped with Capacitor, so it handles all the Swift stuff) import SwiftUI import WebKit struct WebView: UIViewRepresentable { let urlString: String func makeUIView(context: Context) -> WKWebView { let webView = WKWebView() webView.configuration.allowsInlineMediaPlayback = true webView.configuration.allowsAirPlayForMediaPlayback = true webView.navigationDelegate = context.coordinator return webView } func updateUIView(_ uiView: WKWebView, context: Context) { if let url = URL(string: urlString) { let request = URLRequest(url: url) uiView.load(request) } } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, WKNavigationDelegate { var parent: WebView init(_ parent: WebView) { self.parent = parent } func webView(_ webView: WKWebView, didFailProvisionalNavigation navigation: WKNavigation!, withError error: Error) { print("Web page loading failed: \(error.localizedDescription)") } } } struct WebViewDemo: View { var body: some View { NavigationView { WebView(urlString: "https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_audio_all") .navigationBarTitle("Web View") } } } struct WebView_Previews: PreviewProvider { static var previews: some View { WebViewDemo() } } Nothing special, right? When I build the app and navigate to a website that has an tag (https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_audio_all). I still see the error when I play the audio. It plays nonetheless, but the error is there. I'm not at all interested in actually playing audio in the background/when the app is closed/suspended. I just want the error to go away! I've tried different iOS versions (14,15,16,17), but the problem persists. Anyone know what's happening?

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

I don't know why but all of a sudden when I build the extension it just doesn't load in Safari. The build executes fine but the extension doesn't load. Sometimes, through trying different combinations of clearing the build folder, building, archiving, ... it suddenly loads. And the next time I build again it doesn't load properly. So I can't do any work on it or test anything. I don't know why all of a sudden I am getting this behavior. It looks like engineers at Apple are constantly trying to overcomplicate a process that is at least ten times simpler in any other browser. This is ridiculous. Is this what our annual fee goes to? And they don't even provide any support for that. Several times I've tried to get some help here just to have to spend hours upon hours to figure it out by myself. I'm so tired of this.

If the Safari Technology Preview window is located on an external monitor with DisplayLink and the computer goes to sleep (screen saver), when it returns, it closes with an error. If the window is located on another monitor that is connected by USB, it does not close. Equipo: Macbook Pro M4 Pro SO: MacOS Sequoia 15.6.1 Safari Technology Preview: Release 227 (preview version work fine) DisplayLink Manager: 13.0.1 (build 46)

Is the new Observations API for WebPage not available in Beta 1 as demoed in the WWDC video? I get this error even though Observation is imported.

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.

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. During user testing we found that the tab title and tab URL properties are empty when obtaining the set of open windows via windows.get() after a Safari restart. We are testing with Safari 18.4 (20621.1.15.11.10). We have made a TestFlight version of our app and extension available to help with testing: https://testflight.apple.com/join/Va8Zdv9d. Screenshot and screen recording are attached to the Feedback ID supplied below. STEPS TO REPRODUCE Install Tabby via the TestFlight link Enable the Tabby for Safari extension in the Safari extensions dialog Grant permissions for Tabby for Safari to all windows all the time Within Safari, open two windows each with at least two tabs Within the Tabby app, ensure you see the windows and tabs listed correctly (tab title displayed for each) Quit and restart Safari Expected behavior Safari re-opens existing windows and Tabby displays title for each tab Observed Safari re-opens existing windows but within Tabby all tabs except the current tab are displayed with a title of “Start Page”. Under the hood the tab title and tab URL properties are empty when returned via a windows.get() call after Safari restarts. NAME AND APPLE ID OF APP Tabby - Browser Tab Manager 1586203406 FEEDBACK ASSISTANT ID FB16389506

I am maintaining a PWA that utilizes WebSockets. In this app, after the web page is loaded from the server, JavaScript establishes a WebSocket connection. Because the app connects to a completely local server on a managed local network, we use http:// and ws:// (non-secure). The Issue: The app worked perfectly from older iOS versions up to iPadOS 18. However, during testing on iPadOS 26, we encountered an issue where the WebSocket connects successfully but is disconnected by the iPad approximately one second later. According to our packet captures, the iPad is sending a FIN packet to initiate the teardown. Additional Context: What makes this particularly confusing is that we have another server hosting the exact same PWA where the WebSocket connection stays stable even on iPadOS 26. This suggests it might not be a universal OS bug, but perhaps related to specific network conditions or a new security policy. Has anyone experienced similar behavior on iPadOS 26? Could this be a bug, or is there a new security restriction regarding non-secure WebSocket (ws://) connections in local networks? Are there any known changes in WebKit/Safari for iPadOS 26 that might cause the OS to send a FIN packet immediately after a handshake? I would appreciate any insights or suggestions on what might be causing this.

Safari 26 close and Refresh buttons not working in Compact tab layout

Hi everyone, I’m encountering a serious reliability issue with message passing in my Safari extension on iOS 18.4.1 and iOS 18.5 In my extension, I use the standard messaging API where the background script sends a message to the content scrip. The content script is listening using: browser.runtime.onMessage.addListener(handler); This setup has been working reliably in previous versions of iOS, but since updating to iOS 18.4.1 and iOS 18.5, I’ve noticed that messages sent from the background script are not consistently received by the content script. From my logs, I can confirm that: The background script is sending the message. The content script’s listener is not always triggered. There are no errors or exceptions logged in either script. It seems as if browser.runtime.onMessage.addListener is either not getting registered in time or failing silently in some instances. This issue is intermittent and does not occur all the time. Has anyone else experienced similar issues in iOS 18.4.1 and 18.5? Are there any known changes or workarounds for ensuring reliable communication between background and content scripts in this version? Any help or insights would be greatly appreciated. Thanks!

Subject: Unexpected system confirmation dialog when opening a Universal Link Description of the issue: We’re implementing a login flow using Native iOS apps, Universal Links, and OpenID Connect authentication. Our domain is correctly configured with the apple-app-site-association file, and Universal Links work as expected. However, under certain circumstances, the behavior differs on the same login page: The user connects to the OIDC provider in their mobile browser. Instead of automatically switching to the Native application, a popup asks the user to open the app. The behavior depends on how the login page is opened: When opened in a new browser tab, the Universal Link opens the app immediately without showing any system confirmation dialog. When the same tab is reused without a page refresh, iOS displays a system confirmation dialog asking the user to open the link in the app. This confirmation dialog doesn’t appear in the first scenario. This additional system dialog impacts the user experience, as we aim for a frictionless and seamless login flow with minimal confirmation steps. Question: Why does the app switch work automatically only the first time? Is this intentional iOS behavior? If so, what security requirement or system rule causes a confirmation dialog when reusing the same tab, but not when redirecting in a new tab or pressing a button on the reused tab? Is this expected design, or should we adjust our side to avoid this dialog? Environment details: Verified on two devices iOS versions: 18.7.2, 26.1 Thanks for your help.

navigator.permissions.query -> permissionStatus.onchange is Supposed to listen to the event of a change in permissions in the browser settings. This works for all browsers, but in Safari for iOS and MacOS this seems to be broken in the currently recent versions 17.x Example: navigator.permissions.query({ name: 'notifications' }).then((permissionStatus) => { permissions = permissionStatus.state; // this value gets set correctly permissionStatus.onchange = () => { // This will not get executed when permissions have been changed // within the safari settings app, or iOS Settings for PWA or Safari }; }); Can someone from Apple's Webkit Team please comment on this? Thank you. T.

I am reporting what appears to be a serious integrity flaw in Safari under iPadOS 26.3 (and lower) that materially undermines the reliability of Screen Time parental controls. This is not merely a UX inconsistency but a functional contradiction within a system explicitly marketed and positioned as secure parental control infrastructure. Device / Environment Device: iPad Air M3 13" (2025) OS: iPadOS 26.3 Safari (system version) Screen Time enabled with active restrictions Child account (10 years old) Background We deliberately chose an Apple device for school use based on the expectation that Apple’s system-level parental control mechanisms — especially Screen Time — are robust, tamper-resistant, and technically consistent. Screen Time is configured with: App limits Downtime Parental controls enabled with limited web content restrictions (school requirements prevent strict blocking) Safari enabled (mandatory for educational use) further parental control restrictions Because aggressive website blocking would interfere with legitimate school activities, monitoring Safari browsing history is a central supervisory mechanism. When Screen Time is active: Clearing the entire browsing history via Safari is correctly blocked. Clearing history via system settings is correctly blocked. The system explicitly communicates that deletion is not permitted due to Screen Time restrictions. This behavior establishes a clear user expectation: Browsing history is protected against manipulation. The Issue Despite the above safeguards, individual browsing history entries can be deleted easily and silently through the address bar suggestion interface. This creates a structural contradiction: Full deletion is blocked. Selective deletion — which is arguably more problematic — remains possible. Steps to Reproduce Enable Screen Time with restrictions that prevent deletion of browsing history (for example on a student device with a child account). Open Safari and visit any website. Confirm it appears in Safari history. Tap the Safari address bar. Type part of the URL or page title. Safari suggests the previously visited page below the address bar. Swipe left on that suggestion. A red “Delete from History” button appears. Tap it. Actual Result The entry disappears immediately: No Screen Time PIN required No authentication request No warning No restriction triggered No parental notification No audit trace visible Deletion occurs silently and irreversibly. Expected Result When Screen Time is configured to prevent browsing history deletion: Individual entries must not be deletable Deletion must require Screen Time authentication Anything else defeats the protective purpose of the restriction. Real-World Impact In practical use, this allows minors to selectively sanitize browsing history while preserving a seemingly intact record. In our case, this method is widely known among classmates and routinely used to conceal visits to gaming or social media platforms during school hours. The technical barrier to exploitation is negligible. This results in: A false sense of security for parents A discrepancy between advertised functionality and actual system behavior A material weakening of parental control integrity When a system explicitly blocks full history deletion but permits silent selective deletion, the protection mechanism becomes functionally inconsistent and unreliable. Given that Screen Time is publicly positioned as a dependable parental control framework, this issue raises concerns not only about implementation quality but also about user trust and reasonable reliance on advertised safeguards. Request Please classify this as a parental control integrity and trust issue. Specifically: Disable individual history deletion while Screen Time restrictions are active OR Require Screen Time passcode authentication for deleting single entries Screen Time is presented as a secure supervisory environment for minors. In its current implementation under iPadOS 26.3 and before, that expectation is technically not met. This issue warrants prioritization.

I have a local HTML file used to display mixed content with images and text. Here's the issue: the same file displays everything correctly in Google Chrome, showing both images and text as expected. However, when opened in Safari, only the text is shown—images are missing, which is very strange. Interestingly, if I remove .png from the title attribute of the tag, the images show up properly in Safari. Alternatively, if I comment out the inclusion of html2canvas.min.js, the images also display correctly (although the layout breaks without it). I'm not sure if this is a Safari-specific issue. Can anyone explain what might be causing this problem?

The crash is specific to iOS 26.2 prior versions working fine. WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) Name attribute is accessible but WKScriptMessage body attribute causes crash The object seems to be not accessible(not in memory) self.webkit.configuration.userContentController.add(self, name: "sampleHandler") self.webkit.load(request) func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { print(message.name) // works print(message.body) // crashes }

I have a simple Safari extension for iOS. In its popup, I want a button that will open the app via a universal link. I have this kind-of working, except that Safari opens the actual online destination of the link with a banner at the top saying "Open in the XXXX app" and an OPEN button. What do I have to do to go directly to the app? More generally, I know that if I copy-and-paste a universal link into the Safari address bar, Safari does the same thing - but it does go directly to the app from an <a href="...."> link. In my app extension JavaScript, I set window.location. Presumably this is too similar to pasting into the address bar. Is there some alternative to setting window.location that is more like clicking on a link and will go directly to the universal link's app? Thanks.

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); } };

Hi! I configure proxy for webview like DispatchQueue.main.async { self.webView.configuration.websiteDataStore.proxyConfigurations = [proxyConfiguration] } It is fine in iosiOS 17 however, it crashes in iOS 18.3. And the problem seems to be related to the left side of the equation. I tried to call print(self.webView.configuration.websiteDataStore.proxyConfigurations.count) in async block and got the same bad access error. But if stop at that line of code and call po self.webView.configuration.websiteDataStore.proxyConfigurations in debugger it returns 0 elements. Did anyone have the same problem? What may cause the exception?