Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2

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 }

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?

Create shortcut to open chrome with url and put it on the desktop. Tap the shortcut. Tap the username text field. When launching Safari from an iOS shortcut on an iOS device with a valid passkey registered, the passkey suggestion does not appear; instead, the password suggestion appears sometimes.

Starting in iOS 26 (tested on 26.1), when I use any of the “policy” methods of WKNavigationDelegate to return an action policy of cancel I get a trace like this printed to console: 1 0x18de71bbc WebKit::WebFramePolicyListenerProxy::ignore(WebKit::WasNavigationIntercepted) 2 0x18db3dd50 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)::$_0::operator()(WKNavigationActionPolicy, WKWebpagePreferences*) 3 0x100189e5c $sSo24WKNavigationActionPolicyVIeyBhy_ABIeghy_TR 4 0x100189d38 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctF 5 0x100189df4 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctFTo 6 0x18db255c0 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&) 7 0x18dea9848 WebKit::WebPageProxy::decidePolicyForNavigationAction(WTF::Ref<WebKit::WebProcessProxy, WTF::RawPtrTraits<WebKit::WebProcessProxy>, WTF::DefaultRefDerefTraits<WebKit::WebProcessProxy>>&&, WebKit::WebFrameProxy&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&) 8 0x18dea7a34 WebKit::WebPageProxy::decidePolicyForNavigationActionAsync(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&) 9 0x18d9cbbf4 void IPC::handleMessageAsync<Messages::WebPageProxy::DecidePolicyForNavigationActionAsync, IPC::Connection, WebKit::WebPageProxy, WebKit::WebPageProxy, void (IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)) 10 0x18d9c7728 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 11 0x18e49a0d8 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) 12 0x18df1908c WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&) 13 0x18d9dfc28 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 14 0x18e47f72c IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) 15 0x18e47fac4 IPC::Connection::dispatchIncomingMessages() 16 0x199ad3758 WTF::RunLoop::performWork() 17 0x199ad4eb0 WTF::RunLoop::performWork(void*) 18 0x1804563a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 19 0x1804562ec __CFRunLoopDoSource0 20 0x180455a78 __CFRunLoopDoSources0 21 0x180454c4c __CFRunLoopRun 22 0x18044fcec _CFRunLoopRunSpecificWithOptions 23 0x1926be9bc GSEventRunModal 24 0x18630f0d8 -[UIApplication _run] 25 0x186313300 UIApplicationMain 26 0x18554ac38 block_destroy_helper.15 27 0x10018a70c $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ 28 0x10018a67c $s16WebkitPolicyTrap11AppDelegateC5$mainyyFZ 29 0x10018a818 __debug_main_executable_dylib_entry_point 30 0x1000cd3d0 29 dyld 0x00000001000cd3d0 start_sim + 20 31 0x1002bab98 30 ??? 0x00000001002bab98 0x0 + 4297829272 This doesn’t happen in 18.6. Also, it doesn’t seem to have any negative consequences other than the console spam? But then, the navigation is being cancelled anyway, so maybe it’s trapping and just happens to have the effect of not loading the request? Anyway, I guess I can’t upload zips. But it’s pretty easy to reproduce. Just assign a WKWebView a navigationDelegate with an implementation like: func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping @MainActor (WKNavigationActionPolicy) -> Void) { decisionHandler(.cancel) } and then have it .load() anything. Have I been doing this wrong and 26 exposes it? Or is this a bug in 26? If the latter, any downstream consequences I should be looking out for? macOS 15.7.1 (24G231) Xcode 26.1.1 (17B100) iOS 26.1 (23B86)

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.

Hi, I have an app that uses WKWebView and it's crashing on iOS 26 Simulator in places I've never had problems before. In this case it's crashing when calling WKWebView.callAsyncJavaScript, but in my other project WKWebView is crashing with some sort of EXC_BAD_ACCESS other than callAsyncJavaScript. Am I missing something? Thanks,

