I'm using the new iOS 26 WebPage/WebView for SwiftUI in a NavigationStack. The initial load works as expected, but when loading items from the back/forward lists, the content jumps beneath the navigation bar: struct WebPageTestView: View { var webPage = WebPage() var body: some View { NavigationStack { WebView(webPage) .toolbar { Button("Back") { if let backItem = webPage.backForwardList.backList.last { webPage.load(backItem) } } Button("Forward") { if let forwardItem = webPage.backForwardList.forwardList.first { webPage.load(forwardItem) } } } } .task { webPage.isInspectable = true webPage.load(URL(string: "https://domchristie.co.uk/")) } } } I have run this on the iOS 26.0 and 26.1 Simulators and get the same issue. The demo website does not use any JavaScript. I was able to replicate this behaviour using a wrapped WKWebView and calling the .ignoresSafeArea(.all) modifier.

I'm developing an application that needs smooth framerates within a wkwebview that interacts with native code. However, requestAnimationFrame by default is still throttled to 60hz even if all my target devices (the iPad Pro for example) have supported 120hz for a long time already. I noticed that the latest Safari in 18.3 beta supports unlocked framerates, but that's only under Safari feature flags. To my knowledge, these flags do not apply to WKWebView. Is there a way to enable unlocked framerate in WKWebView via requestAnimationFrame? (Calling JS at a faster rate from the native code side will not work, almost definitely, since WKWebView will still render at its own rate.) This is an experimental application for internal use and I'm okay if there are temporary beta solutions available.

The app I work on uses WKWebView to render customer data. In iPadOS 26, we observe that there is a delay when resizing the window (and thus the web view) before the content is re-rendered. The same behavior is visible in Safari. For demonstration purposes, consider this test page: https://phet-dev.colorado.edu/html/build-an-atom/0.0.0-3/simple-text-only-test-page.html Initially, the window is small: Then when the window is expanded, the content scales up temporarily: It eventually re-renders to the correct size, but then if you make the window small again, you get (temporarily): Is there anyway around this behavior? We would love to have the content reflow interactively.

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

I’m experiencing an issue in WKWebView on iOS 26 Developer Beta 8. If a view's subview contains a WKWebView, using the CALayer's renderInContext method fails to capture the pixel at the current point, and the console outputs "unsupported surface format: &b38". The following code snippet was functioning as expected on iOS 18 and iOS 26 beta 1. However, it no longer works in the latest beta. Is this a known bug in the current iOS 26 betas, or is there a recommended workaround? - (BOOL)isTransparentAtTouchPoint:(CGPoint)point layer:(CALayer *)layer { unsigned char pixel[4] = {0}; CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB(); CGContextRef context = CGBitmapContextCreate(pixel, 1, 1, 8, 4, colorSpace, (CGBitmapInfo) kCGImageAlphaPremultipliedLast); CGContextTranslateCTM(context, -point.x, -point.y); [layer renderInContext:context]; CGContextRelease(context); CGColorSpaceRelease(colorSpace); CGFloat alpha = pixel[3] / 255.0f; return alpha < 0.01; }

Hey there. I recently completed an Apple Pay (on the web) integration and it has been working fine, for the most part. I had one customer contact us saying that it didn't work on his devices though. I checked it out, and while it does normally work (and we've had over a thousand transactions use it) there does seem to be some scenarios where it fails and I'm not sure why. I was able to replicate his issue (or at least an issue) by using BrowserStack. When I click the button which should initiate the payment, everything works in the JS code until it gets to the applePaySession.begin() function call. Once it hits that, it just stops. No errors are generated and no notice is given that anything is wrong until you try to do it a second time. Then an error about a payment session already being active on the page is thrown. I'm not really sure how to troubleshoot this since I know it works on my old iPad Air 2, my current M4 Macbook, multiple other devices, and also works when scanning the QR code for use on an iPhone. There is some very specific thing with some very specific versions of Safari that seem to be tripping it up. If it helps, the version of Safari on the BrowserStack device is 18.1, but the version on my Macbook is 18.1.1. The version the customer who is having the issue is on is 18.2 according to him. The customer also says they have used ApplePay on other websites with no issues. I checked one of them and they appear to be using a PayPal integration, where as I am using the ApplePay SDK straight from Apple. There are quite a few variables at play here, and I'm just trying to narrow down what I should be looking at. If one person is reporting the issue, there are probably others with it as well.

