Summary When an app is associated with a domain via applinks in the Apple App Site Association (AASA) file, the app's icon is displayed next to passkey entries in the iOS passkey selection UI (e.g., in Safari's sign-in dialog). This occurs even when: The AASA file does not contain a webcredentials section The passkey's relying party ID (rp.id) matches the domain, but the app has no webcredentials association The URL path of the passkey login page does not match any paths specified in the applinks configuration Environment iOS 18.6.2 iPhone 16 Pro Safari / Passkey UI via WebAuthn Steps to Reproduce Create an iOS app and register it in App Store Connect (or distribute via TestFlight) Configure the AASA file on the domain with only applinks — no webcredentials section: json{ "applinks": { "apps": [], "details": [ { "appIDs": ["TEAMID.com.example.myapp"], "components": [ { "/": "/specific-path/*" } ] } ] } } Implement WebAuthn/passkey registration on the same domain with the domain as rp.id Install the app on the device (via TestFlight or App Store) Register a passkey on the website via Safari Navigate to the login page and trigger the passkey selection UI Expected Behavior Since webcredentials is not configured in the AASA file, the passkey selection UI should NOT display the app icon next to the passkey entry. The passkey icon should be the default website favicon or a generic icon. Actual Behavior The app icon (from App Store Connect / TestFlight) is displayed next to the passkey entry in the selection UI, even though: Only applinks is configured (no webcredentials) The current page URL does not match any paths in the applinks configuration Impact In our production environment, we have a single domain serving multiple partner bank apps. The AASA file contains applinks entries for many different apps (20+ partner apps). When a user accesses the passkey login page, the passkey UI may display an app icon from one of these partner apps, which can be confusing for users — especially if the displayed icon belongs to a different partner's app than the one the user intends to use. Questions Is this the intended behavior — that applinks associations influence the passkey UI icon display? Is there a way to prevent applinks associations from affecting the passkey selection UI without removing the applinks entries? Would adding a proper webcredentials section with the correct app ID override the icon source from applinks to webcredentials? Is there a recommended approach for domains that serve multiple apps via applinks but want to control which icon appears in the passkey UI?

Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. During user testing we found that the tab title and tab URL properties are empty when obtaining the set of open windows via windows.get() after a Safari restart. We are testing with Safari 18.4 (20621.1.15.11.10). We have made a TestFlight version of our app and extension available to help with testing: https://testflight.apple.com/join/Va8Zdv9d. Screenshot and screen recording are attached to the Feedback ID supplied below. STEPS TO REPRODUCE Install Tabby via the TestFlight link Enable the Tabby for Safari extension in the Safari extensions dialog Grant permissions for Tabby for Safari to all windows all the time Within Safari, open two windows each with at least two tabs Within the Tabby app, ensure you see the windows and tabs listed correctly (tab title displayed for each) Quit and restart Safari Expected behavior Safari re-opens existing windows and Tabby displays title for each tab Observed Safari re-opens existing windows but within Tabby all tabs except the current tab are displayed with a title of “Start Page”. Under the hood the tab title and tab URL properties are empty when returned via a windows.get() call after Safari restarts. NAME AND APPLE ID OF APP Tabby - Browser Tab Manager 1586203406 FEEDBACK ASSISTANT ID FB16389506

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?

I am reporting what appears to be a serious integrity flaw in Safari under iPadOS 26.3 (and lower) that materially undermines the reliability of Screen Time parental controls. This is not merely a UX inconsistency but a functional contradiction within a system explicitly marketed and positioned as secure parental control infrastructure. Device / Environment Device: iPad Air M3 13" (2025) OS: iPadOS 26.3 Safari (system version) Screen Time enabled with active restrictions Child account (10 years old) Background We deliberately chose an Apple device for school use based on the expectation that Apple’s system-level parental control mechanisms — especially Screen Time — are robust, tamper-resistant, and technically consistent. Screen Time is configured with: App limits Downtime Parental controls enabled with limited web content restrictions (school requirements prevent strict blocking) Safari enabled (mandatory for educational use) further parental control restrictions Because aggressive website blocking would interfere with legitimate school activities, monitoring Safari browsing history is a central supervisory mechanism. When Screen Time is active: Clearing the entire browsing history via Safari is correctly blocked. Clearing history via system settings is correctly blocked. The system explicitly communicates that deletion is not permitted due to Screen Time restrictions. This behavior establishes a clear user expectation: Browsing history is protected against manipulation. The Issue Despite the above safeguards, individual browsing history entries can be deleted easily and silently through the address bar suggestion interface. This creates a structural contradiction: Full deletion is blocked. Selective deletion — which is arguably more problematic — remains possible. Steps to Reproduce Enable Screen Time with restrictions that prevent deletion of browsing history (for example on a student device with a child account). Open Safari and visit any website. Confirm it appears in Safari history. Tap the Safari address bar. Type part of the URL or page title. Safari suggests the previously visited page below the address bar. Swipe left on that suggestion. A red “Delete from History” button appears. Tap it. Actual Result The entry disappears immediately: No Screen Time PIN required No authentication request No warning No restriction triggered No parental notification No audit trace visible Deletion occurs silently and irreversibly. Expected Result When Screen Time is configured to prevent browsing history deletion: Individual entries must not be deletable Deletion must require Screen Time authentication Anything else defeats the protective purpose of the restriction. Real-World Impact In practical use, this allows minors to selectively sanitize browsing history while preserving a seemingly intact record. In our case, this method is widely known among classmates and routinely used to conceal visits to gaming or social media platforms during school hours. The technical barrier to exploitation is negligible. This results in: A false sense of security for parents A discrepancy between advertised functionality and actual system behavior A material weakening of parental control integrity When a system explicitly blocks full history deletion but permits silent selective deletion, the protection mechanism becomes functionally inconsistent and unreliable. Given that Screen Time is publicly positioned as a dependable parental control framework, this issue raises concerns not only about implementation quality but also about user trust and reasonable reliance on advertised safeguards. Request Please classify this as a parental control integrity and trust issue. Specifically: Disable individual history deletion while Screen Time restrictions are active OR Require Screen Time passcode authentication for deleting single entries Screen Time is presented as a secure supervisory environment for minors. In its current implementation under iPadOS 26.3 and before, that expectation is technically not met. This issue warrants prioritization.

