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

Crash Stack: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x19ba3bb04) frame #0: 0x000000019ba3bb04 CoreFoundation`forwarding.cold.2 + 92 frame #1: 0x000000019b8ab718 CoreFoundation`forwarding + 1288 frame #2: 0x000000019b8ab150 CoreFoundation`_CF_forwarding_prep_0 + 96 frame #3: 0x000000019df230b0 CoreText`TCFRef<CTRun*>::Retain(void const*) + 40 frame #4: 0x000000019e052050 CoreText`CreateFontWithFontURL(__CFURL const*, __CFString const*, __CFString const*) + 476 frame #5: 0x000000019e052874 CoreText`TCGFontCache::CopyFont(__CFURL const*, __CFString const*, __CFString const*) + 144 frame #6: 0x000000019df27dcc CoreText`TBaseFont::CopyNativeFont() const + 232 frame #7: 0x000000019df8ee64 CoreText`TBaseFont::GetInitializedGraphicsFont() const + 152 frame #8: 0x000000019df26d70 CoreText`TBaseFont::CopyVariationAxes() const + 296 frame #9: 0x000000019df2d148 CoreText`TDescriptor::InitBaseFont(unsigned long, double) + 768 frame #10: 0x000000019df21358 CoreText`TDescriptor::CreateMatchingDescriptor(__CFSet const*, double, unsigned long) const + 604 frame #11: 0x000000019df251f8 CoreText`CTFontCreateWithFontDescriptor + 68 frame #12: 0x00000001bff8dfb8 WebCore`WebCore::createCTFont(__CFDictionary const*, float, unsigned int, __CFString const*, __CFString const*) + 124 frame #13: 0x00000001bff8e8bc WebCore`WebCore::FontPlatformData::fromIPCData(float, WebCore::FontOrientation&&, WebCore::FontWidthVariant&&, WebCore::TextRenderingMode&&, bool, bool, std::__1::variant<WebCore::FontPlatformSerializedData, WebCore::FontPlatformSerializedCreationData>&&) + 228 frame #14: 0x00000001c128eef4 WebKit`IPC::ArgumentCoder<WebCore::Font, void>::decode(IPC::Decoder&) + 1352 frame #15: 0x00000001c1333ca4 WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::ArgumentCoder<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>, void>::decodeIPC::Decoder(IPC::Decoder&) + 480 frame #16: 0x00000001c1333a5c WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::Decoder::decode<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>() + 28 frame #17: 0x00000001c1333804 WebKit`std::__1::optional<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>> IPC::Decoder::decode<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>>() + 156 frame #18: 0x00000001c121f368 WebKit`IPC::ArgumentCoder<WebCore::AttributedString, void>::decode(IPC::Decoder&) + 172 frame #19: 0x00000001c121f124 WebKit`std::__1::optionalWebCore::AttributedString IPC::Decoder::decodeWebCore::AttributedString() + 28 frame #20: 0x00000001c12594ec WebKit`IPC::ArgumentCoder<WebCore::DictionaryPopupInfo, void>::decode(IPC::Decoder&) + 76 frame #21: 0x00000001c12d0660 WebKit`std::__1::optionalWebCore::DictionaryPopupInfo IPC::Decoder::decodeWebCore::DictionaryPopupInfo() + 28 frame #22: 0x00000001c12ceef0 WebKit`IPC::ArgumentCoder<WebKit::WebHitTestResultData, void>::decode(IPC::Decoder&) + 1292 frame #23: 0x00000001c1338950 WebKit`std::__1::optionalWebKit::WebHitTestResultData IPC::Decoder::decodeWebKit::WebHitTestResultData() + 28 frame #24: 0x00000001c1ec7edc WebKit`WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 31392 frame #25: 0x00000001c1fb8f28 WebKit`IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 frame #26: 0x00000001c19ab2c0 WebKit`WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 frame #27: 0x00000001c1fb3254 WebKit`IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) + 252 frame #28: 0x00000001c1fb3768 WebKit`IPC::Connection::dispatchIncomingMessages() + 576 frame #29: 0x00000001b9ab90c4 JavaScriptCore`WTF::RunLoop::performWork() + 204 frame #30: 0x00000001b9ab9fec JavaScriptCore`WTF::RunLoop::performWork(void*) + 36 frame #31: 0x000000019b8cc8a4 CoreFoundation`CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #32: 0x000000019b8cc838 CoreFoundation`__CFRunLoopDoSource0 + 176 frame #33: 0x000000019b8cc59c CoreFoundation`__CFRunLoopDoSources0 + 244 frame #34: 0x000000019b8cb138 CoreFoundation`__CFRunLoopRun + 840 frame #35: 0x000000019b8ca734 CoreFoundation`CFRunLoopRunSpecific + 588 frame #36: 0x00000001a6e39530 HIToolbox`RunCurrentEventLoopInMode + 292 frame #37: 0x00000001a6e3f348 HIToolbox`ReceiveNextEventCommon + 676 frame #38: 0x00000001a6e3f508 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #39: 0x000000019f442848 AppKit`_DPSNextEvent + 660 frame #40: 0x000000019fda8c24 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 frame #41: 0x000000019f435874 AppKit`-[NSApplication run] + 480 frame #42: 0x000000019f40c068 AppKit`NSApplicationMain + 888 frame #43: 0x00000001ca56a70c SwiftUI`merged generic specialization <SwiftUI.TestingAppDelegate> of function signature specialization <Arg[0] = Existential To Protocol Constrained Generic> of SwiftUI.runApp(__C.NSResponder & __C.NSApplicationDelegate) -> Swift.Never + 160 frame #44: 0x00000001ca9e09a0 SwiftUI`SwiftUI.runApp<τ_0_0 where τ_0_0: SwiftUI.App>(τ_0_0) -> Swift.Never + 140 frame #45: 0x00000001cad5ce68 SwiftUI`static SwiftUI.App.main() -> () + 224 frame #46: 0x0000000105943104 MyApp Dev.debug.dylib`static MyMacApp.$main() at :0 frame #47: 0x0000000105943c9c MyApp Dev.debug.dylib`main at MyMacApp.swift:24:8 frame #48: 0x000000019b464274 dyld`start + 2840

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

