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.

hi Testing on OS26 Public Beta 6. In Safari, if you enter x homepage and scroll, the tab bar sticks to the bottom and moves. Make the keyboard appear in the search window When scrolling down on the Safari homepage again, the issue of not being able to stick to the bottom appears. Is it because the liquid glass UI was applied this time? and safari bug? Please let me know if I'm missing anything

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

Our app encountered a new crash since beta5(23A5308g) released last week,and it seems the crash is not solved yet in beta6(23A5318c).The crash stack below `-[UIView _backing_setPosition:] -[UIView setCenter:] -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ___54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] -[_UIEditMenuContentPresentation _displayMenu:reason:] -[_UIEditMenuContentPresentation displayMenu:configuration:] ___58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ___80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ___109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ___107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) WTF::Detail::CallableWrapper<IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)> >(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::{lambda(IPC::Connection*, IPC::Decoder*)#1}, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRefIPC::Encoder&&, WTF::OptionSetIPC::SendOption, std::__1::optionalIPC::ConnectionAsyncReplyHandler, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) IPC::Connection::dispatchIncomingMessages() WTF::RunLoop::performWork() WTF::RunLoop::performWork(void*) _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ___CFRunLoopDoSource0 ___CFRunLoopDoSources0 ___CFRunLoopRun __CFRunLoopRunSpecificWithOptions _GSEventRunModal -[UIApplication _run] _UIApplicationMain main main.m start

When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?

Hey Guys My PWA video playback and even youtube videos stopped working after updating iOS to 26.0.1. The video thumnails appear fine and if i try to play the video, it remains stuck. If i restart the phone, the video plays for a second in the PWA and then stops again and entire app gets stuck. Request apple team to fix this issue at the earliest. This is hampering all my iOS users who install the PWA on their device homescreen and use it as app. FYI strangely EVERYTHING WORKS FINE ON iOS SAFARI browser including videos playback If i open it as a web app. so this seems like a specific PWA issue on latest ios 26.0.1

We’re currently working on an OTT-based application where we integrate Google Ad Manager to serve video ads. As part of the ad experience, users often see a “Learn More” CTA (Call to Action) on these ads. As per our current requirement, when a user taps “Learn More” on an ad: • The link should open in Safari (i.e., an external browser) on iOS devices • The Safari browser should ideally open in portrait orientation, as the ad content and layout are optimised for portrait mode However, based on our understanding and technical constraints on iOS, it appears that: • Orientation control is restricted to the app’s own context. • Once Safari is launched via UIApplication.shared.open, we no longer have control over how it behaves in terms of orientation. • iOS system behaviour determines Safari’s orientation based on the device’s physical orientation and Safari’s own internal configuration. Could you please confirm if there’s any supported way (via SDK, deep link config, or otherwise) to enforce portrait orientation in Safari when opening such external URLs from within an iOS app? If this is not technically feasible, we would appreciate any best practices or alternatives you can suggest for ensuring a consistent user experience.

Hello Apple Developer Community, I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26. Problem Description: I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior: PDF links should remain clickable and functional across all iOS versions. What I've Tried: Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps: Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment: Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2 Questions: Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity? Any guidance or suggestions would be greatly appreciated!

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)?

Adding Stack Trace for your reference: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1a6efe5b8) frame #0: 0x00000001a6efe5b8 WebCoreWebCore::BaseAudioSharedUnit::BaseAudioSharedUnit() + 668 frame #1: 0x00000001a6efe044 WebCoreWebCore::CoreAudioSharedUnit::singleton() + 80 frame #2: 0x00000001a9521fe4 WebCoreWebCore::CoreAudioCaptureSource::create(WebCore::CaptureDevice const&, WebCore::MediaDeviceHashSalts&&, WebCore::MediaConstraints const*, std::__1::optional<WTF::ObjectIdentifierGeneric<WebCore::PageIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>>) + 360 frame #3: 0x00000001a94f180c WebCoreWebCore::RealtimeMediaSourceCenter::getUserMediaDevices(WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WebCore::MediaConstraintType&) + 356 frame #4: 0x00000001a94f22cc WebCoreWebCore::RealtimeMediaSourceCenter::validateRequestConstraintsAfterEnumeration(WTF::Function<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&, WTF::Function<void (WebCore::MediaConstraintType)>&&, WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&) + 356 frame #5: 0x00000001a94fb394 WebCoreWTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::enumerateDevices(bool, bool, bool, bool, WTF::CompletionHandler<void ()>&&)::$_0, void>::~CallableWrapper() + 164 frame #6: 0x00000001a814bbe8 WebCoreWTF::Detail::CallableWrapper<WebCore::AVCaptureDeviceManager::refreshCaptureDevicesInternal(WTF::CompletionHandler<void ()>&&, WebCore::AVCaptureDeviceManager::ShouldSetUserPreferredCamera)::$_0::operator()()::'lambda'(), void>::call() + 520 frame #7: 0x00000001ab7f1aac JavaScriptCoreWTF::RunLoop::performWork() + 524 frame #8: 0x00000001ab7f1880 JavaScriptCoreWTF::RunLoop::performWork(void*) + 36 frame #9: 0x00000001935e7d0c CoreFoundationCFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #10: 0x00000001935e7ca0 CoreFoundation__CFRunLoopDoSource0 + 172 frame #11: 0x00000001935e6a24 CoreFoundation__CFRunLoopDoSources0 + 232 frame #12: 0x00000001935e5c64 CoreFoundation__CFRunLoopRun + 840 frame #13: 0x000000019360a730 CoreFoundationCFRunLoopRunSpecific + 572 frame #14: 0x00000001e0fb5190 GraphicsServicesGSEventRunModal + 168 frame #15: 0x0000000196239f34 UIKitCore-[UIApplication _run] + 816 frame #16: 0x0000000196238164 UIKitCore`UIApplicationMain + 336 frame #17: 0x000000010811bec4 AppName.debug.dylibmain at AppDelegate.swift:25:13 frame #18: 0x00000001bae06a58 dyldstart + 5964

