I coded two demo websites as follows (both written in NextJS): Website 1: I coded an interval counter that increments every 1 second. Website 2: I used the MediaRecorder API (described in the WebKit documentation: https://webkit.org/blog/11353/mediarecorder-api/). In the ondataavailable function, I periodically send a blob (once every 1 second) to my server. In the backend, I coded a POST API to upload this blob. I noticed that with website 1, the interval doesn't work when I run Safari in the background, even on iOS and iPadOS. However, website 2 works, meaning it still calls my API normally (I tried running Safari in the background for about 1-2 hours and it worked). So, does this mean Apple allows native APIs like MediaRecorder and its callbacks to run in the background?

Please kindly improve the Safari browser side bar implementation further along with what The Browser Company has done with their Arc browser. Arc is about to retire soon too and they're willing to sell their SwiftUI code perhaps too for a decent pile of dollars, not the Jony Ive piles at least it should not. The toggle for side bar is nice and works perfect though!

When trying to login using apple account it shows me this error "Your request could not be completed because of an error. Please try again later." although in the inspector everything looks fine (200)

The passkey authentication dialog appears, and after unlocking with Touch ID, the dialog closes without any notification of success or failure. This issue occurs with high frequency. access to the https://passkeys-demo.appspot.com/ register account and create passkey. logoff access to the url again you can see the passkey dialog unlock device then the dialog disappears nothing happens reload the page proceed 5) to 6) nothing happens or success webauthn.

I am maintaining a PWA that utilizes WebSockets. In this app, after the web page is loaded from the server, JavaScript establishes a WebSocket connection. Because the app connects to a completely local server on a managed local network, we use http:// and ws:// (non-secure). The Issue: The app worked perfectly from older iOS versions up to iPadOS 18. However, during testing on iPadOS 26, we encountered an issue where the WebSocket connects successfully but is disconnected by the iPad approximately one second later. According to our packet captures, the iPad is sending a FIN packet to initiate the teardown. Additional Context: What makes this particularly confusing is that we have another server hosting the exact same PWA where the WebSocket connection stays stable even on iPadOS 26. This suggests it might not be a universal OS bug, but perhaps related to specific network conditions or a new security policy. Has anyone experienced similar behavior on iPadOS 26? Could this be a bug, or is there a new security restriction regarding non-secure WebSocket (ws://) connections in local networks? Are there any known changes in WebKit/Safari for iPadOS 26 that might cause the OS to send a FIN packet immediately after a handshake? I would appreciate any insights or suggestions on what might be causing this.

The crash is specific to iOS 26.2 prior versions working fine. WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) Name attribute is accessible but WKScriptMessage body attribute causes crash The object seems to be not accessible(not in memory) self.webkit.configuration.userContentController.add(self, name: "sampleHandler") self.webkit.load(request) func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { print(message.name) // works print(message.body) // crashes }

I'm in the process of supporting Apple Pay through a 2nd payment gateway for some users, so I need to support two separate Apple Pay relationships. Both require their own apple-developer-merchantid-domain-association. I don't see how I can have both files for the one domain. Is this possible? Is there a workaround other than just replacing the old file with the new one and hoping that doesn't disrupt anything. That seems to be the approach taken by others (https://developer.apple.com/forums/thread/695538) but it is too high risk for me without any confirmation from Apple that this is ok. I'd also like to avoid having to setup a 2nd domain for these customers, since the current domain is already quite embedded in their operations.

The crash is specific to iOS 26.2 WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) Name attribute is accessible but WKScriptMessage body attribute causes crash The object seems to be not accessible

I have a simple website, that I would like to make available as a progressive webapp, so I can somewhat customize what happens when people add the website to their homescreen (using the Share button) and maybe, in the future, use PWABuilder or something similar to publish it in some stores. My website needs authentication using OIDC, which after some redirects within the PWA opens an authenticator app on the phone. When the app returns from authenticating however, it opens a new browser tab instead of my PWA, so there is no context and the login fails. I am under the impression that this used to work, but I'm not sure. I'm also not sure what the problem is, I have no idea how, when the Authenticator app opens a URL (which is what I assume is happening under the hood), iOS or Safari or whatever would know which app to open (as the redirect URL is to the OIDC Idp, not the URL of my Web app). Any hints where I could look for a solution? Thanks!

