Subject: Unexpected system confirmation dialog when opening a Universal Link Description of the issue: We’re implementing a login flow using Native iOS apps, Universal Links, and OpenID Connect authentication. Our domain is correctly configured with the apple-app-site-association file, and Universal Links work as expected. However, under certain circumstances, the behavior differs on the same login page: The user connects to the OIDC provider in their mobile browser. Instead of automatically switching to the Native application, a popup asks the user to open the app. The behavior depends on how the login page is opened: When opened in a new browser tab, the Universal Link opens the app immediately without showing any system confirmation dialog. When the same tab is reused without a page refresh, iOS displays a system confirmation dialog asking the user to open the link in the app. This confirmation dialog doesn’t appear in the first scenario. This additional system dialog impacts the user experience, as we aim for a frictionless and seamless login flow with minimal confirmation steps. Question: Why does the app switch work automatically only the first time? Is this intentional iOS behavior? If so, what security requirement or system rule causes a confirmation dialog when reusing the same tab, but not when redirecting in a new tab or pressing a button on the reused tab? Is this expected design, or should we adjust our side to avoid this dialog? Environment details: Verified on two devices iOS versions: 18.7.2, 26.1 Thanks for your help.

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.

overflow-x: clip; will also apply clipping on the Y-axis. The correct implementation of this should only affect the X-axis. This is correctly implemented in all browsers except for Safari

I'm a web developer of WebRTC based web app for video and audio calls. After updating to iOS 26.1 beta I noticed, that my app can't use microphone anymore. When I'm calling to getUserMedia with audio set to true, Safari returns error "No AVAudioSessionCaptureDevice device". Other WebRTC demo apps also can't access microphone on this firmware. And maybe it's connected somehow, but safari can't detect connected AirPods Pro 2 as an input device. So, this bug brakes any WebRTC app, that uses microphones.

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:

I'm working on a web browser App that's distributed via the App Store. This app renders web pages using WKWebView. Our users are requesting a way for us to allow them to play videos in Picture in Picture. After some investigation, we noticed that in order to allow PiP videos in our browser in the sandboxed environment, we need to add the com.apple.PIPAgent entitlement under the com.apple.security.temporary-exception.mach-lookup.global-name option. We tried to submit our app with this entitlement, but unfortunately, we were rejected: Guideline 2.4.50) - Performance We've determined that one or more temporary entitlement exceptions requested for this app are not appropriate and will not be granted: com.apple.security.temporary-exception.mach-lookup.global-name com.apple.P|PAgent We would like to have access to this entitlement so we can offer PiP to our users. We already created a radar about this as well: FB13814428 Additionally, we have another radar (FB13557716) regarding allowing the usage of a private flag _allowsPictureInPictureMediaPlayback, which would also be required to enable us to use PiP. Is there any way in which we can currently enable PiP? Would opening a TSI help here?

Trying to implement my own forward/back buttons for the new SwiftUI WebView and reading the documentation I’m totally lost. What’s the recommended way of implementing forward/back behavior with this component?

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

Starting with iOS 26.2, when Safari tabs are set to Bottom or Compact view, some pages are not rendering properly. The error does not occur in Top view. For some pages, scrolling causes rendering to be very slow, causing the user to experience page breaks and missing parts. If the user waits a few seconds, the missing parts of the page will appear, but the issue will reoccur when scrolling further. We have tested this on all available iOS devices and the issue occurs on all iPhones running iOS 26.2. The issue does not occur on iOS 26.1, and we have not experienced it on devices running iOS 18. The issue can be reproduced on the following pages with an iPhone running iOS 26.2: https://fotosakademia.hu/products/course/fotografia-kozephaladoknak-haladoknak https://oktatas.kurzusguru.hu/products/course/az-online-kurzuskeszites-alapjai

I’m experiencing a crash in WKWebView on iOS 26 Developer Beta 5 and Beta 6 with the following exception: CALayer position contains NaN: [nan 65] The crash occurs when the following CSS properties are applied to content displayed in WKWebView: -webkit-user-select: none; -webkit-touch-callout: none; This issue happens consistently whenever these styles are set, leading to the crash inside WKWebView. Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?

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.

使用direct distribution进行分发时，safari web extension 在safari setting 中显示没有权限读取、修改或传输任何网页的内容。 但是我在看公证日志显示插件是正常的公证的 这导致safari extension 无法使用。 公证日志 https://www.coupert.com/img/2025-04-10/notarization-log.json

