Our current iOS application utilizes WKWebView to display a web application. We've observed intermittent deletion of non-expired 1st-party persistent cookies within this web application, leading to session drops. Here are our environment details and specific questions: Environment: App Build: Built with Xcode 16.2. WebView Class: WKWebView. Cookie Type: 1st-Party Persistent Cookie (Explicit expiration set, not a session cookie). Domain Configuration: The content server and the cookie-issuing server are the same (same IP address, same eTLD+1). The Cookie is set via the Set-Cookie HTTP Header on the server side. Questions: Automatic Deletion Policy: Are there any scenarios (e.g., related to iOS system behavior, Safari policies, or Intelligent Tracking Prevention (ITP)) where iOS or Safari might automatically delete non-expired 1st-party persistent cookies used by WKWebView? Deletion Conditions: If the answer to Q1 is Yes, under what specific conditions (e.g., memory pressure, inactivity, storage limits, specific ITP criteria) does this cookie deletion occur, and does the behavior differ significantly across various iOS versions? OS Update Impact: Are there any known specifications or documented cases where an iOS version update itself triggers the mass deletion of existing cookies stored in the WKWebsiteDataStore? Mitigation Strategy: If this automatic deletion is a known behavior, what mitigation strategies are officially recommended to ensure the persistence of essential 1st-party authentication cookies (e.g., manual synchronization with WKHTTPCookieStore or Keychain/UserDefaults)? Official Documentation: If the answer to Q1 is Yes, please provide URLs to any official Apple documentation or technical notes that detail the specifications or behavior of 1st-party persistent cookie deletion within WKWebView.

