I’m adding 5G network slicing support to a web browser app using WKWebView. The app declares: com.apple.developer.networking.slicing.appcategory: webBrowser-9003 com.apple.developer.networking.slicing.trafficcategory: defaultslice-1 The documentation says that apps should also set networkServiceType on URLRequest or URLSessionConfiguration. However, most requests made by a WKWebView, including subresources, JavaScript fetches, and WebSockets, are created internally by WebKit. Is declaring webBrowser-9003 and defaultslice-1 sufficient for WKWebView traffic, or is there a supported way to configure the network service type for the entire WKWebView network session?

on hybrid app , capacitor enabled , vuejs , firebase realtime database loading data to welcome page and the rest of data for language learning application, using websockets and firebase database problem: ios iphone when the app is built and run it doesnt load the data for welcome page and the rest of data. tried longpolling instead of websockets, tried directly REST api connection to firebase but no success on both. ps. App Check token is successfully acquired (JS SDK token ready) but Realtime Database reconnects always time out on all iPhones in TestFlight while the same build works on iPad.

In iOS 26.4 beta, I noticed that when loading pages using WKWebView and using WebSocket to establish IP type addresses, the connection duration was several seconds and sometimes even failed to connect (normally, the connection duration should be in milliseconds). However, when establishing WebSocket connections using domain names, the connections were normal. Additionally, I discovered a special scenario: When directly establishing WebSocket connections using IP type addresses, it remained in the "connect" state. At the same time, based on Wireshark packet capture, it was found that no TCP connection was sent at this time. However, if two connections with the same address were established simultaneously, those two connections could successfully connect. This bug has seriously affected the use of my application service. Is there a chance that this version will solve the problem?

