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.

WebRTC and Web Audio are essential for modern web applications, powering everything from real-time voice communication to accessibility tools. However, in iOS Safari, these technologies are suspended as soon as the screen locks or Safari goes into the background. This makes web-based calling, live audio spaces, broadcast sessions and assistive applications unreliable for iOS users. Why This Matters: It’s impractical and inefficient. Asking users to keep their screen on to continue a WebRTC call wastes more battery, as the display is one of the most power-intensive components of a device. Allowing WebRTC audio to run in the background would be more battery-efficient than forcing the screen to stay lit for extended periods. Competing platforms allow WebRTC to run in the background. Safari’s restriction puts web-based applications at a disadvantage compared to native apps. Many industries depend on persistent WebRTC audio, including telehealth, live broadcasting, and accessibility tools. This restriction forces developers to build native iOS apps instead of using the open web, limiting web innovation and increasing development costs. Proposed Solution: Apple could implement an explicit user permission for background WebRTC, similar to how background audio playback is already handled for media apps. This would balance user security with the need for uninterrupted real-time communication—without forcing users to keep their screens on unnecessarily. I would love to hear if anyone has found workarounds or if Apple has commented on potential improvements in future iOS versions.

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

hi, I'm having an issue with Safari devlop menu "Web Extension Background Content" menu item being grayed out. I cant do any debugging right now and its becoming mission critical for us. Any help is appreciated. Thank you,

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

We are encountering an issue where the Safari extension we are developing stops working while in use on relatively new iOS versions (confirmed on 17.5.1, 17.6.1, and 18). Upon checking the Safari console, the content script is displayed in the extension script, so the background script or Service Worker must be stopping. The time until it stops is about 1 minute on 17.5.1 and about one day on 17.6.1 or 18. When it stops, we would like to find a way to restart the Service Worker from the extension side, but we have not found a method to do so yet. To restart the extension, the user needs to turn off the corresponding extension in the iPhone settings and then turn it back on. As mentioned in the following thread, it is written that the above bug was fixed in 17.6, but we recognize that it has not been fixed. https://forums.developer.apple.com/forums/thread/758346 On 17.5.1, adding the following process to the background script prevents it from stopping for about the same time as on 17.6 and above. // Will be passed into runtime.onConnect for processes that are listening for the connection event const INTERNAL_STAYALIVE_PORT = "port.connect"; // Try wake up every 9S const INTERVAL_WAKE_UP = 9000; // Alive port var alivePort = null; // Call the function at SW(service worker) start StayAlive(); async function StayAlive() { var wakeup = setInterval(() => { if (alivePort == null) { alivePort = browser.runtime.connect({ name: INTERNAL_STAYALIVE_PORT }); alivePort.onDisconnect.addListener((p) => { alivePort = null; }); } if (alivePort) { alivePort.postMessage({ content: "ping" }); } }, INTERVAL_WAKE_UP); } Additionally, we considered methods to revive the Service Worker when it stops, which are listed below. None of the methods listed below resolved the issue. ① Implemented a process to create a connection again if the return value of sendMessage is null. The determination of whether the Service Worker has stopped is made by sending a message from the content script to the background script and checking whether the message return value is null as follows. sendMessageToBackground.js let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { // If infoFromBackground is null, Service Worker should have stopped. browser.runtime.connect({name: 'reconnect'}); // ← reconnection process // Sending message again infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; Background script browser.runtime.onConnect.addListener((port) => { if (port.name !== 'reconnect') return; port.onMessage.addListener(async (request, sender, sendResponse) => { sendResponse({ response: "response form background", message: "reconnect.", }); }); ② Verified whether the service worker could be restarted by regenerating Background.js and content.js. sendMessageToBackground.js export async function sendMessageToBackground(sendParam) { let infoFromBackground = await browser.runtime.sendMessage(sendParam); if (!infoFromBackground) { executeContentScript(); // ← executeScript infoFromBackground = await browser.runtime.sendMessage(sendParam); } return infoFromBackground.message; } async function executeContentScript() { browser.webNavigation.onDOMContentLoaded.addListener((details) => { browser.scripting.executeScript({ target: { tabId: details.tabId }, files: ["./content.js"] }); }); } However, browser.webNavigation.onDOMContentLoaded.addListener was not executed due to the following error. @webkit-masked-url://hidden/:2:58295 @webkit-masked-url://hidden/:2:58539 @webkit-masked-url://hidden/:2:58539 ③ Verify that ServiceWorker restarts by updating ContentScripts async function updateContentScripts() { try { const scripts = await browser.scripting.getRegisteredContentScripts(); const scriptIds = scripts.map(script => script.id); await browser.scripting.updateContentScripts(scriptIds);//update content } catch (e) { await errorLogger(e.stack); } } However, scripting.getRegisteredContentScripts was not executed due to the same error as in 2. @webkit-masked-url://hidden/:2:58359 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58456 @webkit-masked-url://hidden/:2:58549 @webkit-masked-url://hidden/:2:58549 These are the methods we have considered. If anyone knows a solution, please let us know.

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.

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.

