When using passkeys stored in iCloud Keychain (Passwords app) via Passkey Autofill in browsers other than Safari, the userVerification parameter is ignored and user verification (UV) is not performed. As a result, relying party servers that require userVerification = required fail validation because the UV flag is not set, causing passkey authentication to fail. This issue occurs when the following setting is disabled: Settings → Face ID & Passcode → Use Face ID For → Password AutoFill The issue is reproducible only with the following combination: Non-Safari browsers (e.g. Chrome) Passkeys stored in iCloud Keychain (Passwords app) Passkey Autofill The issue does not occur in the following cases: Safari with passkeys stored in any credential manager Non-Safari browsers using credential managers other than iCloud Keychain Steps to Reproduce: Go to Settings → General → Autofill & Passwords, and enable the Passwords app under “Autofill From”. Go to Settings → Face ID & Passcode → Use Face ID For, and disable “Password AutoFill”. Open Chrome and navigate to https://webauthn.io Enter a username and tap “Register” to create a passkey using the Passwords app (iCloud Keychain). On webauthn.io, go to Advanced Settings → Authentication Settings, and set “User Verification” to “Required”. Reload the page, tap the input field, and perform Passkey Autofill. User Verification is not triggered, and “Authentication failed” is displayed on webauthn.io. === This issue has already been reported via Feedback Assistant as FB21756948. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

Hi, We're experiencing a WKWebView issue where the screen intermittently turns pure magenta (#FF00FF) in our production iOS app. After investigation, we traced this to WebKit's internal WKCompositingView.mm where [UIColor magentaColor] is used as a pending state indicator when coverView.hidden == NO. This matches rdar://163597990 / WebKit Bug 303157 ("Magenta flash when loading page"), which was fixed in commit 303720@main on 2025-12-01 via PR #54499. My question is simple: which iOS/Safari release includes this fix? We're on iOS 26.3 and still seeing the issue. We need to know: Is the fix already in iOS 26.3? (If so, there may be another unfixed code path) If not, which upcoming iOS version will include it? Our environment iOS 26.3, iPhone 15 Pro Max WKWebView with complex web content App codebase contains zero magenta color usage — this is purely from WebKit Related rdar://163597990 Bug 303157 — RESOLVED FIXED Bug 230531 — "Pages render as magenta after being in background" PR #54499 — Merged to main 2025-12-01 Any information about the release timeline would be very helpful. Thanks!

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?

Before iOS 26.3, the WKWebView method open func loadFileURL(_ URL: URL, allowingReadAccessTo readAccessURL: URL) -> WKNavigation? worked fine when both parameters were passed the same path (e.g., h5path/index.html), allowing access to and loading of other files like CSS and JS within the h5path directory. However, in iOS 26.4 Beta, this results in an error, and the second parameter must point to a parent directory. Is this a bug?

Hi Team, We're trying to load an Image Ad inside WKWebView and we're wondering if we can adjust its width and height based on the loaded content. Currently, we're using evaluateJavaScript("document.body.scrollHeight") query to fetch the height of the content but often times we get incorrect value from it. We looked at the WKWebView documentation but couldn't find anything related to our use case. Could someone from the team guide us through the next step? Thanks

We are developing a mobile-first, browser-only web application that requires users to upload 20–200 images stored inside a single folder (for example, a merchant product directory). On iOS Safari: window.showDirectoryPicker() is not supported. is not supported. File System Access API is not available. Users must manually multi-select images from the Photos picker. This creates significant friction for bulk upload workflows. We are NOT requesting unrestricted file system access. We are asking whether a privacy-preserving, user-granted folder-scoped permission model is being considered for web applications. For example: User explicitly selects a folder. The web app receives scoped access only to that selected folder. Access is session-bound and revocable. No background or global storage access is required. Questions: Is folder-level access for web apps being considered for iOS Safari? Does installing a PWA provide any enhanced file access capability? Are there recommended best practices for handling bulk image uploads in browser-only iOS applications? Is there any roadmap alignment with the File System Access API standard? Our goal is to remain browser-only and maintain strict user privacy while improving usability for high-volume image workflows. Any clarification on intended platform direction would be appreciated.

Hello there, Credit card autofill works in Safari when accessing the checkout on my website, but does NOT work when the same page is loaded in a WKWebView within the my iOS mobile app. is there any way I can make it work?

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

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