I'm trying to sync authentication data from my iOS app to a Safari Web Extension using App Groups, but the extension isn't consistently receiving the data. Setup: App Group: group.com.airaai.AiraApp (configured in both app and extension) iOS app writes auth data using UserDefaults(suiteName: "group.com.airaai.AiraApp") Extension's Swift SafariWebExtensionHandler reads from App Groups in beginRequest() Extension's JavaScript reads from browser.storage.local Problem: Extension popup always shows "logged out" even when: User is logged into main iOS app Auth data exists in App Groups (verified via native module logs) Handler successfully writes test values to extension storage Current Behavior: Handler CAN read from App Groups ✅ Handler CAN write test values to extension storage ✅ But auth data doesn't appear in browser.storage.local when popup checks ❌ Popup reads empty keys even though handler logged writing them Code: // Handler reads from App Groups guard let sharedDefaults = UserDefaults(suiteName: "groupName") else { return } let authData = sharedDefaults.string(forKey: "auth_data") // Handler writes to extension storage (tried multiple suite names) let extensionDefaults = UserDefaults(suiteName: Bundle.main.bundleIdentifier ?? "") extensionDefaults?.set(authData, forKey: "oauth_token") extensionDefaults?.synchronize() // Popup reads from storage browser.storage.local.get(['oauth_token']).then(data => { console.log(data); // Always empty {} }); What I've tried: ✅ App Groups properly configured in both targets ✅ Extension has App Groups capability enabled ✅ Multiple UserDefaults suite names (bundle ID, bundle ID + suffix) ✅ Delayed sync attempts in handler ✅ Comprehensive logging Questions: What is the correct UserDefaults suite name for Safari extension storage on iOS? When does beginRequest() get called? Can it be triggered manually? Is App Groups the right approach, or should I use a different pattern? Alternatives I've considered: Deep link/redirect method (app opens Safari with token in URL) Content script intercepts URL and sends to background script Is this a supported approach for iOS Safari extensions? Any guidance or examples would be greatly appreciated!

I'm encountering an issue with front camera video recordings via browser (Safari/Chrome) on devices running iOS/iPadOS 18 and above: On iPad, the recorded video appears upside down. On iPhone, the recorded video is rotated 90 degrees. The rear camera functions correctly without orientation issues. This problem seems specific to browser-based recordings, as the native Camera app records videos with the correct orientation. Has anyone else experienced this behavior? Is there a known workaround or fix? The preview while recording is fine, the recorded video is oriented incorrectly.

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.

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?

iPadOS 26, dark mode Open Safari Search for anything or open a website that has white background Kill Safari Open Safari again I still can reproduce it with Safari on iPadOS 26.0.1 This issue also happens to my app when opening a HTML/JS on WKWebView with white background while using dark mode. I did send a feedback ticket when using iPadOS 26 beta but havent seen any reply. This is my first time sending a feedback so I dont know if Apple would reply or not.

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.

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.

Hi, this is my first post in the community, so please correct me if i am posting this somewhat in a wrong manner. Im using my Apple M1 Pro(14inch, 2021) and installed the os 26 yesterday. Today, I was using Safari, and all of sudden it gets frozen, then the following window popped up. Is this something expected? i.e. my usage is somewhat unusual or is there any report around potential memory leak in Safari? appreciate any suggestions, as Safari is my main browser and currently on hold due to this issue. Thanks

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

After updating to the new iOS, in Safari, my overlays and backdrops using 100dvh no longer cover the full screen there's now a gap at the bottom. Switching to 100vh fixes it, but that causes scrolling issues on older Safari versions since 100vh includes extra height. Has anyone else experienced this? What's the recommended fix that works across iOS versions?

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>

After updating to Safari 26.0 (on macOS Sequoia or Tahoe), the Declarative Net Request (DNR) API rule with "type": "redirect" no longer works as expected. When the rule is applied, the browser initially shows a banner at the top of the page: "This webpage was reloaded because a problem occurred." After the reload, the page fails to load and displays an error page with the message: "A problem repeatedly occurred with https://extensionworkshop.com/?test=true " This behavior is new in Safari 26.0. The same rule was working correctly in earlier Safari versions (17.x / 18.x).

I’m developing a Safari App Extension and I want to debug the background.js script. However, I can’t find any tool or option to do this. When I run the extension from Xcode using the ProjectName Extension (macOS) scheme, I expect to see a “ProjectName” item under the Develop → Web Extension Background Content menu. But there’s nothing there. Has anyone encountered the same issue? How did you fix it? Environment: Manifest Version: V3 Safari: 26.0.1 (21622.1.22.11.15) Xcode: 26.0.1 (17A400)