I'd like to know the install state of my iOS safari extension in the associated swift app. Is there any way to get this? As we have seen it is available for macOS here, is there anyway to know iOS Safari extension is enabled or not? Thanks

There does not appear to be any way to use or create iCloud passkeys with a Safari Web Extension, either using the navigator.credentials API in an extension origin webpage such as the popover, or using the AuthenticationServices framework in the SafariWebExtensionHandler. I've setup an associated domain for my plugin, and I know it works for the host application. But I get errors trying to do so in the web extension target. createCredentialRegistrationRequests results in the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier <ID> is not associated with domain <RPID> The other problem, assuming the entitlement works correctly for the web extension, is that there is no NSWindow to use as the presentation target from the SafariWebExtensionHandler. Trying to use the navigator.credentials.create JS API (which is the preferred method, frankly, in a web extension) results in the following error: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Chrome has a great solution for this that I believe should be adopted by Safari. If an extension has host permissions for a relying party it wants to claim, or if it has an associated domain entitlement for it, webauthn operations should be allowed.

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.

We are seeing network errors in Outlook mail on iOS and MacOS safari browsers. As per current investigation, we notice these network error when the user tries to use outlook after leaving it open on Safari for a while. Observations: Issue present in both MacOS and iOS safari. Issue is not present in other webkit browsers like brave and edge on iOS. Issue is reproable on both mini and big owa on safari browser. Issue is not related to post requests being sent in different packets on safari browser. Requests are only blocked for outlook.office/outlook.live domains What does not fix this issue? Reloading the application Clearing cookie, local storage or session storage Unregistering service workers Redirecting to a different page and coming back to outlook domain Re authenticating the users What fixes this issue? Reconnecting to wifi or mobile network Reconnecting vpn Removing safari from background and reopening Flushing the dns in setting

We have a SAML-based SSO App Extension that uses WKWebView to load the SAML login request. This implementation has been working correctly on iOS versions prior to 26. However, starting with iOS 26, the extension consistently crashes when calling WKWebView.load(_:). The crash occurs inside WebKit, specifically in: /Library/Caches/com.apple.xbs/Sources/WebKit/Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp at WebKit::WebPageProxy::loadRequest(...) No app-level exception is thrown, and the extension terminates with: Thread 10: EXC_BREAKPOINT (code=1, subcode=0x1a31dbe00) It appears that WKWebView initialization or WebsiteDataStore creation is now restricted in extension contexts on iOS 26, but this change is not documented in the SDK release notes. Could you please confirm if this is an intentional sandbox restriction in iOS 26 or a regression in WebKit? Steps to reproduce: Implement an App Extension using ASAuthorizationProviderExtensionAuthorizationRequest. Create a WKWebView instance in the extension. Attempt to load a SAML login request (POST request with headers). Observe immediate crash on iOS 26 (works fine on earlier versions). Expected behavior: WKWebView should load the request or fail gracefully as in prior releases, without crashing the extension process. Request: Please clarify if WKWebView usage inside extensions is officially unsupported as of iOS 26, and if so, recommend an alternative approach for handling SSO flows.

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>

