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,

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)

myCode is here // titleScript = "document.querySelector('#\(rawValue) span')?.textContent" guard let titleResult = try? await webView.evaluateJavaScript(type.titleScript), let title = titleResult as? String else { return } this code has error Thread 1: Swift runtime failure: Unexpectedly found nil while implicitly unwrapping an Optional value but edit Code like this It is works Successful do { ... let titleResult = try await webView.evaluateJavaScript(type.titleScript) let title = titleResult as? String ... } catch { LogManager.log(level: .error, self, #function, error, "title is Invalid : \(type.titleScript)") continue } I don't know why guard let _ = try? is Fail

I am encountering an issue where we are unable to run or launch Safari Driver in our automation tests using macOS. When attempting to run safaridriver -p 8888 from the terminal, we receive the following error message: ERROR: safaridriver could not launch because it is not configured correctly or you need to authenticate. Re-run safaridriver(1) and pass the '--enable' flag to configure and/or authenticate. For more information, consult the safaridriver(1) man page. Despite running sudo safaridriver --enable as an administrator (even as root), the issue persists. I’ve searched through various online forums and GitHub repositories but couldn’t find a working solution. Some references are: Apple Developer Forum Thread: https://forums.developer.apple.com/forums/thread/762321 GitHub Issue: https://github.com/SeleniumHQ/selenium/issues/11381

On iOS 26 Beta, WKWebView consistently crashes when interacting with pages that use -webkit-user-select: none. This issue does not reproduce in Safari, but only when the same content is loaded inside a WKWebView. Steps to Reproduce: Install iOS 26 Beta. Open a WKWebView that loads a webpage with the following style applied globally: -webkit-user-select: none; Perform the following gesture sequence inside the WKWebView: Double tap anywhere in the web content. On the second tap, keep your finger pressed (do not lift). While still holding the second tap, drag your finger across the screen (pan). This sequence reliably produces the crash. Expected Result: No crash. The gesture should either be ignored or handled gracefully. Actual Result: The app crashes 100% of the time with the following exception: #0 0x000000013f1a0874 in __pthread_kill () #1 0x00000001357522ec in pthread_kill () #2 0x00000001801ad950 in abort () #3 0x00000001802fa26c in __abort_message () #4 0x00000001802ea1a4 in demangling_terminate_handler () #5 0x0000000180077218 in _objc_terminate () #6 0x00000001802f9758 in std::__terminate () #7 0x00000001802fc7c0 in __cxxabiv1::failed_throw () #8 0x00000001802fc7a0 in __cxa_throw () #9 0x000000018009c1bc in objc_exception_throw () #10 0x00000001804f38f8 in +[NSException raise:format:] () #11 0x000000018c5fb570 in -[CALayer setPosition:] () #12 0x0000000185d02414 in -[UIView _backing_setPosition:] () #13 0x00000001867ec978 in -[UIView setCenter:] () #14 0x0000000186666468 in -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] () #15 0x0000000186666088 in __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke () #16 0x00000001867b3ed4 in -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] () #17 0x0000000186665fb0 in -[_UIEditMenuContentPresentation _displayMenu:reason:] () #18 0x0000000186665de4 in -[_UIEditMenuContentPresentation displayMenu:configuration:] () #19 0x00000001867b3260 in __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke () #20 0x00000001867b4c98 in __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke () #21 0x000000018653ff80 in __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke () #22 0x0000000186540448 in __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke () #23 0x000000018dba84f8 in WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call () #24 0x000000018dca14cc in WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call () #25 0x000000018e2d5c54 in IPC::Connection::dispatchMessage () #26 0x000000018e2d6118 in IPC::Connection::dispatchIncomingMessages () #27 0x00000001997f9c58 in WTF::RunLoop::performWork () #28 0x00000001997fa930 in WTF::RunLoop::performWork () #29 0x000000018044d4dc in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #30 0x000000018044d424 in __CFRunLoopDoSource0 () #31 0x000000018044cc0c in __CFRunLoopDoSources0 () #32 0x000000018044bd84 in __CFRunLoopRun () #33 0x0000000180446e24 in _CFRunLoopRunSpecificWithOptions () #34 0x00000001924c19bc in GSEventRunModal () #35 0x00000001862217a8 in -[UIApplication _run] () #36 0x00000001862259d0 in UIApplicationMain () Same issues below. https://developer.apple.com/forums/thread/796799 https://developer.apple.com/forums/thread/796501 https://developer.apple.com/forums/thread/796874 https://developer.apple.com/forums/thread/796686