Fatal Exception: NSInternalInconsistencyException Cannot remove an observer <WKWebView 0x135137800> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13c6d7460>, 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.] I noticed that on iOS 26, WKWebView registers STScreenTimeConfigurationObserver, Is this an iOS 26 system issue? What should I do?

VideoMaterial Black Screen on Vision Pro Device (Works in Simulator) App Overview App Name: Extn Browser Bundle ID: ai.extn.browser Purpose: A visionOS web browser that plays 360°/180° VR videos in an immersive sphere environment Development Environment & SDK Versions Component Version Xcode 26.2 Swift 6.2 visionOS Deployment Target 26.2 Swift Concurrency MainActor isolation enabled App is released in the TestFlight. Frameworks Used SwiftUI - UI framework RealityKit - 3D rendering, MeshResource, ModelEntity, VideoMaterial AVFoundation - AVPlayer, AVAudioSession WebKit - WKWebView for browser functionality Network - NWListener for local proxy server Sphere Video Mechanism The app creates an immersive 360° video experience using the following approach: // 1. Create sphere mesh (10 meter radius for immersive viewing) let mesh = MeshResource.generateSphere(radius: 10.0) // 2. Create initial transparent material var material = UnlitMaterial() material.color = .init(tint: .clear) // 3. Create entity and invert sphere (negative X scale) let sphere = ModelEntity(mesh: mesh, materials: [material]) sphere.scale = SIMD3<Float>(-1, 1, 1) // Inverts normals for inside-out viewing sphere.position = SIMD3<Float>(0, 1.5, 0) // Eye level // 4. Create AVPlayer with video URL let player = AVPlayer(url: videoURL) // 5. Configure audio session for visionOS let audioSession = AVAudioSession.sharedInstance() try audioSession.setCategory(.playback, mode: .moviePlayback, options: [.mixWithOthers]) try audioSession.setActive(true) // 6. Create VideoMaterial and apply to sphere let videoMaterial = VideoMaterial(avPlayer: player) if var modelComponent = sphere.components[ModelComponent.self] { modelComponent.materials = [videoMaterial] sphere.components.set(modelComponent) } // 7. Start playback player.play() ImmersiveSpace Configuration // browserApp.swift ImmersiveSpace(id: appModel.immersiveSpaceID) { ImmersiveView() .environment(appModel) } .immersionStyle(selection: .constant(.mixed), in: .mixed) Entitlements <!-- browser.entitlements --> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.network.client</key> <true/> <key>com.apple.security.network.server</key> <true/> Info.plist Network Configuration <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict> The Issue Behavior in Simulator: Video plays correctly on the inverted sphere surface - 360° video is visible and wraps around the user as expected. Behavior on Physical Vision Pro: The sphere displays a black screen. No video content is visible, though the sphere entity itself is present. Important: Not a DRM/Licensing Issue This issue is NOT related to Digital Rights Management (DRM) or FairPlay. I have tested with: Unlicensed raw MP4 video files (no DRM protection) Self-hosted video content with no copy protection Direct MP4 URLs from CDN without any licensing requirements The same black screen behavior occurs with all unprotected video sources, ruling out DRM as the cause. (Plain H.264 MP4, no DRM) Screen Recording: Working in Simulator The following screen recording demonstrates playing a 360° YouTube video in the immersive sphere on the visionOS Simulator: https://cdn.commenda.kr/screen-001.mov This confirms that the VideoMaterial and sphere rendering work correctly in the simulator, but the same setup shows a black screen on the physical Vision Pro device. Observations AVPlayer status reports .readyToPlay - The video appears to load successfully VideoMaterial is created without errors - No exceptions thrown Sphere entity renders - The geometry is visible (black surface) Audio session is configured - No errors during audio session setup Network requests succeed - The video URL is accessible from the device Same result with local/unprotected content - DRM is not a factor Console Logs (Device) The logging shows: Sphere created and added to scene AVPlayer created with correct URL VideoMaterial created and applied Player status transitions to .readyToPlay player.play() called successfully Rate shows 1.0 (playing) Despite all success indicators, the rendered output is black. Questions for Apple Are there known differences in VideoMaterial behavior between the visionOS Simulator and physical Vision Pro hardware? Does VideoMaterial(avPlayer:) require specific video codec/format requirements that differ on device? (The test video is a standard H.264 MP4) Is there a required Metal capability or GPU feature for VideoMaterial that may not be available in certain contexts on device? Does the immersion style (.mixed) affect VideoMaterial rendering on hardware? Are there additional entitlements required for video texture rendering in RealityKit on physical hardware? Attempted Solutions Configured AVAudioSession with .playback category Added delay before player.play() to ensure material is applied Verified sphere scale inversion (-1, 1, 1) Tested multiple video URLs (including raw, unlicensed MP4 files) Confirmed network connectivity on device Ruled out DRM/FairPlay issues by testing unprotected content Environment Details Device: Apple Vision Pro visionOS Version: 26.2 Xcode Version: 26.2 macOS Version: Darwin 25.2.0