This is my first post, so please forgive me if it is to the wrong area. I've been using Tahoe for a few days and, overall, it's very stable. But the one thing that has bothered me to no end is Safari's new behavior with respect to its header (Address bar, Favorite bookmarks bar, tab bar) background color. The web content of the active tab seems to affect everything - and oftentimes makes things completely unreadable - at least in "Dark" mode. For instance, if a web page uses a white background, the Favorites bookmark labels are the same color as the bookmark background, so reading the labels is simply impossible. At other times, they're just very difficult to read. Similarly, it is almost always impossible to tell which tab is the active one - my only workaround is to try 100% brightness....or to just guess. When Apple previously experimented with letting content bleed through to the top, there was a setting for stopping it - but I don't see such a setting anymore. Do you you know of any way to stop this effect?

Despite using the iPad in landscape mode, self-camera video is forced to portrait (Rotate 90 degrees). Only the video is portrait, even though the browser is in landscape orientation. Our app use getUserMedia() to get the video. The problem also happend in iPad Safari GoogleMeet. Details: The problem occurs even when the screen orientation is locked. After the video has been forced to portrait, rotating the iPad temporarily changes the video to landscape, but forces it to portrait again. It takes around 0 - 30 seconds before the video is forced to portrait. Both selfie camera and back camera I have confirmed this problem on the following devices iPad 8th iPadOS: 18.3.1 iPad10th iPadOS:18.3.1 iPadPro(M4) iPadOS:18.3.1 Some devices do not have this problem, even if they are the same model and OS version. I have tried the following restart factory reset Configuration changes (Settings > Apps > Safari) SETTINGS FOR WEBSITES Camera > Allow, Ask Microphone > Allow, Ask Advanced ＞ Feature Flags Reset All to Defaults Screen Orientation API (Locking / Unlocking) Screen Orientation API WebRTC AV1 codec Please help me to resolve this problom. Thanks.