Hello, We are experiencing a behavior change with WKWebView related to upgradeKnownHostsToHTTPS. Current application, we explicitly disable automatic HTTPS upgrades: let config = WKWebViewConfiguration() config.upgradeKnownHostsToHTTPS = false Observed behavior iOS 17.5 (built with Xcode 15.3) http:// image URLs are not automatically upgraded to https://, and the behavior works as expected. iOS 18.5 / 18.6.x (built with Xcode 16.4) http:// image URLs appear to be automatically upgraded to https:// by WebKit, even when upgradeKnownHostsToHTTPS is explicitly set to false. This behavior occurs for subresource requests such as <img src="http://..."> inside a WKWebView. Question Has the behavior of upgradeKnownHostsToHTTPS changed in iOS 18 / Xcode 16? Is this property now ignored for certain types of subresource requests (e.g. images), or overridden by new WebKit security policies such as mixed-content HTTPS upgrades? Any clarification or official guidance would be greatly appreciated!.

Hi, after upgrading MacOS (MB Air M1 Version 26.2 (25C56)) & Safari (Version 26.2 (21623.1.14.11.9)) to latest versions, we are experiencing a new bug occurring with our web extension (Click & Read) on local storage writing and getting this error : Invalid call to browser.storage.local.set(). Disk I/O error. This doesn't happen on other browsers (chromium, Firefox). export const setLocalStorage = async (value: object) => { try { await browser.storage.local.set(value); } catch (error) { console.error("[Click & Read] Error setting local storage", error); } };

Problem Safari requires tabindex="0" for keyboard access to scrollable containers. Chrome (v130+) and Firefox (v4+) handle this automatically. Current Behavior Chrome/Firefox: Scrollable div with overflow: auto → automatically keyboard-accessible (Tab to focus, Arrow keys to scroll) Safari: Same element → NOT keyboard-accessible unless: Add tabindex="0", OR Container has focusable children Workaround <div style="overflow-y: auto; height: 300px;" tabindex="0"> <!-- content --> </div> Issue: Adds unnecessary tab stops on Chrome/Firefox where not needed. Request Will Safari support auto-focus for scrollable containers? (matching Chrome/Firefox) If not planned: Any official Apple guide for cross-browser scrollable accessibility? Timeline? If on roadmap, estimated Safari version? Can I subscribe for updates? Use Cases Dropdown menus Modal dialogs Tab panels Data tables Chat interfaces Reference: WCAG 2.1 Keyboard Accessible: https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html Example component: https://www.radix-ui.com/themes/docs/components/scroll-area

Since recently, when I try to close a thread I created on an answer of mine, I get the following error: Trying later, next day, does not solve it. In the list of all threads, the post is not marked as answered. But if I look via Chrome or plain Safari, I see the answer itself is marked as correct: Which is not the case when opening in Safari Technology Preview (Release 233) where the same answer is still to be accepted:

WKWebView has a new property "isBlockedByScreenTime" since iOS 26. But I do not yet understand when exactly this property could be used. When I setup content-based restrictions in the ScreenTime settings then WKWebView reports an error 105 via "webView:didFailProvisionalNavigation:" delegate. The isBlockedByScreenTime property still returns false in this case. If ScreenTime has a time-based limit, the App would not run at all. Under which circumstances would the property "isBlockedByScreenTime" return the value true? When exactly and for what can this property be actually used? The "problem" is that I want to find if a web page is blocked and can not be loaded, why this is the case. By simply trial and error I found out that WKWebView returns error codes 104 and 105 for blocked web sites because of content filters and Screen Time restrictions, however these error codes are not documented at all (at least I've not found any documentation or documentation for these error codes and also some other codes like 100, 102, 204 etc), so I'm not really sure if I handle all cases correctly. I hoped that isBlockedByScreenTime would at least tell me one reason for blocked pages. If there are documents which explain these error codes (100 and above), where I can find these?

My iOS app uses a WKWebView with a WKUIDelegate method (webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:) to handle popup windows. This works for most cases, but during OAuth flows on certain sites (e.g., canva.com), the popup WKWebView attempts to send results back to the main WKWebView using JavaScript like window.opener.postMessage(...). However, window.opener is always null in the popup, preventing the message from being posted and blocking login completion.I've researched this and found suggestions that it's by design, as WKWebView instances are isolated for security reasons. Has anyone encountered this and found a reliable workaround (e.g., bridging communication between the main and popup WKWebViews without relying on window.opener)?