Is there an MDM solution that will give a Safari extension all the permissions it needs with no interaction from the end user?

Hello, We have a Network extension transparent proxy (NETransparentProxyProvider) that receives browser TCP flows as NEAppProxyTCPFlow. For each flow we create an NWConnection to the flow's original destination and set NEParameters.preferNoProxies = true - expecting the outbound connection to bypass the user's HTTP/HTTPS proxy and PAC so it goes to the destination server directly. However, in practice we see connections still being redirected to local proxy after being evaluated against the PAC rules using the destination IP and port. Our questions are: Could we expect preferNoProxies to be respected when a PAC exist on the endpoint and supersede the PAC rule decision? If yes, what would be the best way to file a bug and what information do you need? If not, is there any other way of making sure that the outbound NWConnection created by the transparent proxy is not redirected to a proxy and goes directly to the destination? One other way of avoiding our NWConnection being redirected to the proxy is to use hostname instead of destination IP. Would there be a reliable way of getting hostname for the NEAppProxyTCPFlow so that PAC can correctly filter all NWConnection based on rules? We have explored remoteHostname but it's generally not available for connections from browsers other than Safari.

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?

Hi, I see that on WebViews we don't get the same interface for allowing the user to use a saved password or passkey as in Safari or on an Authentication View. Can the same be accomplished on a WebView?

The new WKJSScriptingBuffer API allows Swift to define data buffers and make them available to JS code running in a WKWebView. Is there any API for passing an ArrayBuffer of data from a WKWebView to Swift code? Currently the usual workaround is to convert the buffer to a base64 string, but that is slow and can lead to exhausting memory depending on the size of the buffer. On the web, window.postMessage() has an argument that allows transferring ownership of ArrayBuffers to the receiver, but the webkit.messageHandlers.<name>.postMessage() API doesn't seem to support that.

I build a framework that has a function that returns a UIView with a web view inside. The app that uses the framework has control over the webview through the subviews API of my UIView. I do not want the framework consumer to utilise the web view's methods and properties. How do I limit access to web view methods like evaluateJavascript, navigation delegate etc?

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.

Context: This is for a privacy relay in a browser, where the proxy is toggled on/off and rotated mid-session, so we can't lose the user's logged-in sessions when it engages. Connection pool behavior — is this expected? When we mutate proxyConfigurations on a live data store, the proxy only applies to newly-visited origins. Origins that already have established connections keep going direct — reloading the page, and even tearing down and recreating the WKWebView, doesn't move them onto the proxy. The only thing that reliably forces all traffic through the proxy is swapping in a brand-new WKWebsiteDataStore. Is that the intended behavior — i.e. is recreating the store the expected way to re-establish the connection pool — or is there a supported way to invalidate the existing connections so a mutated proxy config takes effect on already-loaded origins? What does fetchData/restoreData actually carry? To preserve the session across that store swap, we serialize the old store with fetchData(of: WKWebsiteDataStore.allWebsiteDataTypes()) and rehydrate the new one with restoreData(_:) (iOS 26). Passing the full allWebsiteDataTypes() set, does this round-trip everything those types represent — cookies, localStorage, IndexedDB, service worker registrations, etc. — into a store created with init(forIdentifier:)? And does anything not enumerated by allWebsiteDataTypes() — per-site permissions, tracking-prevention/ITP state — get dropped silently?

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.

We are investigating a web application performance issue observed in iOS Safari/WKWebView after a recent iOS/Safari update. In the network waterfall, the main backend/document request completes within an acceptable time, but JavaScript resources appear to load late and in a more sequential pattern. We also noticed duplicate requests for some static JavaScript assets, which further delays full page rendering. The issue is more visible in iOS Safari/WKWebView compared with other browsers/environments.