I have a very specific issue that happens only on iOS Simulator version 18.4. It does NOT happen when I run my app on a real iOS 18.4 device through Testflight. My app displays a WebView (courtesy of Capacitor, url scheme capacitor://). Inside that Webview I'm using Firebase JS API (11.2.0) and calling signInWithEmailAndPassword, which works well in all other contexts, i.e. browser, Android webview, iOS webview in all other Simulator versions, and on real devices. Only when running in Simulator 18.4, I get a failed network request: cannot parse response Fetch API cannot load https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?... due to access control checks. Failed to load resource: cannot parse reponse error: FirebaseError: (auth/network-request-failed) Everything is working correctly for both: Capacitor app webview installed on a real 18.4 device with Testflight Safari (non-webview) in the 18.4 Simulator The issue is severe for us, because we are unable to develop our app and test it in the simulator on 18.4 Simulator before pushing it through Testflight internal release. Request headers on the failed request (no response status or headers available). Request Accept: / Content-Type: application/json Origin: capacitor://localhost Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: cross-site User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) - AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 X-Client-Version: Mobile/JsCore/11.2.0/FirebaseCore-web X-Firebase-Client: (...)

Create shortcut to open chrome with url and put it on the desktop. Tap the shortcut. Tap the username text field. When launching Safari from an iOS shortcut on an iOS device with a valid passkey registered, the passkey suggestion does not appear; instead, the password suggestion appears sometimes.

Typically, you can use the @@extension_id special string to reference the absolute path into the bundled resources of an extension, such as an image or a custom font, in a CSS file. However, this broke with Safari 18. Consider this section in a popup.css file: .card-icon { height: 16px; width: 20px; background-image: url(safari-web-extension://__MSG_@@extension_id__/images/card.svg); background-size: 20px 16px; } In Safari 17.4, once loaded in the browser, @@extension_id is replaced with E8BEA491-9B80-45DB-8B20-3E586473BD47, and the background-image reads as so: background-image: url(safari-web-extension://E8BEA491-9B80-45DB-8B20-3E586473BD47/images/card.svg); But as of Safari 18, the @@extension_id just collapses to an empty string, and the background-image reads as so: background-image: url(safari-web-extension:///images/card.svg); and the svg fails to load with the following error: "Failed to load resource: You do not have permission to access the requested resource." This is a regression, does to match the behavior of the other major browsers, and should be fixed. Filed with Feedback ID: FB15104807

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?

I'm trying to sync authentication data from my iOS app to a Safari Web Extension using App Groups, but the extension isn't consistently receiving the data. Setup: App Group: group.com.airaai.AiraApp (configured in both app and extension) iOS app writes auth data using UserDefaults(suiteName: "group.com.airaai.AiraApp") Extension's Swift SafariWebExtensionHandler reads from App Groups in beginRequest() Extension's JavaScript reads from browser.storage.local Problem: Extension popup always shows "logged out" even when: User is logged into main iOS app Auth data exists in App Groups (verified via native module logs) Handler successfully writes test values to extension storage Current Behavior: Handler CAN read from App Groups ✅ Handler CAN write test values to extension storage ✅ But auth data doesn't appear in browser.storage.local when popup checks ❌ Popup reads empty keys even though handler logged writing them Code: // Handler reads from App Groups guard let sharedDefaults = UserDefaults(suiteName: "groupName") else { return } let authData = sharedDefaults.string(forKey: "auth_data") // Handler writes to extension storage (tried multiple suite names) let extensionDefaults = UserDefaults(suiteName: Bundle.main.bundleIdentifier ?? "") extensionDefaults?.set(authData, forKey: "oauth_token") extensionDefaults?.synchronize() // Popup reads from storage browser.storage.local.get(['oauth_token']).then(data => { console.log(data); // Always empty {} }); What I've tried: ✅ App Groups properly configured in both targets ✅ Extension has App Groups capability enabled ✅ Multiple UserDefaults suite names (bundle ID, bundle ID + suffix) ✅ Delayed sync attempts in handler ✅ Comprehensive logging Questions: What is the correct UserDefaults suite name for Safari extension storage on iOS? When does beginRequest() get called? Can it be triggered manually? Is App Groups the right approach, or should I use a different pattern? Alternatives I've considered: Deep link/redirect method (app opens Safari with token in URL) Content script intercepts URL and sends to background script Is this a supported approach for iOS Safari extensions? Any guidance or examples would be greatly appreciated!

Hello We've encountered an issue with WKWebView in the latest iOS 26 beta. When loading a PDF URL, the background of the PDF viewer now displays as a dark gray instead of the expected white. Device: iOS 26 Simulator/Device Component: WKWebView Issue: The background color of the loaded PDF is gray. Expected Behavior: The background should be white, as it has been in all previous iOS versions. Link for Testing: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf We confirmed that the same PDF and code render with a white background on iOS 26 and earlier. Questions: Is this an intentional change in iOS 26's WKWebView? If so, is there a new property or configuration setting available to control the background color of the PDF viewer within WKWebView? We would like to have the ability to set it back to white. Any insights, workarounds, or information on this matter would be greatly appreciated. Thank you.

PLATFORM AND VERSION iOS Development environment: Xcode 16.2, macOS 15.3.2 Run-time configuration: iOS 15-18 This happens in iOS, and leads to to the hybrid home page showing users as wrongly unauthenticated, since the at cookie is missing. For context, we have a JWT token that is stored in the Keychain, and on app launch, before any WKWebViews are created, we synchronize this to the WKWebsiteDataStore as an at cookie. We have analytics instrumentation on our websitef to show that WKWebView randomly refuses to send out any cookies. – The following is a snippet from an explanation to the WebKit Slack: We are having an issue on iOS, in which WKWebView loads pages (and even subsequent reloads) without any cookies, even though we have stored cookies in WKWebsiteDataStore.default() before hand right after application launch and becoming a key window. We reference this object, store it as a singleton, (as well as a process pool), and then all webview configurations are initialized with the same data store, the same process pool, every call on the main thread. From reading the source code, it seems that if the internal IPC logic fails, the APIs for deleting and setting data records and cookies fail without any feedback in completion handlers. This bug often happens when returning from the background on iOS after a few hours. Sometimes it happens on cold launches of the app. We have mitigated a similar issue (no cookies being sent) by implementing webViewWebContentProcessDidTerminate and reloading the webview ourselves, we found that whatever webview does to reload if that method is not implemented leads to cookies not being used. There have been multiple reports of WKWebView losing cookies in recent iOS versions, and we have tried to implement all of the workarounds listed. Setting a maximumAge to the cookies we store, and doing a _ = await websiteDataStore.dataRecords(ofTypes: Set([WKWebsiteDataTypeCookies])) before accessing or modifying websiteDataStore.httpCookieStore Question: is it safe to work with WKWebsiteDataStore before a WKWebView is added as a view, if so are there any timing considerations? Are there any logs that we can take a look at, this issue is very hard to reproduce, about 2% of our users face it at scale? Is there anything that could be happening within our process (runloop issues, timing) that could be causing this issue? See multiple reports from other companies that have faced the issue: "Now the Thermonuclear Problem with WKWebViewDataStorage" https://medium.com/axel-springer-tech/synchronization-of-native-and-webview-sessions-with-ios-9fe2199b44c9 STEPS TO REPRODUCE They don't exist, because the issue only happens at scale. We just know that no cookies are sent for a small percentage of requests. We believe this to be an issue in which Webkit fails to communicate internally with whatever IPC mechanisms it has. We have not been able to reproduce this issue consistently. The best we can give is that it happens after a few hours that the app is in the background. This happens regardless of whether the WKWebsiteDataStore is persistent or not, but seems to be much worse when it is persistent. Thus we have disabled persistnet data stores and relied on nonPersistent. The issue is bad enough that we are trying to move away from relying on cookies for iOS and just use request headers which we can only set on the top level request of WKWebView. DTS Case-ID: 13154329

It seems fetch() does not include credentials (cookie) even when credentials: include is used and Safari extension has host_permissions for that domain when using from a non-default Safari profile. It includes credentials (cookie) when using from the default profile (which has the default name Personal). Is there anyone who has this problem? I try to request in popup.js like this: const response = await fetch( url, { method: 'GET', mode: 'cors', credentials: 'include', referrerPolicy: 'no-referrer', } ); and it does not include the credentials (cookie) from host_permissions. I already posted https://developer.apple.com/forums/thread/764279, and opened feedback assistant (FB15307169). But it is still not fixed yet. (macOS 15.4 beta 3) I hope this is fixed soon.