Hi, I'm trying to test out an extension I'm building in Xcode and every time I try to test it, Safari crashes immediately. On later versions of Mac OS, e.g. Sequoia, there's no problem. I'm building this extension as part of a Mac Catalyst app that is a hybrid iPad/Mac OS app. On Safari 26.3 (20623.2.7.18.1) I can just add the source tree as a temporary extension and it works fine. But the .appex file for the same thing is causing the older Safari 17.6 (17618.3.11.11.7, 17618) to throw a fit. Trying to get through this with LLMs has focused on whether the extension target is for iOS and Mac OS or just Mac OS alone, and futzing with UIDeviceFamily the Build Settings. But basically it just doesn't work no matter what I do, and Safari shouldn't crash. Here's the .appex's Info.plist after compilation: % defaults read /Users/[username]/Library/Developer/Xcode/DerivedData/PlainSite-[gibberish]/Build/Products/Debug-maccatalyst/PlainSite.app/Contents/PlugIns/PlainSiteRecycler.appex/Contents/Info.plist { BuildMachineOSBuild = 21H1320; CFBundleIdentifier = "com.thinkcomputer.[product].[extension]"; CFBundleShortVersionString = "1.0"; CFBundleSupportedPlatforms = ( MacOSX ); CFBundleVersion = 2; DTCompiler = "com.apple.compilers.llvm.clang.1_0"; DTPlatformBuild = 14C18; DTPlatformName = macosx; DTPlatformVersion = "13.1"; DTSDKBuild = 22C55; DTSDKName = "macosx13.1"; DTXcode = 1420; DTXcodeBuild = 14C18; LSMinimumSystemVersion = "12.0"; NSExtension = { NSExtensionAttributes = { SafariWebExtensionPath = src; }; NSExtensionPointIdentifier = "com.apple.Safari.web-extension"; NSExtensionPrincipalClass = "PlainSiteRecycler.SafariWebExtensionHandler"; }; UIDeviceFamily = ( 2, 6 ); } Crash log: Hardware Model: MacBookPro12,1 Process: Safari [44241] Path: /Applications/Safari.app/Contents/MacOS/Safari Identifier: com.apple.Safari Version: 17.6 (17618.3.11.11.7) Code Type: X86-64 (Native) Role: Background Parent Process: launchd [1] Coalition: com.apple.Safari [1098] Date/Time: 2026-06-12 13:29:10.8546 -0700 Launch Time: 2026-06-12 13:27:27.7047 -0700 OS Version: macOS 12.7.6 (21H1320) Release Type: User Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_PROTECTION_FAILURE at 0x00007ff7b77d1ff8 Exception Codes: 0x0000000000000002, 0x00007ff7b77d1ff8 VM Region Info: 0x7ff7b77d1ff8 is in 0x7ff7b3fd2000-0x7ff7b77d2000; bytes after start: 58720248 bytes before end: 7 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_SMALL 7fa313000000-7fa313800000 [ 8192K] rw-/rwx SM=PRV GAP OF 0x54a07d2000 BYTES ---> STACK GUARD 7ff7b3fd2000-7ff7b77d2000 [ 56.0M] ---/rwx SM=NUL ... for thread 0 Stack 7ff7b77d2000-7ff7b7fd2000 [ 8192K] rw-/rwx SM=PRV thread 0 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [44241] Highlighted by Thread: 0 Backtrace not available No thread state (register information) available Binary Images: 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ??? Error Formulating Crash Report: dyld_process_info_create failed with 5 Failed to create CSSymbolicatorRef - corpse still valid ¯_(ツ)/¯ thread_get_state(PAGEIN) returned 0x10000003: (ipc/send) invalid destination port thread_get_state(EXCEPTION) returned 0x10000003: (ipc/send) invalid destination port thread_get_state(FLAVOR) returned 0x10000003: (ipc/send) invalid destination port EOF Full Report {"app_name":"Safari","timestamp":"2026-06-12 13:29:12.00 -0700","app_version":"17.6","slice_uuid":"af2262af-647d-3262-adc8-e52c3ef7579e","build_version":"17618.3.11.11.7","platform":0,"bundleID":"com.apple.Safari","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 12.7.6 (21H1320)","incident_id":"8F871759-8566-49DE-A6F9-EE73128BB836","name":"Safari"} { "uptime" : 100000, "procLaunch" : "2026-06-12 13:27:27.7047 -0700", "procRole" : "Background", "version" : 2, "userID" : 503, "deployVersion" : 210, "modelCode" : "MacBookPro12,1", "procStartAbsTime" : 102649791496150, "coalitionID" : 1098, "osVersion" : { "train" : "macOS 12.7.6", "build" : "21H1320", "releaseType" : "User" }, "captureTime" : "2026-06-12 13:29:10.8546 -0700", "incident" : "8F871759-8566-49DE-A6F9-EE73128BB836", "bug_type" : "309", "pid" : 44241, "procExitAbsTime" : 102752878214260, "cpuType" : "X86-64", "procName" : "Safari", "procPath" : "/Applications/Safari.app/Contents/MacOS/Safari", "bundleInfo" : {"CFBundleShortVersionString":"17.6","CFBundleVersion":"17618.3.11.11.7","CFBundleIdentifier":"com.apple.Safari"}, "buildInfo" : {"ProjectName":"Safari","SourceVersion":"7618003011011007","ProductBuildVersion":"618G22","BuildVersion":"12"}, "storeInfo" : {"deviceIdentifierForVendor":"28124F28-A4EB-556C-A50C-D710162ABDA6","thirdParty":true}, "parentProc" : "launchd", "parentPid" : 1, "coalitionName" : "com.apple.Safari", "crashReporterKey" : "134BE33B-9612-8725-73E0-95998174507F", "wakeTime" : 67008, "sleepWakeUUID" : "F942DC6A-04DF-4EE2-AA9F-DB3EDCB24AC3", "sip" : "enabled", "isCorpse" : 1, "exception" : {"codes":"0x0000000000000002, 0x00007ff7b77d1ff8","rawCodes":[2,140701912080376],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_PROTECTION_FAILURE at 0x00007ff7b77d1ff8"}, "termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":44241}, "usedImages" : [ { "size" : 0, "source" : "A", "base" : 0, "uuid" : "00000000-0000-0000-0000-000000000000" } ], "sharedCache" : { "base" : 140703277129728, "size" : 19331678208, "uuid" : "246818c3-4b9f-3462-bcaf-fdf71975e5fe" }, "legacyInfo" : { "threadHighlighted" : 0 }, "trialInfo" : { "rollouts" : [ { "rolloutId" : "61301e3a61217b3110231469", "factorPackIds" : { "SIRI_FIND_MY_CONFIGURATION_FILES" : "652886aa2c02f032beae8316" }, "deploymentId" : 240000028 }, { "rolloutId" : "5ffde50ce2aacd000d47a95f", "factorPackIds" : { }, "deploymentId" : 240000550 } ], "experiments" : [ ] }, "reportNotes" : [ "dyld_process_info_create failed with 5", "Failed to create CSSymbolicatorRef - corpse still valid ¯\(ツ)_/¯", "thread_get_state(PAGEIN) returned 0x10000003: (ipc/send) invalid destination port", "thread_get_state(EXCEPTION) returned 0x10000003: (ipc/send) invalid destination port", "thread_get_state(FLAVOR) returned 0x10000003: (ipc/send) invalid destination port" ] } Any help would be greatly appreciated!

In 2018, Apple staff noted that Safari App Extensions had no direct API to communicate with the containing app, and suggested app groups or opening a custom URL scheme as workarounds. On iOS Safari Web Extensions, app groups work for persistence, but opening the containing app from the native extension/background flow does not appear reliable. iOS launch policy seems to require a direct user gesture, and I have not found a documented way for the extension flow to reliably continue into the containing app. Is there a supported iOS architecture for completing an extension-initiated workflow in the containing app, or is the intended model to persist data and require the user to manually open the app? My current architecture is: JavaScript in the Safari Web Extension extracts article content from the page. The native Extension Handler receives that content via native messaging. The Extension Handler writes an encoded request into the App Group container. The containing app watches the App Group container using DispatchSource.makeFileSystemObjectSource and processes new requests. This works on macOS. It also works on iOS when the containing app is already running. The problem is that on iOS, if the containing app is not already running, there is no app process to observe the filesystem event or process the request. I have tried treating the Extension Handler as the place to do more work, but in practice it seems suited only for short-lived relay/persistence work. It is not a reliable place for my app’s main processing pipeline, which includes rendering article content and uploading it to a third-party service. My app is a Safari-native “read later” style tool that uploads simplified articles to the reMarkable Cloud. The containing app contains most of the functionality: SwiftUI UI, WebKit/WebPage rendering, account/cloud logic, and upload orchestration. The Safari extension captures the article, but the app needs to run to complete the user-visible workflow. From a user’s perspective, tapping the Safari extension toolbar button is the action that initiates the workflow. Is there any supported way for that user-initiated extension action to launch or wake the containing iOS app so it can process pending App Group requests? Or should Safari Web Extensions on iOS be designed only to persist work and then ask the user to manually open the containing app? If manual app launch is the intended model, it would be helpful for the documentation to state this explicitly. The current tripartite model strongly suggests that the JavaScript extension, native handler, and containing app can collaborate as parts of one workflow, but on iOS the containing app appears to be available only out-of-band unless already running.

Hi,
 We’re implementing Apple Pay on the Web for a multi-tenant platform via a PSP. The PSP operates multiple HSM/clusters and gave us multiple CSRs, asking us to register all.
Our understanding: a Merchant ID can hold several PPCs over time, but only one is active at once. Questions Is there any supported way to keep more than one PPC active simultaneously for the same Merchant ID? If not, what does Apple recommend for web-only, multi-tenant setups: a single MID with PSP-side decryption & sub-merchant separation, or separate MIDs per brand/region? Any official guidance on PPC rotation and handling many domains for Apple Pay on the Web? links to official docs or prior Apple responses would be appreciated.

Hello, I am developing a Safari extension that uses service workers and all works well. When the extension is updated, a new content script is injected into the current open tabs however the service worker connection with the new content script does not get established. I confirmed both the old content script and new one is on the page, but the new one just doesn't execute which means it will not connect to the service worker. In Chrome a newly injected content script does work and in FireFox it is handled by FireFox automatically. How can this be done in Safari? Any help would be appreciated.

Hello, Safari on iOS is showing a “Fraudulent Website Warning” for our domain: https://doobler.ru/ We are trying to understand how to properly diagnose this and request a re-evaluation. The website has a valid HTTPS certificate and does not currently appear to be flagged by the reputation tools we checked, including Google Safe Browsing / Search Console / VirusTotal. However, some iPhone users still see the Safari warning, while others do not. What we have checked so far: HTTPS certificate is valid No mixed-content or obvious redirect issues found Google Safe Browsing does not show the domain as unsafe Google Search Console does not show security issues VirusTotal does not show active malware/phishing detections The warning appears only for some users/devices We submitted a review request through Apple’s Website Review form, but have not received any response yet We would like to know: Is there any way to confirm whether the warning comes from Apple’s own reputation system, Google Safe Browsing, or another provider used by Safari? How long does Apple Website Review usually take for Safari fraudulent website warnings? Is there a recommended process for requesting re-evaluation if the warning appears to be a false positive? Are there specific technical signals Safari checks that we should verify, such as redirects, third-party scripts, domain reputation, or brand/phishing heuristics? This is affecting real users, so any guidance on the correct escalation or diagnostic path would be appreciated. Thank you.

1. System/device combinations where the issue does not occur: Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max 2. System/device combinations where the issue does occur: System versions: Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340) Simulator: iOS 26.0 (23A339) Device models: Physical device: iPhone 12 Reproducible in Safari, WKWebView, and UIWebView: Yes Actual behavior In WebView (and identically in Safari): Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected. After the keyboard appears, the visualViewport position changes. Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned: When scrolling down, the position looks correct. When scrolling up, the header/footer are visibly offset. Steps to reproduce Focus an input field → the keyboard appears Dismiss the keyboard Observe that visualViewport.offsetTop remains >0 (does not reset to zero) position: fixed header/footer elements are misplaced relative to the screen Expected behavior After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0. When scrolling upward, fixed elements should remain correctly positioned within the layout viewport. Minimal reproducible demo A simple HTML file containing: A header and footer with position: fixed An input element to trigger the keyboard <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" /> <title>H5 吸顶吸底页面 Demo</title> <style> * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: Arial, sans-serif; height: 2000px; /* 设置内容高度 */ background-color: #f0f8ff; /* body 背景浅蓝色 */ padding-top: 120px; /* 预留 header 高度 */ padding-bottom: 60px; /* 预留 footer 高度 */ overflow-x: hidden; } /* 吸顶 Header */ header { position: fixed; top: 0; left: 0; width: 100%; height: 120px; background-color: #ff6b6b; /* 红色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 24px; font-weight: bold; z-index: 1000; } /* 吸底 Footer */ footer { position: fixed; bottom: 0; left: 0; width: 100%; height: 60px; background-color: #4ecdc4; /* 青绿色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 18px; font-weight: bold; z-index: 1000; } /* 输入框样式 */ .input-container { margin: 100px auto; width: 80%; max-width: 600px; text-align: center; } input[type='text'] { padding: 12px; font-size: 16px; border: 2px solid #ddd; border-radius: 8px; width: 100%; box-sizing: border-box; } input[type='text']:focus { outline: none; border-color: #4ecdc4; } </style> </head> <body> <!-- 吸顶 Header --> <header>吸顶 Header (120px)</header> <!-- 主体内容 --> <div class="input-container"> <input type="text" placeholder="请输入内容..." /> </div> <!-- 吸底 Footer --> <footer>吸底 Footer (60px)</footer> </body> </html>

Hello, I am investigating a WKWebView cookie reliability issue with WKWebsiteDataStore.default() / persistent website data, and I would like to request a supported public API to force persistent cookie durability. We set persistent cookies from native code through the public WKHTTPCookieStore API: let dataStore = WKWebsiteDataStore.default() let cookieStore = dataStore.httpCookieStore await cookieStore.setCookie(cookie) The cookies have Max-Age / maximumAge set, so these are persistent cookies, not session-only cookies. Reproduction pattern: Use WKWebsiteDataStore.default(). Clear existing cookies. Set a persistent cookie through WKHTTPCookieStore.setCookie. After setCookie completes, terminate WebKit's NetworkProcess soon afterward. Create or reuse a WKWebView with the same WKWebsiteDataStore.default(). Load a same-origin page or trigger a same-origin fetch. I also have reproducible WebKit source-level test cases for this, in the style of TestWebKitAPI / WKHTTPCookieStore tests. The tests exercise persistent WKWebsiteDataStore.default() cookies, terminate the NetworkProcess after the cookie mutation, and then verify that a top-level load, same-origin fetch, and WKHTTPCookieStore cookie read can miss the cookie on an unpatched WebKit build. Observed result: The next top-level HTTP request, and sometimes a same-origin fetch, can omit the cookie that was just set. After the NetworkProcess is relaunched, WKHTTPCookieStore.allCookies() can also fail to show the recently set cookie. If I wait long enough after the cookie mutation before terminating the NetworkProcess, the problem disappears. In local simulator testing, this lines up with CFNetwork appearing to debounce/coalesce persistent cookie writes in an approximately 2-to-10 second window. That makes this look like setCookie completion means the current NetworkProcess / CFNetwork cookie store accepted the cookie in memory, but the persistent cookie backing store has not necessarily been written yet. If the NetworkProcess dies before that delayed write, the replacement NetworkProcess appears to reload stale cookie state from disk. This is especially painful for apps that bridge native authentication state into WKWebView. The app sees setCookie complete, assumes the cookie is ready, and then a later WebKit NetworkProcess termination can cause authenticated web requests to be sent without the expected auth cookie. We believe that, at scale, this is a mechanism causing a baseline of about 5% of our HTTP requests, as measured by HAProxy, to lack cookies that should be present. We know those cookies should be present because we duplicate the same values as URLRequest headers under different keys, and the headers are present while the corresponding Cookie header entries are missing. The API gap is that there does not appear to be a supported public equivalent of Android WebView's CookieManager.flush(). There is no public way for an app to say: "I just mutated persistent WKWebView cookies; please synchronously/asynchronously flush the persistent cookie store before I proceed." Request: Please expose a public flush API for persistent WKHTTPCookieStore / WKWebsiteDataStore cookies, for example an async API shaped like: try await websiteDataStore.httpCookieStore.flush() or: try await websiteDataStore.flushCookies() The important behavior would be: after WKHTTPCookieStore.setCookie / deleteCookie completes, an app can explicitly request durability; the flush completion should mean persistent cookie state has been handed to the backing persistent store, not merely accepted by the current NetworkProcess; if flushing is impossible because the relevant process/state is gone, the API should fail or report that, rather than silently succeeding; the API should be safe for App Store apps and should not require private SPI. Question: Are there any recommended supported patterns today for forcing persistent WKWebView cookies to reach durable storage after native WKHTTPCookieStore mutations? Is there an official supported way to force or observe cookie durability for persistent WKWebsiteDataStore cookies? If not, is the recommended approach simply to re-apply critical cookies before loads and tolerate NetworkProcess loss as unrecoverable app-side state? This issue is not just theoretical. It affects auth/session reliability when WebKit's NetworkProcess is terminated before the backing persistent cookie write completes. Apps can reduce unnecessary cookie churn, but without a flush API there is no supported way to close the durability window after setting important persistent cookies.

Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?

After enabling WebXR following instructions from https://developer.apple.com/forums/thread/732629, I can successfully run WebXR, but it is limited to VR. I cannot get AR running. If I try await navigator.xr.isSessionSupported("immersive-ar"), the result is false. But if I try await navigator.xr.isSessionSupported("immersive-vr"), the result is true. I double checked that I specifically checked the box "WebXR Augmented Reality Module" in the Safari feature flags. Any idea how to enable WebXR AR mode? Thanks in advance!

Has Apple worked out how WebXR authored projects in Safari operate with VisionOS? Quest has support already. And I imagine many cross platform experiences (especially for professional markets where the apps are on windows through web) would be serve well with this. Is there documentation for this?

I'm working on a document reader for long form articles and I love what WebKit gives me for quickly delivering good looking content. But I'm hearing that accessibility support is stronger if I go with UIKit or SwiftUI. Accessibility support is meant to be a headline feature in my app so it's the deciding factor on which technology I should use (webview versus UIKit/SwiftUI). Given Accessibility Reader now provides system-wide reflow and spoken reading, is there now a durable reason a document reader developer should still invest in native UIKit/SwiftUI rendering rather than well-structured HTML in a webview? Where specifically does the system stop helping webview content? What I've heard is that webviews are disadvantaged on custom rotors, focus, and Dynamic Type fidelity. Is this accurate or has it changed this year? Bottom line, I'm wondering if WebKit is a compromise for a11y if I want not baseline accessibility, but truly leading unsurpassed accessibility.

Our app uses WKWebView to load web pages, and we're encountering a crash with WKScreenTimeConfigurationObserver on iOS 26.1 and above. However, there are no WKScreenTimeConfigurationObserver-related code calls in our project. The crash log is as follows: NSInternalInconsistencyException Cannot update for observer <WKScreenTimeConfigurationObserver 0x13be821e0> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13be808e0>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO compliance of the STScreenTimeConfigurationObserver class. We want to confirm if this is a system bug. How can we fix it?

Safari on iOS 17, when entering characters into text input box after deleting characters, the layout is off. Here's the HTML: <body> <div id="J001" style="display: inline-block;"> <div id="J001__0" style="display: inline-block;"> <input id="J001__0__input" style="display: inline-block; height: 28px; padding:2px; border:1px solid gray;"></div> <div id="J003__0" style="display: inline-block;"> <button id="J003__0__btn" style="display: inline-block; height:34px;">a</button> </div> </div> </body> Enter "A" into text input box. Delete "A" with the backspace(x). Enter "A" into text input box, the button position will be shifted down. iOS 17 の Safari にて、テキスト入力ボックスで文字を削除した後、文字を入力するとレイアウトが崩れます。 テキスト入力ボックスに「A」と入力します。 バックスペース(x)で「A」を削除します。 テキスト入力ボックスに「A」と入力すると、ボタンの位置が下にずれます。

Hello everyone, I am testing how Siri interacts with web pages on iOS devices. When a user utilizes Siri voice commands to search for or open a specific website, Siri usually processes the request and opens the result inside the Safari browser. As a web developer, I want to know if there are any specific HTML meta tags, Schema markup, or SEO best practices that we should implement. This is to ensure Siri can accurately recognize the website's name, brand, and content. What are the simplest ways to make a static web page friendly for Siri voice search? Thanks in advance!

Is there any documentation or advice on printing from a Safari webapp (in JavaScript)? My app needs to print labels, and printing from Safari presents few options. For example, you can't turn off backgrounds or the URL/date/time footer. And it wants to print a full-size page, which ends up printing miles of label. (I've also tried printing from SwiftUI on a macOS app, and even that is just terrible to try to get right. Why is printing so hard?)