Hello everyone, I am currently working on integrating a WebView into my macOS application, intended to allow users to browse tutorial webpages directly within the app. Although I’ve followed an example that appears syntactically correct, the WebView does not render any webpage content. Below is a code snippet for reference: import SwiftUI import WebKit struct HelpWebView: View { @State private var toggle = false @State private var page = WebPage() private var url: URL { toggle ? URL(string: "https://www.webkit.org")! : URL(string: "https://www.swift.org")! } var body: some View { WebView(page) .onAppear { page.load(URLRequest(url: url)) } .onChange(of: toggle) { page.load(URLRequest(url: url)) } .toolbar { Button("Reload", systemImage: "arrow.clockwise") { toggle.toggle() } } } } I would greatly appreciate any insights or suggestions on what might be causing this issue or how to resolve it. Thank you in advance for your help!

Hello everyone, I am currently working on integrating a WebView into my macOS application, intended to allow users to browse tutorial webpages directly within the app. Although I’ve followed an example that appears syntactically correct, the WebView does not render any webpage content. Below is a code snippet for reference: import SwiftUI import WebKit struct HelpWebView: View { @State private var toggle = false @State private var page = WebPage() private var url: URL { toggle ? URL(string: "https://www.webkit.org")! : URL(string: "https://www.swift.org")! } var body: some View { WebView(page) .onAppear { page.load(URLRequest(url: url)) } .onChange(of: toggle) { page.load(URLRequest(url: url)) } .toolbar { Button("Reload", systemImage: "arrow.clockwise") { toggle.toggle() } } } } I would greatly appreciate any insights or suggestions on what might be causing this issue or how to resolve it. Thank you in advance for your help!

I am using the native SwiftUI WebView and WebPage APIs (iOS 26+) and would like to implement file download functionality using the native SwiftUI WebView. However, I have not been able to find any APIs equivalent to WKDownload. In WKWebView, the WKDownload API can be used to handle downloads. I am looking for a similar API or recommended approach in the native SwiftUI WebView that would allow downloading files. If anyone has guidance or suggestions on how to implement this, I would appreciate your help.

Expected Behavior: Display the digit “6”. Actual Behavior: The rendered character appears as a composite glyph—the left half resembles “9” and the right half resembles “6”, resulting in a malformed digit. other examples： Environment & Characteristics: Occurs intermittently on iPhone 15 Pro Max and iPhone 16 Pro Max. Reproducible within the Taobao App, specifically in WKWebView. Font Used: AlibabaSans102_v1_TaoBao-Bd.ttf

I’m currently developing an application using WKWebView. After updating to iOS 26.2 Developer Beta, the following Web API started returning false: isUserVerifyingPlatformAuthenticatorAvailable MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static This issue did not occur on iOS 26.1 — it only happens on the beta version. Has anyone else encountered this problem or is aware of any related changes? OS: iOS 26.2 beta 3 (23C5044b)

90809: Deprecated API Usage. New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview). I did not actively use UIWebView in my app, but this error occurred during the build upload process. This version has an additional integration of the iOS Ayla SDK and Public-9.0.7 SDK compared to the previous version. If there is indeed a call in a third-party SDK, how can I determine where the call exists? Thank you