When using passkeys stored in iCloud Keychain (Passwords app) via Passkey Autofill in browsers other than Safari, the userVerification parameter is ignored and user verification (UV) is not performed. As a result, relying party servers that require userVerification = required fail validation because the UV flag is not set, causing passkey authentication to fail. This issue occurs when the following setting is disabled: Settings → Face ID & Passcode → Use Face ID For → Password AutoFill The issue is reproducible only with the following combination: Non-Safari browsers (e.g. Chrome) Passkeys stored in iCloud Keychain (Passwords app) Passkey Autofill The issue does not occur in the following cases: Safari with passkeys stored in any credential manager Non-Safari browsers using credential managers other than iCloud Keychain Steps to Reproduce: Go to Settings → General → Autofill & Passwords, and enable the Passwords app under “Autofill From”. Go to Settings → Face ID & Passcode → Use Face ID For, and disable “Password AutoFill”. Open Chrome and navigate to https://webauthn.io Enter a username and tap “Register” to create a passkey using the Passwords app (iCloud Keychain). On webauthn.io, go to Advanced Settings → Authentication Settings, and set “User Verification” to “Required”. Reload the page, tap the input field, and perform Passkey Autofill. User Verification is not triggered, and “Authentication failed” is displayed on webauthn.io. === This issue has already been reported via Feedback Assistant as FB21756948. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

Before iOS 26.3, the WKWebView method open func loadFileURL(_ URL: URL, allowingReadAccessTo readAccessURL: URL) -> WKNavigation? worked fine when both parameters were passed the same path (e.g., h5path/index.html), allowing access to and loading of other files like CSS and JS within the h5path directory. However, in iOS 26.4 Beta, this results in an error, and the second parameter must point to a parent directory. Is this a bug?

Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2

I have a Net8 Maui WebView app and whenever I use magnifier, it crashes. The magnifier works on iOS18 and lower but crashes on iOS26+ Exception **Type:** CALayerInvalidGeometry **Value:** CALayer position contains NaN: [nan 65]. Layer: <CALayer:0x123e88e40; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x116f2f200; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x123e88e40>>; sublayers = (<CALayer: 0x125232df0>, <CALayer: 0x123e88e70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0> Stacktrace __exceptionPreprocess in unknown file [Line null, column null] (Not in app) objc_exception_throw in unknown file [Line null, column null] (Not in app) +[NSException raise:format:] in unknown file [Line null, column null] (Not in app) CA::Layer::set_position in unknown file [Line null, column null] (Not in app) -[CALayer setPosition:] in unknown file [Line null, column null] (Not in app) -[UIView _backing_setPosition:] in unknown file [Line null, column null] (Not in app) -[UIView setCenter:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] in unknown file [Line null, column null] (Not in app) __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke in unknown file [Line null, column null] (Not in app) -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation _displayMenu:reason:] in unknown file [Line null, column null] (Not in app) -[_UIEditMenuContentPresentation displayMenu:configuration:] in unknown file [Line null, column null] (Not in app) __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke in unknown file [Line null, column null] (Not in app) __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app) __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app) __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke in unknown file [Line null, column null] (Not in app)