Hi, we have PWA for which we´ve built a wrapper using PWA Builder tool and we are experiencing an issue with apple sign in. When we try to redirect the user to "https://appleid.apple.com/auth/authorize?...params...", a bottom sheet login prompt appears and only once the user signs in using the prompt he is then redirected to the url where he needs to sign in again and then we get the callback. We want to get rid of that bottom sheet prompt. The code we´ve tried: ` iosButton.addEventListener('click', function () { window.location.href = "https://appleid.apple.com/auth/authorize?client_id=xxxxx&redirect_uri=xxxxx&response_type=code%20id_token&scope=name%20email&response_mode=form_post"; });` The alternative code we´ve tried for which it seems that nothing happens, we only see the "Started" alert, we´ve confirmed that there is no other error : ` <script src="https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js"></script> <script> (function initAppleSignIn() { try { window.AppleID.auth.init({ clientId: "{{ env('APPLE_WEB_CLIENT_ID') }}", scope: "name email", redirectURI: window.location.origin +"/auth/apple/callback", usePopup: true }); } catch (e) { console.warn('Apple Sign-In init skipped:', e); } })(); function appleButtonClicked() { alert("Started"); try { const res = await window.AppleID.auth.signIn(); } catch (err) { alert("Got error"); } alert("Got here"); } </script>

We have a JavaScript api that queries our Secure Browser to get the network information – signal strength, network name, plugged in/wifi. Everything worked fine through the Tahoe betas, still does. Now we are getting on the network name and this is breaking our UI. Was this an intentional change or a bug? The other two properties still appear to be working. And it works in all lower MacOS versions. We are currently obtaining it through AppleScript try   set ssid to do shell script "system_profiler SPAirPortDataType | awk '/Current Network Information:/ {getline; sub(/^ +/, ""); sub(/:$/, ""); print}'"   if ssid is equal to "" then     return "Not connected to any Wi-Fi network."   else     return ssid   end if on error errMsg   return "Error: " & errMsg end try

"The Safari web extension packager enables you to package and distribute your Safari extensions using App Store Connect from any web browser, without requiring a Mac or access to Xcode." I upload the unzipped folder I'd test in Chrome://extensions to the Safari web extension packager in App store connect. I get error: Embedded binary's bundle identifier is not prefixed with the parent app's bundle identifier. The only solution i've seen to this error involves xcode/a mac, being without which doesn't help

Based on the "Build immersive web experiences with WebXR"-Video for visionOS there is no way to disable the consent prompts for entering an immersive experience or consent hand-tracking. For the microphone it's possible to "greenlight" specific websites for mic input, which works great. I'd welcome it, if it were possible to add specific websites in the settings, in which those consent dialogs aren't shown each time. In my opinion, the user interaction through a button that launches the experience would be sufficient to not disorient.

We’ve noticed that the ApplePaySession.applePayCapabilities() check has stopped working correctly in Safari over the past couple of days. Behavior observed: 1.) In Safari Private Window, paymentCredentialStatus behaves as expected and case 1 is triggered. 2.) In a normal Safari window, it always triggers case 3 (paymentCredentialsUnavailable), even when the user has active cards provisioned in Wallet. We tested across multiple devices, and the behavior is consistent. if (window.ApplePaySession) { var merchantIdentifier = 'YOUR MERCHANT IDENTIFIER'; var promise = ApplePaySession.applePayCapabilities(merchantIdentifier); promise.then(function(capabilities) { switch (capabilities.paymentCredentialStatus) { case "paymentCredentialsAvailable": // Show Apple Pay button as primary option case "paymentCredentialStatusUnknown": // Offer Apple Pay case "paymentCredentialsUnavailable": // Consider showing Apple Pay button case "applePayUnsupported": // Don’t show Apple Pay button } }) } This used to work fine until a few days ago, but now the capability check in non-private Safari windows always indicates unavailable, even with valid active cards. Has anyone else faced this issue recently? Could this be a Safari regression or a change on Apple’s side? Thanks in advance!

Hello, I'm not able to get the webauthn attestation statement using the option (attestation.direct) on Safari. The answer I get is a fmt of none and a aaguid of zeros. The same code works on Chrome and I was able to get a none zero aaguid and a packed fmt attestation. Can you explain why this does not work on Safari ? Thank you.

I don't know why but all of a sudden when I build the extension it just doesn't load in Safari. The build executes fine but the extension doesn't load. Sometimes, through trying different combinations of clearing the build folder, building, archiving, ... it suddenly loads. And the next time I build again it doesn't load properly. So I can't do any work on it or test anything. I don't know why all of a sudden I am getting this behavior. It looks like engineers at Apple are constantly trying to overcomplicate a process that is at least ten times simpler in any other browser. This is ridiculous. Is this what our annual fee goes to? And they don't even provide any support for that. Several times I've tried to get some help here just to have to spend hours upon hours to figure it out by myself. I'm so tired of this.

I'm using the new iOS 26 WebPage/WebView for SwiftUI in a NavigationStack. The initial load works as expected, but when loading items from the back/forward lists, the content jumps beneath the navigation bar: struct WebPageTestView: View { var webPage = WebPage() var body: some View { NavigationStack { WebView(webPage) .toolbar { Button("Back") { if let backItem = webPage.backForwardList.backList.last { webPage.load(backItem) } } Button("Forward") { if let forwardItem = webPage.backForwardList.forwardList.first { webPage.load(forwardItem) } } } } .task { webPage.isInspectable = true webPage.load(URL(string: "https://domchristie.co.uk/")) } } } I have run this on the iOS 26.0 and 26.1 Simulators and get the same issue. The demo website does not use any JavaScript. I was able to replicate this behaviour using a wrapped WKWebView and calling the .ignoresSafeArea(.all) modifier.

When I open the browser in Safari on iOS 26, I want to specify the background color for the header notch (where the time, battery, etc. are displayed) and the footer indicator area. Specifying the theme color in HTML as shown below did not change anything. <meta name="theme-color" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000"> The HTML below specifies the background color as green, but is it necessary to specify the background color directly in the body like this? Or is there some kind of metadata, like theme color? <!doctype html> <html lang="ja"> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width,initial-scale=1" /> <meta name="theme-color" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000"> <meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000"> <title>サンプル</title> </head> <body style="background:#00ff00"> <main> <p>テキスト</p> </main> <div id="overlay" role="dialog" aria-modal="true" data-test-id="health-warning-modal" style=" color:#000000; position:fixed; inset:0; z-index:30000; background:#2563eb; display:grid; /* 初期表示：表示中 */ align-items:center; justify-content:center; overflow-y:auto; " > <div style=" padding:60px 16px; display:flex; flex-direction:column; gap:20px; width:100%; box-sizing:border-box; " > <p style=" font-weight:700; text-align:center; margin-top:20px; font-size:28px; line-height:1.4; " > オーバーレイ </p> </div> </div> </body> </html>

Is this symbol, which Safari uses to the left of the address bar, in the public SF Symbols set? What's it called?

Hi guys, I'm trying to use sign in with apple in javascript, I followed the guider in the website, and almost find everything I can find in Google, but nothing help, here is my situation: I create a new App: com.yuhan.test.app I create a new service ID: com.yuhan.test.service configure a domain and return url domain: tts.perterpon.com returnURL: https://tts.perterpon.com/login create a new key for Sign In with Apple. my html code is here, it's easy, but it always told me invalid_client, I think I have done anything I need to do, can somebody help me? Thank you so much. you can test my online web site: https://tts.perterpon.com/login.html ` const buttonElementNew = document.getElementById('appleid-signin'); buttonElementNew.addEventListener('click', async () => { try { const data = await AppleID.auth.signIn() console.log('Try/Catch Data', data.authorization.id_token); const formData = new FormData(); formData.append("token", data.authorization.id_token); await fetch("", { method: "POST", body: formData, }); // Handle successful response. } catch (error) { // Handle error. } }); </script>

We’re seeing an issue in our Safari Web Extension where not all cookies from the Set-Cookie response header are accessible. We are using macOS 15.4 and Safari 18.4. In the webRequest.onHeadersReceived callback, the Set-Cookie header returned by Safari only includes some of the cookies set by the server. If multiple Set-Cookie headers are present, we seem to receive only a partial list, some cookies are missing entirely. In Chrome and Firefox, the same callback provides all cookies set by the server without issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

Hi, I am developing an OpenType font with the following cursive feature. feature curs { lookup cursivejoinrtl; # RIGHT_TO_LEFT flag set between Hah, Meem, Yeh and final Meem lookup rehwawcursive; # RIGHT_TO_LEFT flag clear between Waw and Hah } curs; Here is the rendering of the word وحميم in TextEdit. Using HarfBuzz I got the following result. The same rendering problem occurs when using Safari. It seems that is related to Core Text. I reported the issue to Feedback Assistant over a year ago but haven't had a response yet. So I'm posting the problem on this forum. Any support on this matter would be greatly appreciated.

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: (...)

I'm not loving the huge Favorites icons in Safari on MacOS 26, is there a way to reduce the size of them so that we can see more favorites on the list without scrolling down?

After updating to Safari 26.0 (on macOS Sequoia or Tahoe), the Declarative Net Request (DNR) API rule with "type": "redirect" no longer works as expected. When the rule is applied, the browser initially shows a banner at the top of the page: "This webpage was reloaded because a problem occurred." After the reload, the page fails to load and displays an error page with the message: "A problem repeatedly occurred with https://extensionworkshop.com/?test=true " This behavior is new in Safari 26.0. The same rule was working correctly in earlier Safari versions (17.x / 18.x).

I have observed Safari App starts crashing when running with my safari extension. Our Safari extension polls the host app every 60s. The extension receives and completes requests in func beginRequest(with context: NSExtensionContext) (we always call context.completeRequest(...)). The crash is intermittent: beginRequest itself does not throw. Looking for guidance about likely causes. I am attaching the snippet from crash report. Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace RUNNINGBOARD, Code 3490524077 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1856f5c34 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1857083a0 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x1856fe764 mach_msg_overwrite + 484 3 libsystem_kernel.dylib 0x1856f5fa8 mach_msg + 24 4 CoreFoundation 0x185822cbc __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1858215d8 __CFRunLoopRun + 1208 6 CoreFoundation 0x185820a98 CFRunLoopRunSpecific + 572 7 HIToolbox 0x1912c327c RunCurrentEventLoopInMode + 324 8 HIToolbox 0x1912c64e8 ReceiveNextEventCommon + 676 9 HIToolbox 0x191451484 _BlockUntilNextEventMatchingListInModeWithFilter + 76 10 AppKit 0x189745a34 _DPSNextEvent + 684 11 AppKit 0x18a0e4940 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 12 Safari 0x1b801cce4 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 228 13 AppKit 0x189738be4 -[NSApplication run] + 480 14 AppKit 0x18970f2dc NSApplicationMain + 880 15 Safari 0x1b83dd0b0 SafariMain + 468 16 dyld 0x185396b98 start + 6076

I'm working on a Safari web extension that uses the nativeMessaging facility to communication with native code. When I want to notify the javascript extension from the embedding application, I use SFSafariApplication::dispatchMessage. As per the documentation, this call ... ensures that Safari is launched and that your extension is running before delivering the message. Everything works fine when the background script is running. However, after the background script gets unloaded at some point in time (non persistent background page, default behavior for a manifest V3 extension), the background script is not reloaded by the message from the native app (background script still appears unloaded in the developer menu of Safari, double-checked using a counter stored in browser.storage.local incremented on message reception). In this case, the completion handler of the application gets no error (error == nil) as if the message was correctly delivered. I was able to reproduce this behavior with the sample app delivered for WWDC20 (after upgrading the manifest from v2 to v3 to make it non-persistent). Is it supposed to work ? What I'm doing wrong ?

I recently upgraded my device from IOS 18.4 to IOS 26. My web extension has disapeared from safari. I can see it in Settings > Apps > Safari > Extensions and when I turn it on and re-open safari. I just get a mesasge that says "{extension name} is no longer avaiable". I have tried Manifest V2 and Manifest V3 both yield the same results. The current production extension bundled with the IOS app has the same problem. I can no longer use or test my own extension !? Help please !