1. Summary In a hybrid iOS app using WKWebView (Angular + Capacitor), after programmatically blurring an element and connecting a Bluetooth keyboard, pressing Ctrl+Home or Ctrl+End causes the app to crash. The crash stack shows the issue occurs inside UIKit keyboard handling (UITextInteractionSelectableInputDelegate _moveToStartOfLine), indicating a system-level bug. 2. Steps to Reproduce Open the hybrid app containing a WKWebView. Blur the input (programmatically). Connect a Bluetooth keyboard. Press Ctrl + Home or Ctrl + End. Expected result: No crash. The command should be ignored if no text input is active. Actual result: App crashes immediately. 3. Crash Log (Crashlytics Trace) Crashed: com.apple.main-thread 0 WebKit 0xfbdad0 <redacted> + 236 1 UIKitCore 0x10b0548 -[UITextInteractionSelectableInputDelegate _moveToStartOfLine:withHistory:] + 96 2 UIKitCore 0xd0fb38 -[UIKBInputDelegateManager _moveToStartOfLine:withHistory:] + 188 3 UIKitCore 0xa16174 __158-[_UIKeyboardStateManager handleMoveCursorToStartOfLine:beforePublicKeyCommands:testOnly:savedHistory:force:canHandleSelectableInputDelegateCommand:keyEvent:]_block_invoke + 52 4 UIKitCore 0xa36ae4 -[_UIKeyboardStateManager performBlockWithTextInputChangesIgnoredForNonMacOS:] + 48 5 UIKitCore 0xa160f0 -[_UIKeyboardStateManager handleMoveCursorToStartOfLine:beforePublicKeyCommands:testOnly:savedHistory:force:canHandleSelectableInputDelegateCommand:keyEvent:] + 440 6 UIKitCore 0xa06614 -[_UIKeyboardStateManager handleKeyCommand:repeatOkay:options:] + 3204 7 UIKitCore 0xa2fb64 -[_UIKeyboardStateManager _handleKeyCommandCommon:options:] + 76 8 UIKitCore 0xa2fb08 -[_UIKeyboardStateManager _handleKeyCommand:] + 20 9 UIKitCore 0xa30684 -[_UIKeyboardStateManager handleKeyEvent:executionContext:] + 2464 10 UIKitCore 0xa2f95c __42-[_UIKeyboardStateManager handleKeyEvent:]_block_invoke + 40 11 UIKitCore 0x4b9460 -[UIKeyboardTaskEntry execute:] + 208 12 UIKitCore 0x4b92f4 -[UIKeyboardTaskQueue continueExecutionOnMainThread] + 356 13 UIKitCore 0x4b8be0 -[UIKeyboardTaskQueue addTask:breadcrumb:] + 120 14 UIKitCore 0xa2f8d0 -[_UIKeyboardStateManager handleKeyEvent:] + 432 15 CoreFoundation 0x2f934 __invoking___ + 148 16 CoreFoundation 0x2efac -[NSInvocation invoke] + 424 17 UIKitCore 0x14cbcc4 -[UIRepeatedAction invoke] + 176 18 UIKitCore 0x14cbeb8 -[UIRepeatedAction _preInvocationTimerFire] + 56 19 UIKitCore 0x1195364 -[UIApplication _handleKeyboardPressEvent:] + 2192 20 UIKitCore 0x1187278 -[UIApplication pressesBegan:withEvent:] + 328 21 UIKitCore 0x9b808 forwardTouchMethod + 376 22 UIKitCore 0x9b808 forwardTouchMethod + 376 23 UIKitCore 0x9b808 forwardTouchMethod + 376 24 UIKitCore 0x9b808 forwardTouchMethod + 376 25 UIKitCore 0x9b808 forwardTouchMethod + 376 26 UIKitCore 0x9b808 forwardTouchMethod + 376 27 UIKitCore 0x9b808 forwardTouchMethod + 376 28 UIKitCore 0x9b808 forwardTouchMethod + 376 29 WebKit 0x66e2b4 <redacted> + 84 30 UIKitCore 0x9b808 forwardTouchMethod + 376 31 UIKitCore 0x157290c -[UIScrollView pressesBegan:withEvent:] + 148 32 UIKitCore 0x9b808 forwardTouchMethod + 376 33 WebKit 0xfbbd04 <redacted> + 100 34 UIKitCore 0x11a7620 -[UIWindow _sendButtonsForEvent:] + 312 35 UIKitCore 0x522dc -[UIWindow sendEvent:] + 568 36 UIKitCore 0x5f508 -[UIApplication sendEvent:] + 376 37 UIKitCore 0x1194364 -[UIApplication _handleKeyUIEvent:] + 136 38 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 39 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 40 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 41 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 42 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 43 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 44 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 45 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 46 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 47 UIKitCore 0x11a3e14 -[UIResponder _handleKeyUIEvent:] + 56 48 UIKitCore 0x11943e8 -[UIApplication handleKeyUIEvent:] + 56 49 UIKitCore 0x11942ac -[UIApplication _handleKeyHIDEvent:usingSyntheticEvent:] + 660 50 UIKitCore 0x117ac __dispatchPreprocessedEventFromEventQueue + 4648 51 UIKitCore 0xfbe4 __processEventQueue + 4812 52 UIKitCore 0x94e4 updateCycleEntry + 160 53 UIKitCore 0x9404 _UIUpdateSequenceRun + 84 54 UIKitCore 0x8ab4 schedulerStepScheduledMainSection + 208 55 UIKitCore 0x41e4 runloopSourceCallback + 92 56 CoreFoundation 0xf92c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 57 CoreFoundation 0xf744 __CFRunLoopDoSource0 + 172 58 CoreFoundation 0xf5a0 __CFRunLoopDoSources0 + 232 59 CoreFoundation 0xff20 __CFRunLoopRun + 840 60 CoreFoundation 0x11adc CFRunLoopRunSpecific + 572 61 GraphicsServices 0x1454 GSEventRunModal + 168 62 UIKitCore 0x135274 -[UIApplication _run] + 816 63 UIKitCore 0x100a28 UIApplicationMain + 336 64 Order 0xa2ed0 main + 21 (AppDelegate.swift:21) 4. Environment iPadOS versions: 18.1.0, 18.4.1, 18.6.2 WebView: WKWebView Hybrid stack: Angular + (Capacitor) Reproducible on multiple iPads and multiple iPadOS 18.x versions. 5. Expected Behavior Pressing Ctrl+Home or Ctrl+End when no text input is active should be ignored and should not crash the app.