Hi Apple engineers! We are making an iOS browser and are planing to deliver a feature that allows enterprise customers to use a MAM key to set a PAC file for proxy. It's designed to support unmanaged device so the MDM based solutions like 'Global HTTP Proxy MDM payload' or 'Per-App VPN' simply don't work. After doing some research we found that with WKWebView, the only framework allowed on iOS for web browsing, there's no API for programmatically setting proxy. The closes API is the WKURLSchemeHandler, but it's for data management not network request interception, in other word it can not be used to handle HTTP/HTTPS request well. When we go from the web-view level to the app level, it seems there's no API to let an app set proxy for itself at an app-level, the closest API is Per-App VPN but as mentioned above, Per-App VPN is only available for managed device so we can't use that as well. Eventually we go to the system level, and try to use Network Extension, but there's still obstacles. It seems Network Extension doesn't directly provide a way to write system proxy. In order to archive that, we may have to use Packet Tunnel Provider in destination IP mode and create a local VPN server to loop back the network traffic and do the proxy stuff in that server. In other word, the custom VPN protocol is 'forward directly without encryption'. This approach looks viable as we see some of the network analysis tools use this approach, but still I'd like to ask is this against App Store Review Guidelines? If the above approach with Network Extension is not against App Store Review Guidelines, I have a further question that, what is the NEProxySettings of NETunnelNetworkSettings for? Is it the proxy which proxies the VPN traffic (in order to hide source IP from VPN provider) or it is the proxy to use after network traffic goes into the virtual private network? If none of the above is considered recommended, what is the recommended way to programmatically set proxy on WKWebView on an unmanaged device (regardless of where the proxy runs, web-view/app/system)?

Since iOS 18.1 launched as a beta, we've been getting reports from end users on iPhone 15 Pro and iPhone 15 Pro Max specifically. They're reporting that our WebView is unable to load our local HTML content. I'm curious if anyone else has had their app or users run into this issue? So far I've tried installing the most recent XCode Beta 16B5014f and installed an 18.1 emulator, but our app worked fine. It's also working fine on all my real devices, but we don't have a 15 Pro to test on. I'm curious if this is related to the processor on these devices and how they are intended to support Apple's new AI coming in 18.1.

iPadOS 26, dark mode Open Safari Search for anything or open a website that has white background Kill Safari Open Safari again I still can reproduce it with Safari on iPadOS 26.0.1 This issue also happens to my app when opening a HTML/JS on WKWebView with white background while using dark mode. I did send a feedback ticket when using iPadOS 26 beta but havent seen any reply. This is my first time sending a feedback so I dont know if Apple would reply or not.

Hi, My app is using JavascriptCore to run the business logic in a javascript environment. We are randomly seeing crashes when users move the app back to the foreground. These crashes are reported by Firebase (I am attaching an example). I also tried to find them in Organizer, but the stacktraces don't match and I am not sure if they are pointing to the same error (I attach one just in case). I was trying to investigate a little bit about this, but I could find any explanation about what pas_reallocation_did_fail would mean. Here is our implementation: -(void) enqueueCallback:(JSValue *)callback withArguments:(NSArray *)args exclusive:(BOOL)exclusive { [self enqueueBlock:^{ @autoreleasepool { [callback callWithArguments:args]; } } exclusive:exclusive]; } Basically, every JS block is enqueued and then run by a dedicated thread specific to our JSContext. Can I get some help? Thanks in advance! Crashlytics.txt 2024-08-30_10-00-01.2572_-0400-f757f8306eda9679ec1b2ff90fbc66c4eb1fbee7.crash

Hi, I have an app that uses WKWebView and it's crashing on iOS 26 Simulator in places I've never had problems before. In this case it's crashing when calling WKWebView.callAsyncJavaScript, but in my other project WKWebView is crashing with some sort of EXC_BAD_ACCESS other than callAsyncJavaScript. Am I missing something? Thanks,