I have an ASP.NET WebForm website application running under a WebView (WKWebView) developed with DotNet MAUI, and I've been experiencing problems since compiling with iOS 26. Specifically, there are two buttons on the webform. These buttons use some JavaScript code defined within the page via onClientClick from the ASPX page, while the button is also called from the server side using code like this: string encodedMessage = System.Web.HttpUtility.JavaScriptStringEncode(diffLocationMessage, true); string scriptError = $"hideLoading(); showBootStrapStyleAlert({encodedMessage}, 'error');"; ScriptManager.RegisterStartupScript(this, GetType(), "Alert_Error_DiffLoc", scriptError, true); Some of these JavaScript scripts work, while others don't. At the same time, the OnClientClick button on the MAUI side uses a special handler to process a parameter (ENTRY or EXIT) received from these buttons and updates some hidden fields and labels on the webform side. await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hfLatMaui')) document.getElementById('hfLatMaui').value = '{latitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hfLonMaui')) document.getElementById('hfLonMaui').value = '{longitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hiddenCurrentLat')) document.getElementById('hiddenCurrentLat').value = '{latitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('hiddenCurrentLon')) document.getElementById('hiddenCurrentLon').value = '{longitude}';"); // Part 2: Update labels await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('lblLatMaui')) document.getElementById('lblLatMaui').innerText = '{latitude}';"); await myWebView.EvaluateJavaScriptAsync( $"if(document.getElementById('lblLonMaui')) document.getElementById('lblLonMaui').innerText = '{longitude}';"); Server-side operations are performed with the values ​​received from here. While the above problems did not occur up to iOS 18.x and Xcode 16.4, they are now occurring. What should I do? What do you suggest? NOTE-1: When my iPhone is connected to my M4 Pro PC via a Type-C Lightning cable, I saw that everything worked correctly when I ran the page under the Develop menu in Safari - I tested it. NOTE-2: The problem is, as explained in NOTE-1, that the WebView executes some JavaScript behaviors while blocking others.

We have an issue where Safari on iOS is not handing off to our app after an Auth0 authentication redirect. Issue After a user completes sign-in via an Auth0-hosted login page in Safari, the callback redirect is followed as a plain HTTP navigation rather than being intercepted and handed off to the app. Callback URL format https://identity.example.com/ios/com.example.app/callback Steps to reproduce Open an Auth0 /authorize URL in Safari on iOS with a redirect_uri pointing to a Universal Link callback, log in, and observe that Safari navigates to the callback URL as a plain HTTP request rather than launching the app. What works ASWebAuthenticationSession inside the app handles the same callback correctly. Navigating directly to a Universal Link launches the app, confirming AASA and Universal Links are correctly configured on the affected devices. The issue is specific to Safari intercepting the callback URL when it arrives as the result of an Auth0 redirect. Affected devices Reproducible across multiple devices and iOS versions from iOS 18.x through iOS 26.x. Does Safari have a restriction on intercepting Universal Links that result from a cross-domain redirect? Any guidance appreciated 🙏

Summary On iOS Safari (and WKWebView-based browsers), when a web page uses <input type="file" accept="image/*" capture="environment"> (or capture="user"), the user can only ever hold one captured photo at a time. Each time the file picker is opened and the user takes a new photo using the camera, the newly captured image completely replaces the previously captured image in the input's files FileList. There is no way to accumulate multiple camera-captured photos across successive picker sessions. Steps to Reproduce Set up a web page with an <input type="file" accept="image/*" multiple> element (with or without the capture attribute). Open the page in iOS Safari on an iPhone. Tap the file input — choose Take Photo from the action sheet. Capture a photo and tap Use Photo. Verify input.files.length === 1 (first photo is captured). Tap the same file input again — choose Take Photo again. Capture a second photo and tap Use Photo. Check input.files.length. Expected Result input.files.length should be 2 (or more), containing both the first and second captured photos. The browser should accumulate photos across picker sessions when the multiple attribute is present. Actual Result input.files.length is 1 — only the most recently captured photo is present. The previously captured photo is completely gone. Every new camera capture wipes out all prior selections. Root Cause Analysis On iOS, each invocation of the system file picker (whether using the camera or photo library) creates a brand-new FileList and assigns it to the input element, discarding any previously selected files. The FileList interface is read-only per the HTML spec — web developers cannot programmatically append File objects to it. The DataTransfer API workaround (constructing a new FileList via DataTransfer.items.add()) does not work on iOS Safari — the DataTransfer constructor is not supported for programmatic file list manipulation in file inputs on iOS WebKit. This is specific to iOS. On macOS Safari and all desktop browsers, users can select multiple files in a single picker session, avoiding this issue. Impact This makes it impossible to build a web-based multi-photo capture workflow on iOS using standard HTML APIs. Common real-world use cases that are broken: Uploading multiple photos of a document one page at a time Capturing multiple product photos for a listing Progressive photo capture in inspection or form-filling apps Any PWA or web app requiring sequential camera captures Users must select all photos in a single picker session. If they tap "Cancel" or close the picker, all prior captures are permanently lost. Request Please fix WebKit on iOS so that when <input type="file" multiple> is used, re-opening the file picker either: Accumulates newly selected/captured files into the existing FileList, or Presents the system picker with previously selected files pre-checked (similar to how macOS handles re-opening file dialogs), or Exposes a web API (e.g., via the File System Access API's showOpenFilePicker() with multi-select) that developers can use to manage a cumulative file collection on iOS. Environment Devices: iPhone 13, 14, 15 Pro (physical devices) iOS versions: iOS 16.x, 17.x, 18.x — all affected Browser: Safari (Mobile) Also reproduced in: Chrome for iOS, Firefox for iOS (both use WKWebView) Not reproducible on: macOS Safari, Chrome desktop, Firefox desktop A Feedback Assistant report has been filed. Happy to provide a minimal HTML repro page on request.