Since iPadOS 18.x WKWebView seems to have a bug within its Fullscreen API (which can be enabled via WKPreferences.isElementFullscreenEnabled). This bug has the effect that websites trying to make an element (for example a video player) fullscreen fail to do so. This does not always happen, most of the time the fullscreen mode does work fine, but sometimes (far too often to be ignored) it does not. If an instance of WKWebView shows this issue, it can not be "fixed" by reloading the page or loading other pages, this issue exists in this instance forever. My App is a web browser App so I can create and remove WKWebView instance easily (by opening or closing Tabs). And there are times where I never see this bug, and times where ever other tab shows this bug. It's totally unreliable. The App does not show any issues at all when running under iPadOS 17 or older. The issue is only present under iPadOS 18.x. After some testing I've found out that when the bug has affected an instance of WKWebView, the JavaScript call element.requestFullscreen() will work if the element is a video element, but does no longer work if it is another element (like a DIV). If an instance of WKWebView is not affected by this bug, element.requestFullscreen() will work for all HTML elements. Does anyone has experienced this bug as well? And maybe found a workaround? Or maybe found a pattern which helps to find out what exactly is triggering this bug?

When I open the browser in Safari on iOS 26, I want to specify the background color for the header notch (where the time, battery, etc. are displayed) and the footer indicator area. Specifying the theme color in HTML as shown below did not change anything. <meta name="theme-color" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000"> The HTML below specifies the background color as green, but is it necessary to specify the background color directly in the body like this? Or is there some kind of metadata, like theme color? <!doctype html> <html lang="ja"> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width,initial-scale=1" /> <meta name="theme-color" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000"> <title>サンプル</title> </head> <body style="background:#00ff00"> <main> <p>テキスト</p> </main> <div id="overlay" role="dialog" aria-modal="true" data-test-id="health-warning-modal" style=" color:#000000; position:fixed; inset:0; z-index:30000; background:#2563eb; display:grid; /* 初期表示：表示中 */ align-items:center; justify-content:center; overflow-y:auto; " > <div style=" padding:60px 16px; display:flex; flex-direction:column; gap:20px; width:100%; box-sizing:border-box; " > <p style=" font-weight:700; text-align:center; margin-top:20px; font-size:28px; line-height:1.4; " > オーバーレイ </p> </div> </div> </body> </html>

