I have an extension which was working fine on older Safari version, but it is getting killed after I upgraded the browser to Safari 18 and higher. From the system logs I could see, Safari is sending the KILL signal to my browser 2024-11-12 13:51:01.536167-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] signal service: caller = Safari[45238], value = 0x9 2024-11-12 13:51:01.536453-0600 0xfab Default 0x0 382 7 WindowServer: (SkyLight) [com.apple.SkyLight:default] [ ConnectionDebug ] Closing conn 0xf955b, PID 45463 in session 257 on console2024-11-12 13:51:01.536474-0600 0x95b674 Default 0x0 1 0 launchd: [gui/503 [100018]:] service inactive: com.apple.xpc.launchd.unmanaged.SafariExtension.45463 2024-11-12 13:51:01.536479-0600 0x95b674 Default 0x0 1 0 launchd: [gui/503 [100018]:] removing inactive unmanaged service: com.apple.xpc.launchd.unmanaged.SafariExtension.454632024-11-12 13:51:01.537354-0600 0x95b907 Default 0x0 354 0 launchservicesd: [com.apple.processmanager:front-35286506] QUITTING: pid=45463 asn=0x-0x176176 foreground=0 wasFront=0 2024-11-12 13:51:01.537375-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] exited due to SIGKILL | sent by launchd[1], ran for 342ms 2024-11-12 13:51:01.537380-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] service state: exited 2024-11-12 13:51:01.537384-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] internal event: EXITED, code = 0 2024-11-12 13:51:01.537385-0600 0x95b672 Default 0x0 1 0 launchd: [pid/45238/SafariExt [45463]:] job state = exited Just before this, I see a macOS error 2024-11-12 13:51:06.789342-0600 0x95b74f Default 0x0 45238 0 Safari: (Security) [com.apple.securityd:security_exception] MacOS error: -67054 This occurs only in my customer machines but not in my test machines. I have verified the code signing, certificate validity & entitlements are fine.

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.

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.

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.

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?

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.

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