Hi, We are facing a major issue with our application. We are using FolioReaderkit to read epub files. Currently, it's working on the iOS 18.1 device and simulator, but it's not working on the iOS 18.2 and later version devices. we are facing this error in Folioreaderkit

I would like to know if there is a way to disable Smart Punctuation from the webpage rather than requiring the user to do so from the settings. Adding a "inputmode=verbatim" attribute to the input HTML tags for my webpage did that for all the web browsers I tested on Windows, Ubuntu, Android, and MacOS. I tested Chrome and Firefox on all platforms, as well as Edge on Windows and Safari on Mac and iOS. So far the only time it did not disable Smart Punctuation was on Safari on iOS, but it did on MacOS.

Hello, In iOS 26 beta, we are seeing an unexpected behavior when using SwiftUI WebView (or a custom WKWebView via UIViewRepresentable). When an alert is presented above the WebView, the WebView immediately reloads to its initial page. The alert itself also disappears instantly, making it impossible for the user to interact with it. This issue occurs both with the new SwiftUI WebView / WebPage API and with a wrapped WKWebView. The problem was not present in previous iOS versions (iOS 17/18). Steps to reproduce: Create a SwiftUI view with a WebView (pointing to any URL). Add a toolbar button that toggles a SwiftUI alert. Run the app on iOS 26 beta. Tap the button to trigger the alert. Expected behavior: The WebView should remain as-is, and the alert should stay visible until the user dismisses it. Actual behavior: As soon as the alert appears, the WebView reloads and resets to the initial page. The alert disappears immediately. Minimal Example: struct ContentView: View { @State private var showAlert = false var body: some View { NavigationStack { WebView(URL(string: "https://apple.com")!) .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close") { showAlert = true } } } .alert("Confirm close?", isPresented: $showAlert) { Button("Cancel", role: .cancel) {} Button("Close", role: .destructive) {} } } } } I'm using Xcode Version 26.0 beta 7 Thanks for your help.

Hello, We’ve been using the CesiumJS WebGL library for several years, both on our website and within embedded WebViews in our iOS application. Since upgrading to iOS versions 18.2 and 18.3, we’ve started receiving numerous user complaints regarding application crashes on various iPad and iPhone models when loading CesiumJS. The crashes occur as soon as the 3D view initializes, and the error consistently reported is: "WebGL context lost" This issue appears to be a WebGL-related crash potentially triggered by GPU memory handling or allocation limits. However, we are not detecting any abnormal memory consumption prior to the crash, and the same setup works perfect on older iOS versions and on all Android devices and versions. Steps to Reproduce: Open: https://www.flightradar24.com/30.47,-94.84/8 Click on any aircraft icon on the map. In the aircraft details panel at the bottom, click on the “3D view” tab. On iOS 18.2 or 18.3, the page will crash shortly after initializing CesiumJS WebGL. Affected Devices: This issue is occurring across a wide range of devices, including: iPad 9th Generation iPad Pro (11-inch, 2nd Gen) iPhone SE (2020 and 2022) iPhone 11, 11 Pro iPhone XR iPhone Mini All of the above are running iOS 18.2 or 18.3. The problem does not occur on Android or previous iOS versions. Request: Has anyone else encountered similar issues with WebGL context loss after upgrading to iOS 18.2 or 18.3? Are there any known changes in memory limits or WebGL behavior in these recent iOS updates? We’d appreciate any insight or suggestions on workarounds or potential fixes. Thank you!