On iOS 18, when setting the src attribute of an tag to a custom scheme (e.g., myapp://image.png) or an HTTP URL (http://example.com/image.png), if crossorigin="anonymous" is applied, the image fails to load. Additionally, images affected by this issue cannot be drawn to a , as the browser treats them as tainted and blocks access to their pixel data. This issue did not occur in previous iOS versions and seems to be a regression in iOS 18. Steps to Reproduce: Open an HTTPS-hosted H5 page in Safari on iOS 18. Add an tag with crossorigin="anonymous" and set src to either: A custom scheme: <img src="myapp://image.png" crossorigin="anonymous"> An HTTP URL (even from the same origin): <img src="http://example.com/image.png" crossorigin="anonymous"> Observe that the image does not load. Attempt to draw the image onto a and retrieve its data: const canvas = document.createElement("canvas"); const ctx = canvas.getContext("2d"); const img = new Image(); img.crossOrigin = "anonymous"; img.src = "http://example.com/image.png"; // or "myapp://image.png" img.onload = () => { ctx.drawImage(img, 0, 0); try { console.log(canvas.toDataURL()); // Expect base64 image data } catch (error) { console.error("Canvas is tainted:", error); } }; Notice that the image is blocked, and any attempt to access pixel data results in a CORS error. Expected Behavior: * The image should be displayed if it is accessible under normal CORS rules. * The API should allow access to the image data unless explicitly blocked by the server’s CORS policy. Actual Behavior: The image fails to load when crossorigin="anonymous" is applied. The API does not allow access to the image data, treating it as tainted. Removing crossorigin="anonymous" allows the image to display in some cases, but this is not a viable workaround when CORS enforcement is required. Regression: Works correctly on: iOS 17 and earlier Broken on: iOS 18 Environment: Device: iPhone/iPad iOS Version: 18.0+ Browser: Safari Suggested Fix: Apple should investigate this regression and allow custom schemes and HTTP images to be correctly handled under CORS policies when crossorigin="anonymous" is set. If the source allows cross-origin requests, Safari should not block the image or its use in .

I am currently operating an app using an embedded web server that communicates over local HTTP. Recently, when opening Safari, I started encountering the following error message: "Safari cannot open the page. Error: Failed to navigate to an HTTP URL with HTTPS-only mode enabled." However, I am currently in a situation where switching to HTTPS is difficult. Are there any solutions to resolve this issue besides using HTTPS? Thank you.🙏

On my native app, will open a wkWebview to display some content. And it will crash on iOS26: *** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan 103.667]. Layer: <CALayer:0x14c2457d0; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x14c273980; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x14c2457d0>>; sublayers = (<CALayer: 0x1306320a0>, <CALayer: 0x14c245a70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>'

I am working in React Native and trying to use Deeplink. When app is installed code is working fine but when app is not installed not redirecting to App Store in Safari instead of that in Chrome that is working fine in safari when i click i got this error message "safari cannot open the page because the address is invalid" this is my apple-app-site-association file code { "applinks": { "apps": [], "details": [ { "appID": "CS666P223.com.seecard", "paths": [ "", "/recover/", "/settings/*" ] } ] } , "webcredentials": { "apps": [ "CS666P223.com.seecard" ] } } and this is my code in next "use client" export default function Home() { // Helper function for device detection // const isiOS = () => /iPhone|iPad|iPod/i.test(navigator.userAgent); const isAndroid = () => /Android/i.test(navigator.userAgent); const isiOS = () => { const userAgent = navigator.userAgent || navigator.vendor; return ( /iPhone|iPad|iPod/.test(userAgent) || (navigator.platform === "MacIntel" && navigator.maxTouchPoints > 1) ); }; const openAndSaveCard = () => { try { // let fallbackLink = ''; if (isiOS() || isAndroid()) { const card_id = "3434bee9675ee44b3dc65"; const card_owner_id = "34349675ee44b3dc43"; const card_for_saved = { "cardId": card_id, "ownerId": card_owner_id }; console.log("=-=-card_for_saved",card_for_saved) const encodedData = encodeURIComponent(JSON.stringify(card_for_saved)); window.location.href = `saveseecard://open?id=${encodedData}`; const androidAppStoreLink = 'https://play.google.com/store/apps/details?id=com.seecard'; const iosAppStoreLink = 'https://apps.apple.com/np/app/seecard/id6502513661'; fallbackLink = isAndroid() ? androidAppStoreLink : iosAppStoreLink; const timeout = setTimeout(function () { if (document.hasFocus()) { window.location.href = fallbackLink; } }, 2000); window.addEventListener('blur', () => { clearTimeout(timeout);; }); } else { alert("Your device doesn't support deep linking for this app."); } } catch (e) { console.log("Error:", e); } }; return ( <div className="cIcon ml-10 purpleBg" // onClick={() => { openAndSaveCard() }} onClick={openAndSaveCard} > <p className="container-text">Save Card</p> </div> </main> </div> ); }

After upgrading to Safari version 18, we encountered an issue with my extension’s background script not being able to access cookies. Previously, in Safari versions 17 and below, the extension worked as expected. Now, when the extension tries to retrieve cookies using browser.cookies.getAll(), it returns an empty list. However, if we open the extension’s developer tools, the cookies are visible and accessible. It seems that Safari only provides cookie data after the developer tools have been opened. However, after relaunching Safari and launching the extension without opening the developer tools, browser.cookies.getAll() still returns an empty list. Has anyone else experienced this? STEPS TO REPRODUCE Download this minimal app : https://www.icloud.com/iclouddrive/0bajlhnuQaG6T5NsFKXEB0U9Q#test%5Fcookies Compile test_mv2 extension (in test_cookies.getAll.zip). Launch test_mv2.app and activate extension. Click on the extension's button (browserAction). Open the developer tools. Observe an empty list of cookies. Click on the extension's button (browserAction). Cookies are retrieved as expected.

Test Scenario: Initial Setup: Register a passkey on Chrome (MacBook) with cross-platform option The passkey syncs to iPhone via iCloud Both devices share same iCloud account Authentication Tests: Chrome on MacBook: Using hybrid transport (QR code with iPhone) → PRF output A Using platform authenticator → PRF output B (different) Safari on MacBook: Only uses platform authenticator → PRF output B Expected Behavior: When using same credential ID and salt, PRF output should be consistent across browsers/devices

Sometimes Safari is rendering the icon for an active extension in its original provided colored representation, other times Safari is applying an overlay color in line with the system's highlight color. This difference can even be seen seen on the Safari Extensions Developer home page: https://developer.apple.com/safari/extensions/images/extensions-hero-large_2x.png You will notice that Grammarly's icon is shown in it's original color format, while the others aren't. Example of extensions where the icon is shown in color: Bitwarden Grammarly 1Password Consent-O-Matic I've compared the source code of Bitwarden and Consent-o-Matic with my own extension and cannot find any differences in the settings or image properties (resolution, DPI, file type, color profile). If I take the exact PNG source files from said open source extensions and replace them in my own source code, these icons show up in full color. Does this perhaps mean there is a bug in Safari's processing of the icons where it fails to overlay the icon with the highlight color in some cases? I and I assume many developers with me would like to understand what determines this difference. Ideally, there is a consistent UX where the end user has the choice between icons in color or highlight color overlay.

Hello WebKit Team, I’m writing to ask if iOS provides a native way to intercept AJAX (XMLHttpRequest or fetch) calls inside WKWebView. On Android, this is handled via: shouldInterceptRequest(WebView view, WebResourceRequest request) but iOS currently seems to have no equivalent. We’ve tried: WKURLSchemeHandler → works only for custom schemes URLProtocol with WKProcessPool → unreliable for AJAX in WebView JavaScript injection → partial and unofficial Could you please clarify: Is there a recommended native approach to intercept AJAX requests? If not supported, is it planned for future releases? Any official workaround or guidance? This is critical for debugging, analytics, and compliance in hybrid apps.

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. As of macOS 15.4 / Safari 18.4 the tab OnAttached and tab onDetached events are no longer received. After some testing we verified that the events were working properly as of macOS 15.3 / Safari 18.3 but appear to have been broken in macOS 15.4. Note a similar issue was reported previously for Safari 17.6 and was fixed in macOS 15.0 (FB14324177). We have made a TestFlight version of our app (Tabby) available to simplify debugging via https://testflight.apple.com/join/Va8Zdv9d. To reproduce the issue: Install the Tabby TestFlight build on macOS 15.4 or 15.4.1 Open Safari, go to Safari settings and select the Extensions tab Enable the Tabby extension and grant permissions to all windows all the time Open a Safari window with at least 3 tabs Note the open window and tabs displayed in Tabby In Safari, perform a tab detach by dragging a tab out of the window Expected behavior Within Safari the detached tab should now be in it’s own window, and via the onDetached event Tabby should update to show the tab in it’s own window AND removed from the original window. Observed Safari fails to send the onDetached event and Tabby will continue to display the detached tab in its original window in addition to the new window. You can also use the repro steps above to observe the onDetached event being received or not by Tabby in the Safari developer console. The same steps but re-attaching the tab to the original window can be used to observe the onAttached event being received or not. We’ve attached two screen recordings to the Feedback ID below, one showing the events working on macOS 15.3, and one showing the events failing to be received on macOS 15.4.1. Note it also fails on macOS 15.4. FEEDBACK ID: FB17367977

I'm building a macOS extension that needs to track multi-step navigation chains (A → B → C) to adjust behavior based on where users came from. Current approach: Using webNavigation.onBeforeNavigate to detect intermediate steps, but experiencing issues in Safari that don't occur on Chrome/Firefox/Edge. Questions: Is webNavigation the right API for tracking redirect chains in Safari? Does ITP/Private Browsing affect event delivery? Any alternative approaches recommended? (Safari version 26.0.1) Any guidance appreciated!

I have a Safari Web Extension that successfully receives a message from a webpage and returns a response. I now want to add a user interface to the Safari Web Extension. How do I do this? I have modified the default template code as follow to add an NSAlert for testing. The modal runs, but no alert ever appears, and the code remains stuck at runModal. What is the correct way to add a UI to a webextension? - (void)beginRequestWithExtensionContext:(NSExtensionContext *)context {     id message = [context.inputItems.firstObject userInfo][SFExtensionMessageKey];     NSLog(@"Received message from browser.runtime.sendNativeMessage: %@", message);     NSAlert* alert = [[NSAlert alloc]init];     [alert setMessageText:message[@"request"]];     [alert setInformativeText:@"Hello"];     [alert runModal];     NSExtensionItem *response = [[NSExtensionItem alloc] init];     response.userInfo = @{ SFExtensionMessageKey: @{ @"id": message[@"id"], @"uuid": message[@"uuid"], @"contentType": message[@"contentType"], @"response": message[@"request"] } };     [context completeRequestReturningItems:@[ response ] completionHandler:nil]; } @end

After the iOS 18.2 update, I can no longer see the some website as I could see it on the desktop. ( for example Jeostok . Com)I have tried this in many browsers. For example, I get the same result in browsers such as Safari Chrome Firefox opera and edge. The home page is not displayed properly. It was displaying properly before the update and now it is not displaying properly. This website is my website. I frankly do not know how to solve this problem, if anyone knows, I am waiting for your help.

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

Background On iOS 18.4 beta, setting a content inset on a WKWebView causes touch events inside the web view to be offset by the content inset amount. In other words, if the web view has a top content inset of 75 points, I must tap 75 points above the intended element for the touch to register correctly. This makes any web content unusable when a content inset is present. A sample app demonstrating the issue is available here: GitHub - iOS18.4-Webview-Bug. The issue does not occur in iOS 18.3 or 18.2. Bug Report The bug has been reported and fixed at WebKit Bug 289715 and also filed as rdar://147075945. Question Will the fix be included in the upcoming iOS 18.4 beta release (Beta 5) or soon thereafter?

Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content. The EPUB content format is XHTML and uses namespaces (for the epub:type declaration). On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace: 0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968 1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940 2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984 3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708 4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636 5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304 6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268 7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488 8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52 9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228 10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268 I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html> I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not. It happens on iOS, macOS, and iPadOS. This has never been a problem in any earlier release of macOS / iOS.