Hi Team, We are observing a noticeable performance difference in client-side PDF generation between Safari and Chrome. Use Case We have an AI modal with a “Download PDF” feature. The PDF is generated on the client side using HTML content from the modal. Observation Chrome: PDF generation completes in ~1–2 seconds Safari: Same flow takes ~25–30 seconds Additional Details The functionality works correctly in both browsers, and the PDF downloads successfully. The issue is mainly the increased processing time in Safari. The modal content may include: Large formatted text Markdown/code blocks Images/styled UI We suspect the delay may be related to Safari’s handling of: Canvas rendering DOM-to-image conversion Blob/PDF generation Font/image processing Libraries/approaches involved: html2canvas jsPDF window.print() (in some cases) Question Is this considered expected behavior in Safari/WebKit for client-side PDF generation? Has anyone found effective Safari-specific optimizations or best practices to improve performance for this use case? Thanks in advance.

We are seeing intermittent WKWebView main-frame navigation failures on iOS 26.4.x. The failure is reported through: webView:didFailProvisionalNavigation:withError: The error code is: NSURLErrorNetworkConnectionLost (-1005) The affected pages are normal HTTPS H5 pages loaded by WKWebView,。 From our client logs, the issue appears during provisional navigation, before the page finishes loading. In many cases, error.userInfo does not contain a useful description, and the log only shows: did fail provisional navigation, error code: -1005, description: nil We have also observed a high concentration of this error on iOS 26.4.x devices. The failures are intermittent and may recover after a retry, which makes us suspect that the underlying network connection may be lost during request processing or connection reuse. What we would like to know: Is there any known issue in iOS 26.4.x / WebKit / CFNetwork that could cause WKWebView provisional navigation to fail with NSURLErrorNetworkConnectionLost (-1005)? Does WKWebView expose any public API or diagnostic mechanism to determine whether the failed request reused an existing TCP/HTTP2 connection? Is there a recommended way to collect lower-level networking diagnostics for WKWebView, such as connection reuse, HTTP/2 stream state, socket close timing, or CFNetwork diagnostics? For main-frame GET navigations that fail with -1005, is a one-time silent retry considered an acceptable mitigation? We can provide timestamps, affected URLs, device OS versions, and client logs if needed.