Thread 0 Crashed: 0 WebKit 0x00000001a1b6bf1c WKMouseDeviceObserver.connectedDeviceCount.setter + 68 (WKMouseDeviceObserver.swift:0) 1 WebKit 0x00000001a1b6bea4 @objc WKMouseDeviceObserver.connectedDeviceCount.setter + 152 2 WebKit 0x00000001a1b6d95c closure #2 in WKMouseDeviceObserver.start() + 80 (WKMouseDeviceObserver.swift:0) 3 WebKit 0x00000001a1b4e3e9 &lt;deduplicated_symbol&gt; + 1 4 WebKit 0x00000001a1b4e139 &lt;deduplicated_symbol&gt; + 1 5 WebKit 0x00000001a1b4e769 &lt;deduplicated_symbol&gt; + 1 6 libswift_Concurrency.dylib 0x0000000196037cdd completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:546)

Summary: Content scripts injected via manifest continue to receive and respond to chrome.tabs.sendMessage() calls even after the user has navigated away from the original page, causing messages intended for the current tab to be handled by zombie contexts from previous pages. Environment: Safari/iOS Version: 18.5 Extension Manifest: Version 3 Expected Behavior: When a user navigates from Page A to Page B: Page A's content script context should be destroyed. chrome.tabs.sendMessage(currentTabId, message) should only reach Page B's content script Only Page B should be able to respond to action button clicks (or other background to content messages). Actual Behavior: When navigating from Page A to Page B: Page A's content script context persists as a "zombie". chrome.tabs.sendMessage(currentTabId, message) reaches zombie context instead of the Page B's one. Hence, it looks like the extension is broken because the content script does not respond to the background messages. Details: Tab ids are properly recognized by both background and content script The problem does not always occur; it occurs on random occasions. It's quite easy to have it reproduced. It can be reproduced easier if user clicks ext icon during site loading (before it fully loaded), triggering ActionClick (ext icon click) event and then sending a msg upon it to the content script Regardless of whether the content script is injected into the tab using manifest.json, registerContentScripts, or executeScript, the problem is still there Once the problem occurs, e.g. user is on macys.com but zombie injected content script believes it's google.com (a previous page), even refreshing the tab doesnt change anything - zombie context is still there (thinking it's still google.com) . Changing a domain to something completely different one could help though. Then going back to macys.com could still lead to the described issue. A zombie content script does not have access to the page's console function and others. Example communication Sending following message from the background to the content script using chrome.tabs.sendMessage() { "tab": { "id": 155, "active": true, "url": "https://www.macys.com/", "title": "Macys.com" } } Results in the content-script zombie context response (the url is taken from the window.location.href) "message": { "type": "ActionClicked", "data": {} }, "response": { "data": { "windowUrl": "https://www.google.com/", "contentReached": true, "timestamp": "1,753,138,945,272", } } }