In WKWebView, there is the WKUIDelegate method: func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {} This delegate method provides a callback when a new window (for example, target="_blank") is requested in the web view. However, in native SwiftUI (iOS 26), WebView / WebPage APIs do not provide an equivalent delegate method to handle new window requests. As a workaround, I am using the following method: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {} In this method, when action.target == nil, I treat it as a new window request. My question: Is relying on action.target == nil in decidePolicy a reliable and future-safe way to detect new window requests in SwiftUI’s WebView, or is there a better or more recommended approach for handling target="_blank" / new window navigation in the SwiftUI WebView APIs? Code: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy { guard let webPage = webPage else { return .cancel } // Handle case where target frame is nil (e.g., target="_blank" or window.open) // This indicates a new window request if action.target == nil { print("Target frame is nil - new window requested") // WORKAROUND: Until iOS 26 WebPage UI protocol is available, we handle new windows here // Try to create a new WebPage through UI plugins if handleCreateWebPage(for: webPage, navigationAction: action) != nil { // Note: The new WebPage has been created and published to the view return .allow } } return .allow }

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 using a CSS filter to achieve dark mode for my HTML page. I know it's imperfect, but I have no choice for many reasons. However, I found that the CSS filter produces incorrect colors in iOS 26.2 WebView, while it works fine in iOS 18.6.2 WebView. Here is my HTML and CSS filter: <html> <head> <style> .filter_container { /* invert colors for the entire page */ filter: invert(1) hue-rotate(180deg); } .filter { /* restore colors for specific elements, such as img */ filter: hue-rotate(180deg) invert(1); } </style> </head> <body> <div>original & bgcolor+filter & img+filter</div> <table> <tr> <td> <div style="display:flex; gap:1px; align-items:center; justify-content:center;"> <div class="origin_container"><div class="origin" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px;"></div></div> <div class="filter_container"><div class="filter" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></div></div> <div class="filter_container"><img class="filter" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAA8CAYAAAA6/NlyAAAAdklEQVR4nOXOQQEAIACEMKR/57OFPliCnW0jRGIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkxt+B1y6HmAR0uIzOQQAAAABJRU5ErkJggg==" style="height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></img></div> </div> <div style="text-align:center;">#FFFFFF</div> </td> ...many other colors </table> </body> </html> It works fine in iOS 18.6.2 WebView: But renders incorrectly in iOS 26.2 WebView:

I'm encountering an issue with front camera video recordings via browser (Safari/Chrome) on devices running iOS/iPadOS 18 and above: On iPad, the recorded video appears upside down. On iPhone, the recorded video is rotated 90 degrees. The rear camera functions correctly without orientation issues. This problem seems specific to browser-based recordings, as the native Camera app records videos with the correct orientation. Has anyone else experienced this behavior? Is there a known workaround or fix? The preview while recording is fine, the recorded video is oriented incorrectly.

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 !

Dear Apple Developer Support, We are currently developing a system that requires the ability to edit Japanese vertical text within the Safari browser on iPhone. During our investigation, we encountered an issue that matches the following WebKit bug: 283620 – Caret Positioning Issues in Vertical Writing Mode We understand that this issue is being addressed in the following pull request: https://github.com/WebKit/WebKit/pull/39939 However, it appears that a complete fix has not yet been implemented. Given this situation, we would like to confirm the following: Is there any known workaround for this issue in iOS 17.5 or iOS 18.5 (the latest versions as of now)? If a workaround exists, could you please provide details? If not, could you share the expected timeline for a full resolution of this issue? Although this appears to be an open-source WebKit issue, we are reaching out to Apple because WebKit is tightly integrated with iOS and Safari, and ultimately delivered as part of the iPhone experience. Thank you very much for your support. Best regards, Takao Kurabayashi

Hello everyone, I am currently working on integrating a WebView into my macOS application, intended to allow users to browse tutorial webpages directly within the app. Although I’ve followed an example that appears syntactically correct, the WebView does not render any webpage content. Below is a code snippet for reference: import SwiftUI import WebKit struct HelpWebView: View { @State private var toggle = false @State private var page = WebPage() private var url: URL { toggle ? URL(string: "https://www.webkit.org")! : URL(string: "https://www.swift.org")! } var body: some View { WebView(page) .onAppear { page.load(URLRequest(url: url)) } .onChange(of: toggle) { page.load(URLRequest(url: url)) } .toolbar { Button("Reload", systemImage: "arrow.clockwise") { toggle.toggle() } } } } I would greatly appreciate any insights or suggestions on what might be causing this issue or how to resolve it. Thank you in advance for your help!

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.

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!

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 ?

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 using the native SwiftUI WebView and WebPage APIs (iOS 26+) and would like to implement file download functionality using the native SwiftUI WebView. However, I have not been able to find any APIs equivalent to WKDownload. In WKWebView, the WKDownload API can be used to handle downloads. I am looking for a similar API or recommended approach in the native SwiftUI WebView that would allow downloading files. If anyone has guidance or suggestions on how to implement this, I would appreciate your help.