Hi, I am developing an OpenType font with the following cursive feature. feature curs { lookup cursivejoinrtl; # RIGHT_TO_LEFT flag set between Hah, Meem, Yeh and final Meem lookup rehwawcursive; # RIGHT_TO_LEFT flag clear between Waw and Hah } curs; Here is the rendering of the word وحميم in TextEdit. Using HarfBuzz I got the following result. The same rendering problem occurs when using Safari. It seems that is related to Core Text. I reported the issue to Feedback Assistant over a year ago but haven't had a response yet. So I'm posting the problem on this forum. Any support on this matter would be greatly appreciated.

I have a very specific issue that happens only on iOS Simulator version 18.4. It does NOT happen when I run my app on a real iOS 18.4 device through Testflight. My app displays a WebView (courtesy of Capacitor, url scheme capacitor://). Inside that Webview I'm using Firebase JS API (11.2.0) and calling signInWithEmailAndPassword, which works well in all other contexts, i.e. browser, Android webview, iOS webview in all other Simulator versions, and on real devices. Only when running in Simulator 18.4, I get a failed network request: cannot parse response Fetch API cannot load https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?... due to access control checks. Failed to load resource: cannot parse reponse error: FirebaseError: (auth/network-request-failed) Everything is working correctly for both: Capacitor app webview installed on a real 18.4 device with Testflight Safari (non-webview) in the 18.4 Simulator The issue is severe for us, because we are unable to develop our app and test it in the simulator on 18.4 Simulator before pushing it through Testflight internal release. Request headers on the failed request (no response status or headers available). Request Accept: / Content-Type: application/json Origin: capacitor://localhost Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: cross-site User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) - AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 X-Client-Version: Mobile/JsCore/11.2.0/FirebaseCore-web X-Firebase-Client: (...)

We are experiencing a compatibility issue with our hybrid app related to the recent update in iPadOS 18.4, specifically concerning HTTPS connections. What are the key changes introduced in iPadOS 18.4 regarding HTTPS connections? Our app previously managed to bypass the DigitalSignature key usage missing error in the self-signed server certificate within the didReceiveAuthenticationChallenge method, as documented here: https://developer.apple.com/documentation/webkit/wknavigationdelegate/webview(_:didreceive:completionhandler:) . However, since the update to iPadOS 18.4, this method is no longer being called, resulting in direct failure of HTTPS connections. We are using cordova-ios 7.1. Thanks in advance for your help.

We’re seeing an issue in our Safari Web Extension where not all cookies from the Set-Cookie response header are accessible. We are using macOS 15.4 and Safari 18.4. In the webRequest.onHeadersReceived callback, the Set-Cookie header returned by Safari only includes some of the cookies set by the server. If multiple Set-Cookie headers are present, we seem to receive only a partial list, some cookies are missing entirely. In Chrome and Firefox, the same callback provides all cookies set by the server without issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

DNR rules redirecting to an extension path lead to an error page: “Safari can’t open the page. The error is: “The operation couldn’t be completed. (NSURLErrorDomain error -1008.)” (NSURLErrorDomain:-1,008).” Here is a demo extension that replicates the bug: https://github.com/lenacohen/Safari-Test-Extensions/tree/main/dnr-extension-path-redirect This is an example of a redirect rule that leads to an error page instead of the extension path page: chrome.declarativeNetRequest.updateDynamicRules({addRules: [ { id: 2, priority: 1, action: { type: "redirect", redirect: { extensionPath: "/web_accessible_resources/test_redirect.html" } }, condition: { urlFilter: "||washingtonpost.com^", resourceTypes: [ "main_frame" ] } } ]}); The extension path is included in web_accessible_resources in the extension manifest: "web_accessible_resources": [{ "resources": [ "web_accessible_resources/test_redirect.html" ], I also submitted a bug report on Apple's Feedback Assistant: FB16607632

Hello, I'm not able to get the webauthn attestation statement using the option (attestation.direct) on Safari. The answer I get is a fmt of none and a aaguid of zeros. The same code works on Chrome and I was able to get a none zero aaguid and a packed fmt attestation. Can you explain why this does not work on Safari ? Thank you.

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?

We encountered an issue with universal links where the link failed to open the iOS application from Safari when triggered by an javascript outside a click event. However, when we modified the code to open the link directly via a user click, the application launched as expected. Based on our testing, this issue seems to occur only when there is information for the application cached in Safari (i.e. IDP page cached, redirects to our app, javascript based universal link navigation fails). Here is a code example of what caused the universal link failure: const openUniversalLink = () => { buttonClicked = True } useEffect(()=> { if (buttonClicked) { window.location.href = universal_link } } <Button onClick={openUniversalLink} /> Here is a code example of what caused our universal links to open successfully: const openUniversalLink = () => { window.location.href = universal_link } <Button onClick={openUniversalLink} /> Are there defined practices of when we are able to open universal links triggered by javascript vs when they must be opened directly through user action?

Hi Apple Team, We’ve noticed a couple of issues with launching default App Clip in safari and would appreciate your guidance. App Clip Popup Timing: When launching the App Clip using default URL, we sometimes see the small App Clip popup appear before the App Clip banner is displayed. Ideally, the banner should appear first. Cached URL Handling: In certain cases, the App Clip appears to be using a cached URL instead of the most recent one. For example, when we invoke two different App Clip URLs with unique parameters, the App Clip sometimes launches using the previous URL’s data instead of the new one. This behavior is inconsistent and makes it difficult to ensure users are directed to the correct experience each time. Could you please help us understand whether this is expected behavior or if there are any known issues or recommended solutions? Thank you for your time and support. Example

Dear Apple Developer Support, We are currently developing a system that requires the ability to edit Japanese vertical text within the Safari browser on iPhone. During our investigation, we encountered an issue that matches the following WebKit bug: 283620 – Caret Positioning Issues in Vertical Writing Mode We understand that this issue is being addressed in the following pull request: https://github.com/WebKit/WebKit/pull/39939 However, it appears that a complete fix has not yet been implemented. Given this situation, we would like to confirm the following: Is there any known workaround for this issue in iOS 17.5 or iOS 18.5 (the latest versions as of now)? If a workaround exists, could you please provide details? If not, could you share the expected timeline for a full resolution of this issue? Although this appears to be an open-source WebKit issue, we are reaching out to Apple because WebKit is tightly integrated with iOS and Safari, and ultimately delivered as part of the iPhone experience. Thank you very much for your support. Best regards, Takao Kurabayashi

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?

Hi, we have PWA for which we´ve built a wrapper using PWA Builder tool and we are experiencing an issue with apple sign in. When we try to redirect the user to "https://appleid.apple.com/auth/authorize?...params...", a bottom sheet login prompt appears and only once the user signs in using the prompt he is then redirected to the url where he needs to sign in again and then we get the callback. We want to get rid of that bottom sheet prompt. The code we´ve tried: ` iosButton.addEventListener('click', function () { window.location.href = "https://appleid.apple.com/auth/authorize?client_id=xxxxx&redirect_uri=xxxxx&response_type=code%20id_token&scope=name%20email&response_mode=form_post"; });` The alternative code we´ve tried for which it seems that nothing happens, we only see the "Started" alert, we´ve confirmed that there is no other error : ` <script src="https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js"></script> <script> (function initAppleSignIn() { try { window.AppleID.auth.init({ clientId: "{{ env('APPLE_WEB_CLIENT_ID') }}", scope: "name email", redirectURI: window.location.origin +"/auth/apple/callback", usePopup: true }); } catch (e) { console.warn('Apple Sign-In init skipped:', e); } })(); function appleButtonClicked() { alert("Started"); try { const res = await window.AppleID.auth.signIn(); } catch (err) { alert("Got error"); } alert("Got here"); } </script>

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