Merhaba ben Müslüm İkuz blog sayfam için Safari tarayıcıdan siteye çok fazla istek geliyor. Sayaçlara girdiğimde uygulama safari olarak gözüküyor ve binlerce sayfa isteği gelmiş. Bu bir siber saldırı mı ? site adress https://ikuz.com.tr/

Hi, How are we supposed to handle links with target="_blank" in the new SwiftUI WebView? I don't see anything in WebPage.NavigationDeciding or elsewhere that corresponds to the delegate method used for WKWebView.

Hi everyone, We're building a web application using Next.js that captures around 40 images across different routes as part of a guided user flow. At the beginning of the process, we explicitly request camera permission using navigator.mediaDevices.getUserMedia(...), and the user grants it successfully. However, as users proceed through the flow (navigating between routes), Safari on iOS intermittently re-prompts for camera access—despite the initial permission already being granted and the origin (domain) remaining unchanged. This repeated prompting interrupts the user experience significantly. What we’ve tried: Ensuring camera access is requested only once and reused where possible. Using persistent media stream across routes (where feasible). Testing across different iOS versions to confirm consistency. Questions: Is there a known workaround or best practice to persist camera access across route transitions in a SPA/PWA context on iOS? Are there any Safari-specific behaviors or restrictions related to WebRTC / getUserMedia we should be aware of? Would embedding the camera view in an iframe or maintaining a persistent component help avoid re-prompting? Any guidance or shared experience would be greatly appreciated. Thanks in advance!

I recently updated my iPhone 12 to iOS 26. It seems there is a bug rendering Safari unable to "add to home screen" any website. Clicking the button displays a blank modal with Add button greyed out.

We have a Safari extension that's been up on the App Store for about 18 months with no apparent issues. This week, however, while working on an update, we uninstalled the production version on our test machines and installed a developer version. When we had some issues, we tried to go back to the production version downloaded from the App Store, but we get an pop saying "Unable to download App." In the log, the most obviously relevant error is 'Operation not permitted'. This occurs on several machines and different logins on those machines in both norma and safe modes. However, on another machine that never had one installed, we could still install the app from the app store, so I suspect there is something left behind that needs to be removed, but I don't know what. FWIW, I see the download directory getting created under /Applications, but it is promptly removed when the failure popup appears. Any suggestions?

Our app connects to the headend to get a IDP login URL for each connection session, for example: “https://myvpn.ocwa.com/+CSCOE+/saml/sp/login?ctx=3627097090&amp;acsamlcap=v2” and then open embedded webview to load the page. (Note: the value of ctx is session token which changes every time). Quite often the webview shows blank white screen. After user cancel the connection and re-connect, the 2nd time webview loads the content successfully. The working case logs shows: didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called twice didReceiveAuthenticationChallenge is called decidePolicyForNavigationResponse is called didReceiveAuthenticationChallenge is called But the failure case shows: Filed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x11461c240 {Error Domain=RBSRequestErrorDomain Code=3 "No such process found" UserInfo={NSLocalizedFailureReason=No such process found}}} didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called decidePolicyForNavigationResponse is called If we stop calling evaluateJavaScript code to get userAgent, the blank page happens less frequently. Below is the code we put in makeUIView(): func makeUIView(context: Context) -&gt; WKWebView { if let url = URL(string: self.myUrl) { let request = URLRequest(url: url) webview.evaluateJavaScript("navigator.userAgent") { result, error in if let error = error { NSLog("evaluateJavaScript Error: \(error)") } else { let agent = result as! String + " " + self.myUserAgent webview.customUserAgent = agent webview.load(request) } } } return self.webview } Found some posts saying call evaluateJavaScript only after WKWebView has finished loading its content. However, it will block us to send the userAgent info via HTTP request. And I don’t think it is the root cause since the problem still occurs with less frequency. There is no problem to load same web page on Windows desktop and Android devices. The problem only occurs on iOS and macOS which both use WKWebview APIs. Is there a bug in WKWebview? Thanks, Ying