We are encountering an issue where the Safari extension we are developing stops working while in use on relatively new iOS versions (confirmed on 17.5.1, 17.6.1, and 18). Upon checking the Safari console, the content script is displayed in the extension script, so the background script or Service Worker must be stopping. The time until it stops is about 1 minute on 17.5.1 and about one day on 17.6.1 or 18. When it stops, we would like to find a way to restart the Service Worker from the extension side, but we have not found a method to do so yet. To restart the extension, the user needs to turn off the corresponding extension in the iPhone settings and then turn it back on. As mentioned in the following thread, it is written that the above bug was fixed in 17.6, but we recognize that it has not been fixed. https://forums.developer.apple.com/forums/thread/758346 On 17.5.1, adding the following process to the background script prevents it from stopping for about the same time as on 17.6 and above. // Will be passed into runtime.onConnect for processes that are listening for the connection event const INTERNAL_STAYALIVE_PORT = "port.connect"; // Try wake up every 9S const INTERVAL_WAKE_UP = 9000; // Alive port var alivePort = null; // Call the function at SW(service worker) start StayAlive(); async function StayAlive() { var wakeup = setInterval(() => { if (alivePort == null) { alivePort = browser.runtime.connect({ name: INTERNAL_STAYALIVE_PORT }); alivePort.onDisconnect.addListener((p) => { alivePort = null; }); } if (alivePort) { alivePort.postMessage({ content: "ping" }); } }, INTERVAL_WAKE_UP); } Additionally, we considered methods to revive the Service Worker when it stops, which are listed below. None of the methods listed below resolved the issue. ① Implemented a process to create a connection again if the return value of sendMessage is null. The determination of whether the Service Worker has stopped is made by sending a message from the content script to the background script and checking whether the message return value is null as follows. sendMessageToBackground.js let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { // If infoFromBackground is null, Service Worker should have stopped. browser.runtime.connect({name: 'reconnect'}); // ← reconnection process // Sending message again infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; Background script browser.runtime.onConnect.addListener((port) => { if (port.name !== 'reconnect') return; port.onMessage.addListener(async (request, sender, sendResponse) => { sendResponse({ response: "response form background", message: "reconnect.", }); }); ② Verified whether the service worker could be restarted by regenerating Background.js and content.js. sendMessageToBackground.js export async function sendMessageToBackground(sendParam) { let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { executeContentScript(); // ← executeScript infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; } async function executeContentScript() { browser.webNavigation.onDOMContentLoaded.addListener((details) => { browser.scripting.executeScript({ target: { tabId: details.tabId }, files: ["./content.js"] }); }); } However, browser.webNavigation.onDOMContentLoaded.addListener was not executed due to the following error. @webkit-masked-url://hidden/:2:58295 @webkit-masked-url://hidden/:2:58539 @webkit-masked-url://hidden/:2:58539 ③ Verify that ServiceWorker restarts by updating ContentScripts async function updateContentScripts() { try { const scripts = await browser.scripting.getRegisteredContentScripts(); const scriptIds = scripts.map(script => script.id); await browser.scripting.updateContentScripts(scriptIds);//update content } catch (e) { await errorLogger(e.stack); } } However, scripting.getRegisteredContentScripts was not executed due to the same error as in 2. @webkit-masked-url://hidden/:2:58359 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58549 @webkit-masked-url://hidden/:2:58549 These are the methods we have considered. If anyone knows a solution, please let us know.