Hello everyone, I am currently evaluating my app's accessibility features to accurately display the "Accessibility" information on the App Store. I have encountered two specific issues regarding Voice Control testing and would appreciate any guidance. Voice Command for "Stop Recording" According to the evaluation criteria, if an app supports audio recording or dictation, users must be able to start and stop recording using only their voice. Behavior: I can successfully trigger the recording using the command "Start Recording". However, I cannot find a command to stop it. Commands like "Stop Recording" or "Stop" are not recognized by the system. Question: Is there a specific standard voice command intended for stopping a recording? Item Number Overlays on Non-Interactive Web Elements (WKWebView) I noticed an inconsistency between native views and web content regarding Voice Control item numbering. Behavior: When testing web content within the app (WKWebView) or in Safari, Voice Control displays item number overlays on non-interactive text elements (such as standard or tags). In native views, static labels do not receive item numbers. Question: Is this expected behavior for web content? Since these elements are not interactive, I am unsure if this should be considered a bug (fail) or an acceptable exception for the accessibility evaluation. Has anyone experienced similar issues or know the correct criteria for these cases? Thank you.

In WKWebView, there is the WKUIDelegate method: func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {} This delegate method provides a callback when a new window (for example, target="_blank") is requested in the web view. However, in native SwiftUI (iOS 26), WebView / WebPage APIs do not provide an equivalent delegate method to handle new window requests. As a workaround, I am using the following method: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {} In this method, when action.target == nil, I treat it as a new window request. My question: Is relying on action.target == nil in decidePolicy a reliable and future-safe way to detect new window requests in SwiftUI’s WebView, or is there a better or more recommended approach for handling target="_blank" / new window navigation in the SwiftUI WebView APIs? Code: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy { guard let webPage = webPage else { return .cancel } // Handle case where target frame is nil (e.g., target="_blank" or window.open) // This indicates a new window request if action.target == nil { print("Target frame is nil - new window requested") // WORKAROUND: Until iOS 26 WebPage UI protocol is available, we handle new windows here // Try to create a new WebPage through UI plugins if handleCreateWebPage(for: webPage, navigationAction: action) != nil { // Note: The new WebPage has been created and published to the view return .allow } } return .allow }