Hello! I have a few questions about integrating an OAuth2 API into my Swift application. I am using this API to access user data from the website (users will authenticate themselves within the app). I have seen other apps use this API in the way that I am describing it so I know that it is possible. However, I am not sure how to implement it. Are there any recommended ways to use an OAuth2 API in my application? The API that I am using does not specifically say that it supports PKCE. However, I have heard from some sources that it does. If it does not support PKCE, how do I still create a secure app infrastructure that will pass App Store Review? At a more basic level, what is the difference between OAuth2 and PKCE? What should I use in my app? Are there any resources to learn a little bit more about these protocols so that I understand them better? Thanks!

正文：大家好， 当设备连接到没有互联网的 Wi-Fi SSID（例如，硬件设备的 AP）时，我看到 NSURLSession（multipathServiceType = NSURLSessionMultipathServiceTypeInteractive）和 WKWebView 之间的行为存在令人费解的差异。我正确启用了多路径授权，在这种情况下： NSURLSession 请求会自动回退到蜂窝网络并成功（无需用户干预，快速切换）。 WKWebView 加载失败或停滞：Web 内容未出现，即使系统网络路径得到满足并确认了真正的 Internet 可访问性，Web 视图似乎也没有使用蜂窝路径。 环境： iOS 版本：（例如 iOS 18.4） 设备：（例如 iPhone 15 Pro） 多路径权利：在应用程序中启用，使用 NSURLSessionMultipathServiceTypeInteractive 连接的 SSID：硬件设备 Wi-Fi，无需外部互联网 预期回退：一旦 Wi-Fi 没有互联网，就会自动到蜂窝网络，如 NSURLSession 所观察到的那样 我做了什么/观察到什么： 使用多路径的 NSURLSession 按预期工作：NSURLSessionConfiguration *cfg = [NSURLSessionConfiguration defaultSessionConfiguration];cfg.multipathServiceType = NSURLSessionMultipathServiceTypeInteractive;NSURLSession *session = [NSURLSession sessionWithConfiguration：cfg];NSURLRequest *req = [NSURLRequest requestWithURL：[NSURL URLWithString：@“https://www.apple.com/library/test/success.html”]];NSURLSessionDataTask *task = [session dataTaskWithRequest：req completionHandler：^（NSData *data， NSURLResponse *resp， NSError *err） { NSLog（@“NSURLSession result： %@， error： %@”， resp， err）; }];[任务简历];连接到设备 Wi-Fi（无外部 Internet）时，会话会悄悄地切换到手机网络并成功完成。 相同情况下WKWebView加载失败：[self.webView loadRequest：[NSURLRequest requestWithURL：[NSURL URLWithString：@“https://www.apple.com/library/test/success.html”]]];Web 视图要么显示负载失败，要么只是挂起，即使较低级别的监视报告网络路径已满足并且真正的 Internet 连接可用。 网络路径监控逻辑： 我使用 C API nw_path_monitor来监视nw_path_status_satisfied。 一旦观察到满意，我就会使用nw_connection（例如，连接 tohttps://www.apple.com/library/test/success.html）执行真正的连接检查，以验证真实的互联网流量是否可以通过蜂窝网络流动。 该检查通过，确认回退到手机网络，但 WKWebView 仍不会加载内容。同时，相同条件下的 NSURLSession 请求会立即成功。 示例日志记录跟踪：[+] nw_path_status_satisfied=1， hasWiFi=1， hasCellular=1 [+] Internet 连接测试：准备就绪（通过 nw_connection） [-] WKWebView 加载失败/停滞 [+] NSURLSession 请求成功完成 问题： 为什么当 Wi-Fi 没有 Internet 时，具有多路径服务类型的 NSURLSession 无缝使用蜂窝网络，但 WKWebView 不表现出相同的回退行为？WKWebView 是否不以相同的方式接受系统的多路径回退？在这种情况下，它是否使用不同的网络堆栈或忽略多路径授权？ 是否有一种受支持的方法可以强制 WKWebView 像 NSURLSession 一样运行？ 例如，我是否可以通过启用多路径的 NSURLSession 桥接内容，并通过自定义方案将其注入 WKWebView？ 是否有任何 WKWebView 配置标志、首选项或策略启用相同的自动接口切换？ 与原始 NSURLSession 相比，WKWebView 处理网络接换、路径满意度或多路径的方式是否存在已知限制或记录在案的差异？ 我排除/尝试过的： 已验证多路径授权是否包含且处于活动状态。 确认的网络路径“满足”，并且在调用 [webView loadRequest：] 之前，真正的 Internet 可访问性成功。 将 WKWebView 加载延迟到连接验证之后。 观察到 NSURLSession 请求在相同的连接条件下成功。 任何对内部差异、推荐的解决方法或 Apple 推荐的模式的见解，以使 Web 内容在“没有互联网的 Wi-Fi”+ 自动回退到蜂窝场景中变得健壮，我们将不胜感激。 谢谢！

I am a newby to JavaScript, suggested to me to use to automate the task of opening of a Web page, selecting three internal buttons in sequence to download the underlying chart data. I have created the App via Automator on macOS, to run the Script, successfully open the Web Page, but cannot find a way to select and click() on the buttons. Can someone please help me. Robert. This is the code suggested by Grok 3 Beta, but I see this error: Error: First parameter passed to Document Constructor must be an object. function run(input, parameters) { var Safari = Application('Safari'); Safari.activate(); // Open the AEMO data dashboard (Grok 3 Beta recomendation opens the web page correctly) Safari.Document().make(); Safari.windows[0].currentTab.url = 'https://www.aemo.com.au/energy-systems/electricity/national-electricity-market-nem/data-nem/data-dashboard-nem'; delay(10); // Wait for page to load // Click the Fuel Mix tab (target the active in the tabs) Safari.Document(0).doJavaScript("document.querySelector('.tabs .active').click()"); delay(5); // Wait for tab content to load // Select 48 hrs from the dropdown Safari.Document(0).doJavaScript("document.querySelector('#interval').value = '48H'; document.querySelector('#interval').dispatchEvent(new Event('change'))"); delay(5); // Wait for selection to take effect // Click the download button Safari.Document(0).doJavaScript("document.querySelector('.visualisation-icon-button').click()"); return input; }

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.

I am trying to setup web sign in with apple, I have an active apple subscription and have set up all necessary things. I made a service id in apple Identifiers, connected to existing primary id (also has apple sign in enabled). I have my domain set up also correctly but still I cant generate the code due to invalid client. What do I need to do? I have also tried recreating the service ids multiple times with no luck. my init is AppleID.auth.init({ clientId : '[CLIENT_ID]',//used the service id one not app id redirectURI : '[REDIRECT_URI]', usePopup : true }); link to generate codes now is: https://appleid.apple.com/auth/authorize?client_id=com.crmtournest.sigin&redirect_uri=https%3A%2F%2Fwww.tournestcrm.com%2Fauth%2Fcallback&response_type=code%20id_token&state=saciy7rn1km&scope=name%20email&response_mode=web_message&frame_id=03487c22-abb4-48cd-8613-d6bf5836e9eb&m=11&v=1.5.5 Also tried: https://appleid.apple.com/auth/authorize?client_id=com.crmtournest.sigin&redirect_uri=https%3A%2F%2Fwww.tournestcrm.com%2Fauth%2Fcallback&response_type=code%20id_token (not working) I get invalid_client setup on apple below:

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.

Body:
Hi all, I’m seeing a puzzling discrepancy in behavior between NSURLSession (with multipathServiceType = NSURLSessionMultipathServiceTypeInteractive) and WKWebView when the device is connected to a Wi-Fi SSID that has no internet (e.g., a hardware device’s AP). I have the Multipath entitlement properly enabled, and in this scenario: NSURLSession requests automatically fall back to cellular and succeed (no user intervention, fast switch). WKWebView loads fail or stall: the web content does not appear, and it seems like the web view is not using the cellular path even though the system network path becomes satisfied and real Internet reachability is confirmed. Environment: iOS version: (e.g., iOS 18.4) Device: (e.g., iPhone 15 Pro) Multipath entitlement: enabled in the app, using NSURLSessionMultipathServiceTypeInteractive Connected SSID: hardware device Wi-Fi with no external internet Expected fallback: automatic to cellular once the Wi-Fi has no internet, as observed with NSURLSession What I’ve done / observed: NSURLSession using Multipath works as expected:
NSURLSessionConfiguration *cfg = [NSURLSessionConfiguration defaultSessionConfiguration];
cfg.multipathServiceType = NSURLSessionMultipathServiceTypeInteractive;
NSURLSession *session = [NSURLSession sessionWithConfiguration:cfg];
NSURLRequest *req = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.apple.com/library/test/success.html"]];
NSURLSessionDataTask *task = [session dataTaskWithRequest:req completionHandler:^(NSData *data, NSURLResponse *resp, NSError *err) {
NSLog(@"NSURLSession result: %@, error: %@", resp, err);
}];
[task resume];
When connected to the device Wi-Fi (no external internet), the session quietly shifts to cellular and completes successfully. WKWebView fails to load under the same conditions:
[self.webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.apple.com/library/test/success.html"]]];
The web view either shows a load failure or just hangs, even though lower-level monitoring reports that the network path is satisfied and real Internet connectivity is available. Network path monitoring logic: I use the C API nw_path_monitor to watch for nw_path_status_satisfied. Once satisfied is observed, I perform a true connectivity check using nw_connection (e.g., connecting tohttps://www.apple.com/library/test/success.html) to verify that real Internet traffic can flow over cellular. That check passes, confirming fallback to cellular, but WKWebView still does not load content. Meanwhile, NSURLSession requests in the same condition succeed immediately. Sample logging trace:
[+] nw_path_status_satisfied=1, hasWiFi=1, hasCellular=1
[+] Internet connectivity test: ready (via nw_connection)
[-] WKWebView load failed / stalled
[+] NSURLSession request completed successfully Questions: Why does NSURLSession with the multipath service type seamlessly use cellular when the Wi-Fi has no internet, but WKWebView does not exhibit the same fallback behavior? Is WKWebView not honoring the system’s multipath fallback the same way? Does it use a different networking stack or ignore the multipath entitlement in this scenario? Is there a supported way to force WKWebView to behave like NSURLSession here? For example, can I bridge content through a multipath-enabled NSURLSession and inject it into WKWebView via a custom scheme? Are there any WKWebView configuration flags, preferences, or policies that enable the same automatic interface switching? Are there known limitations or documented differences in how WKWebView handles network interface switching, path satisfaction, or multipath compared to raw NSURLSession? What I’ve ruled out / tried: Verified the Multipath entitlement is included and active. Confirmed network path is “satisfied” and that real Internet reachability succeeds before calling [webView loadRequest:]. Delayed the WKWebView load until after connectivity verification. Observed that NSURLSession requests succeed under identical connectivity conditions. Any insight into internal differences, recommended workarounds, or Apple-recommended patterns for making web content robust in a “Wi-Fi with no internet” + automatic fallback-to-cellular scenario would be greatly appreciated. Thank you!

iOS18的app中加载了自己开发的H5页面，H5页面有个input输入框，每次输入框聚焦的时候，都会弹出键盘滑行键入的提示：“滑动手指将字母拼成词以快速键入”，应该怎么修改，达到不每次都弹出这个提示呢

How did you test apple-app-site-association in non-production environments that are usually not public?