When attempting to authorize an Apple Payment on an iOS 18 device using the scannable code in a non-Safari browser (i.e. Chrome), the payment sheet displays briefly, then dismisses. This same exact implementation of Apple Pay on the Web works flawlessly in Safari, so this feels like a bug given that the merchant session works fine in Safari. The following errors were found in my iOS device logs: (PassbookUIService) Codable: Failed to decode Merchant Session Created: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=<private>, NSCodingPath=<private>} (PassbookUIService) Session 29592: Fatal Error: Failed to decode merchant session created`

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

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 have a Net8 Maui WebView app and whenever I use magnifier, it crashes. The magnifier works on iOS18 and lower but crashes on iOS26+ Exception **Type:** CALayerInvalidGeometry **Value:** CALayer position contains NaN: [nan 65]. Layer: <CALayer:0x123e88e40; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x116f2f200; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x123e88e40>>; sublayers = (<CALayer: 0x125232df0>, <CALayer: 0x123e88e70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0> Stacktrace __exceptionPreprocess in unknown file [Line null, column null] (Not in app) objc_exception_throw in unknown file [Line null, column null] (Not in app) +[NSException raise:format:] in unknown file [Line null, column null] (Not in app) CA::Layer::set_position in unknown file [Line null, column null] (Not in app) -[CALayer setPosition:] in unknown file [Line null, column null] (Not in app) -[UIView _backing_setPosition:] in unknown file [Line null, column null] (Not in app) -[UIView setCenter:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] in unknown file [Line null, column null] (Not in app) __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke in unknown file [Line null, column null] (Not in app) -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation _displayMenu:reason:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation displayMenu:configuration:] in unknown file [Line null, column null] (Not in app) __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke in unknown file [Line null, column null] (Not in app) __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app) __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app) __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)

Hi, Our company has an application uses the WKWebview to host a lot of content. The content is web based and hosts a lot of charts and metrics. Because of the high content, we've seen the memory of the WebContent hit above 1.25 GB. When that happens, it'll eventually terminate and we have our recovery code to reload the same page Seems like the limit is hidden / internal. Some Apple devs also noted something might be hard coded to be limited as well. Yes, we have our optimizations but we still need to keep our queries, use react, cache, etc... It's just a heavy web application. Request: Can you help us raise that limit? Are there some limitations in Webkit for such a need to terminate? As some devices have much higher RAM than before, we were hoping to be able to dynamically adjust the limit for the wkwebview before it resets. We contacted our internal contacts but they said to post here.

I want to print the content of a WKWebView. I've done some searching, and many people have struggled with this over the years. Some claimed success, but their solutions don't work for me. One person created images for each pages and printed that, but then if you were to print to PDF, you'd get a PDF containing images rather than text. If I just call the printView(_:)) method of the view, I get blank pages. With the following more elaborate code, I get a partial printout, 11 out of what should be about 13 pages. let info = NSPrintInfo.shared info.topMargin = 72.0; info.bottomMargin = 72.0; info.leftMargin = 72.0; info.rightMargin = 72.0; info.isVerticallyCentered = false; info.isHorizontallyCentered = false; info.horizontalPagination = .fit; info.verticalPagination = .automatic; let printOp = webView!.printOperation( with: info ) printOp.canSpawnSeparateThread = true printOp.view?.frame = NSMakeRect( 0, 0, info.paperSize.width, info.paperSize.height ) printOp.runModal(for: webView.window!, delegate: self, didRun: nil, contextInfo: nil ) When I run the above under the debugger, I see console messages saying CGContextClipToRect: invalid context 0x0. Once the print dialog appears, if I touch (but not change) the selected printer, then the page count changes to the correct value.

I'm working on a Safari web extension that uses the nativeMessaging facility to communication with native code. When I want to notify the javascript extension from the embedding application, I use SFSafariApplication::dispatchMessage. As per the documentation, this call ... ensures that Safari is launched and that your extension is running before delivering the message. Everything works fine when the background script is running. However, after the background script gets unloaded at some point in time (non persistent background page, default behavior for a manifest V3 extension), the background script is not reloaded by the message from the native app (background script still appears unloaded in the developer menu of Safari, double-checked using a counter stored in browser.storage.local incremented on message reception). In this case, the completion handler of the application gets no error (error == nil) as if the message was correctly delivered. I was able to reproduce this behavior with the sample app delivered for WWDC20 (after upgrading the manifest from v2 to v3 to make it non-persistent). Is it supposed to work ? What I'm doing wrong ?

Hello, my application experiences crashes related to JavaScriptCore in iOS 17 and 18. I would like to consult about potential causes, to determine whether it is a bug in JavaScriptCore or an issue with my code implementation. First, the crash stack always includes the call to JSC::MarkedBlock::aboutToMarkSlow(unsigned int). In the iOS 17 version, the crash occurs on this line, typically JSC::MarkedBlock::aboutToMarkSlow(unsigned int) + 88. In iOS 18 and later, the stack crashes atJSC::MarkedBlock::dumpInfoAndCrashForInvalidHandle(WTF::AbstractLocker&, JSC::HeapCell*). I checked the source code of JavaScriptCore for both iOS 17.6 and iOS 18.2 and observed modifications in the implementation of aboutToMarkSlow. My question is under what circumstances could this crash occur? crash.log I have attached a crash log encountered in iOS 18, hoping you can provide more effective information for problem diagnosis, especially since there are specific details worth noting near the crash registers. INVALID HANDLE: MarkedBlock = 0x141158000; heapCell = 0x14115bfa0; type = 0 INVALID HANDLE: found 24 0s at beginning of block INVALID HANDLE: block in another VM: 1, block in another VM: 1; other VM is 0x1324b6000 Moreover, in iOS 18.4, due to the implementation of dumpInfoAndCrashForInvalidHandleV2, the message has changed to: INVALID HANDLE 587: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=0; totalzeros=0; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0; INVALID HANDLE 606: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0; INVALID HANDLE 615: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0; isBlockVMValid=0; isBlockInSet=1; isBlockInDir=1; foundInBlockVM=0; (Further INVALID HANDLE messages follow the same format) I hope this provides you with more information.

How can I make a background image take the entire screen in ios26? I've tried position fixed, sticky, env() css variables but nothing worked. It does it when in PWA mode, but I would like to do so in the browser too.

We are building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Communication between the Angular UI and native Swift code is done using WKScriptMessageHandler. The app mostly works without issues, but in rare edge cases, we’re seeing crashes on the main thread, and the crash is reported in Firebase Crashlytics. The root cause appears related to CFRelease and WKScriptMessageHandler. Here’s the relevant crash stack: Crashed: com.apple.main-thread 0 CoreFoundation 0xbfac CFRelease + 44 1 CoreFoundation 0xa734 __CFURLDeallocate + 128 2 CoreFoundation 0x730c _CFRelease + 292 3 libobjc.A.dylib 0x4e28 AutoreleasePoolPage::releaseUntil(objc_object**) + 204 4 libobjc.A.dylib 0x4cbc objc_autoreleasePoolPop + 260 5 WebKit 0x99f194 WebKit::WebUserContentControllerProxy::didPostMessage(WTF::ObjectIdentifierGeneric<WebKit::WebPageProxyIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, WebKit::FrameInfoData&&, WTF::ObjectIdentifierGeneric<WebKit::ScriptMessageHandlerIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::CompletionHandler<void (std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::String const&)>&&) + 680 6 WebKit 0x1b358 WebKit::WebUserContentControllerProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 392 7 WebKit 0xe86b0 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 8 WebKit 0x23c0c WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 9 WebKit 0xe3f054 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 252 10 WebKit 0x332d4 IPC::Connection::dispatchIncomingMessages() + 744 11 JavaScriptCore 0x58a7c WTF::RunLoop::performWork() + 204 12 JavaScriptCore 0x599a4 WTF::RunLoop::performWork(void*) + 36 13 CoreFoundation 0x56328 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 14 CoreFoundation 0x562bc __CFRunLoopDoSource0 + 176 15 CoreFoundation 0x53dc0 __CFRunLoopDoSources0 + 244 16 CoreFoundation 0x52fbc __CFRunLoopRun + 840 17 CoreFoundation 0x52830 CFRunLoopRunSpecific + 588 18 GraphicsServices 0x11c4 GSEventRunModal + 164 19 UIKitCore 0x3d2eb0 -[UIApplication _run] + 816 20 UIKitCore 0x4815b4 UIApplicationMain + 340 21 APP1 0xa2f80 main + 21 (AppDelegate.swift:21) 22 ??? 0x1c234eec8 (シンボルが不足しています) Steps: WebView: WKWebView Message passing: WKScriptMessageHandler → passing data from Angular → Swift WKWebView is long-lived and reused Native is using WKUserContentController.add(_:name:) to register handlers Crashes are intermittent (hard to reproduce), but often follow: Screen sleep/wake Push notification open Angular calling native immediately after resume Questions: Has anyone seen this specific crash pattern involving CFRelease and WKScriptMessageHandler? Are there known WebKit or CoreFoundation bugs related to WKScriptMessageHandler and retained URLs or message content? Thank you for your help!

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?