Hi all, I'm currently working with WKWebView and implementing the WKNavigationDelegate protocol. In particular, I'm trying to inspect the sourceFrame of a WKNavigationAction to make navigation policy decisions based on the frame's URL path. Here's the relevant Swift code inside decidePolicyFor: public func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, preferences: WKWebpagePreferences, decisionHandler: @escaping (WKNavigationActionPolicy, WKWebpagePreferences) -> Void) { // ... let sourceFrame: WKFrameInfo = navigationAction.sourceFrame let request: URLRequest = sourceFrame.request // <- SIGABRT occurs here // ... } The issue is that the app crashes with a SIGABRT at runtime when attempting to access sourceFrame.request. According to Swift's type system, neither sourceFrame nor its request property are optional, so at first glance this seems safe. However, the crash report suggests otherwise. From the crash log, it appears that the issue arises during the bridging from Objective-C to Swift: Thread 1 Queue : com.apple.main-thread (serial) #0 0x00000001a127a030 in static Foundation.URLRequest._unconditionallyBridgeFromObjectiveC(Swift.Optional<__C.NSURLRequest>) -> Foundation.URLRequest () #1 0x00000001056c48b0 in CustomWebViewController.webView(_:decidePolicyFor:preferences:decisionHandler:) #2 0x00000001056c4c78 in @objc CustomWebViewController.webView(_:decidePolicyFor:preferences:decisionHandler:) () #3 0x00000001b8c66e0c in WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction () #4 0x00000001b8fd14dc in WebKit::WebPageProxy::decidePolicyForNavigationAction () #5 0x00000001b8fcfc7c in WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared () #6 0x00000001b8fcfb18 in WebKit::WebPageProxy::decidePolicyForNavigationActionAsync () #7 0x00000001b87ddaa0 in WebKit::WebPageProxy::didReceiveMessage () #8 0x00000001b869f474 in IPC::MessageReceiverMap::dispatchMessage () #9 0x00000001b878dda4 in WebKit::WebProcessProxy::dispatchMessage () #10 0x00000001b878d614 in WebKit::WebProcessProxy::didReceiveMessage () #11 0x00000001b869e7e4 in IPC::Connection::dispatchMessage () #12 0x00000001b869e358 in IPC::Connection::dispatchIncomingMessages () #13 0x00000001b9a96a44 in WTF::RunLoop::performWork () #14 0x00000001b9a96688 in WTF::RunLoop::performWork () #15 0x00000001a2428b9c in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #16 0x00000001a24289b4 in __CFRunLoopDoSource0 () #17 0x00000001a2428810 in __CFRunLoopDoSources0 () #18 0x00000001a2429190 in __CFRunLoopRun () #19 0x00000001a242ad4c in CFRunLoopRunSpecific () #20 0x00000001ef705454 in GSEventRunModal () #21 0x00000001a4e45890 in -[UIApplication _run] () #22 0x00000001a4e10cec in UIApplicationMain () #23 0x00000001a4ef261c in ___lldb_unnamed_symbol275689 () #24 0x00000001059a5104 in static UIApplicationDelegate.main() () #25 0x00000001059a5074 in static AppDelegate.$main() () #26 0x00000001059a82ec in main () #27 0x00000001c940af0c in start () This implies that while Swift treats sourceFrame.request as non-optional, the underlying Objective-C implementation may actually return nil—leading to a crash when the non-optional Swift type attempts to force unwrap it. My question: Is there a way to safely access navigationAction.sourceFrame.request —- or determine if it’s nil—before Swift attempts the implicit bridging from Objective-C? Or is there an established workaround for safely inspecting this property? Any guidance or best practices for avoiding this crash would be greatly appreciated! Thanks in advance.

As with the adoption of MV3 standards among all major browser vendors that allow browser extensions at the client-side, I understand that this is the same with Safari as well, as mentioned here (https://www.wwdcnotes.com/notes/wwdc22/10099/). However, as with Firefox, browsers may choose to adopt them incompletely and with few changes. I had a few questions regarding how Safari views this transition and what would be the next steps from here. Thus, it would be really great if the browser team could provide your insights on any or all of the following points: Would Safari adopt the exact standards proposed by the Chromium ecosystem such as with functionalities like header-based modifications in the coming days.  What would be the general timeline be for this in general?  Does this also translate to the fact that existing standards with MV2 standards would not be allowed to operate any further, as with the timeline with Chromium? Regards

Hello, According to the documentation: If you provide your extension in macOS and don’t want to use the Mac App Store for distribution, you can sign and notarize your extension’s app with a Developer ID to distribute it outside the Mac App Store. However, I found this to be untrue in practice. Even after signing and notarising the Safari extension correctly, it is not possible to enable it in Safari without turning on "allow unsigned extension". This makes it impossible to distribute your Developer ID–signed and notarized extension outside the Mac App Store. I would like to distribute my web extension directly to employees in my organization using MDM without having each user manually enable "allow unsigned extension" for it to work. Any way to make it work? The documentation is quite confusing in this aspect, it says "Safari only supports signed extensions" but my extension is rejected even if notarised and signed.