Dear App Store Connect Team! Since Passkeys have been introduced as login option on https://appstoreconnect.apple.com, I am unable to to make use of this new sign in option. I have attached sysdiagnoses, screen recordings, and .har exports in my feedback requests: FB22167539 FB17622414 FB22403813 When I select "Sign in with Passkey", the spinner just keeps spinning. Signing in with password works without issues. I can sign into my Apple ID on other Apple websites using my passkey without problems. Hope that helps! – Frederik

On macOS 26, when a passkey sign-in flow is started in Safari or another WebKit-based browser (for example, DuckDuckGo browser), smart cards become inaccessible as soon as the password manager selection UI is shown, but only if the website offers “Security Key” as one of the passkey storage/authentication options. At that moment, it appears the system starts polling connected smart cards and does not properly release the transaction/session. As a result, other applications and libraries can no longer communicate with the smart card until the passkey UI is dismissed, and in practice the card may remain unavailable until the passkey sign-in flow is fully completed. This does not happen in Chrome. This does not happen if the website does not offer the “Security Key” option. This does not happen during passkey registration; the issue affects sign-in only. From our investigation, Safari/WebKit appears to open communication with connected smart cards and keep the transaction/session active. Because of that: • our own smart card code blocks while waiting for a PC/SC transaction to begin; • the system pcsctest utility also hangs and does not continue until the passkey selection UI is closed; • a minimal sample using TKSmartCard also blocks on beginSession(). This suggests the smart card is locked not only at the PC/SC level, but also at the CryptoTokenKit level. This issue is critical for us. We are developing a password manager that supports storing keys on a smart card, and due to this behavior we cannot access our card while Safari/WebKit is showing the passkey flow. Is there any way to stop safari from accessing smartcards? Any terminal commands/settings/workarounds?

I have an app which has at least two extensions: A Content Blocker extension with a request handler that returns an appropriate NSExtensionItem as part of beginRequest. A different file URL is returned depending upon if the content blocking is on or off by a user setting A Safari Web Extension that includes a toolbar button and popover that enables users to enable or disable the ad blocking of the content blocker extension All three targets (App, Content Blocker appex and Web Extension appex) use an App Group default to read and set the on or off status of the content blocking. When the user changes the content blocking status, the app group default is updated and SFContentBlockerManager.reloadContentBlocker(...) is called. The Content Blocker extension reads the default and then returns the appropriate file URL. The issue is, I have noticed that whenever SFContentBlockerManager.reloadContentBlocker(...) is called from the app, Safari always applies the correct rules from the returned file URL. However sometimes when SFContentBlockerManager.reloadContentBlocker(...) is called from the Safari Web Extension using native messaging, Safari does NOT apply the correct rules from the returned file URL. Using logging I have confirmed that the Content Blocker extension always returns the appropriate file URL irrespective if called as a result of the app or the web extension. Despite this, Safari does not seem to always apply the returned file URL rules when it is called from the Safari Web Extension appex. In these cases, quitting Safari and relaunching it seems to make it apply the rules correctly (obviously this is applying it due to its launch state, not due to the Web extension appex asking it to do so at that point). All targets have access to the App Group location where the active content blocking file URL belongs and the inactive content blocking file URL is within the Safari content blocker target as a resource. I don't think this is a memory status issue as I cannot see the Content Blocker extension being killed when it returns complex rules --- the fact it always works when called via the app also seems to rule this possibility out. This brings up a number of questions: Is calling SFContentBlockerManager.reloadContentBlocker(...) from a different appex, of the same app target and app group supported? (it seems to work sometimes and did work in previous versions of the app). Is there an issue that the Content Blocker extension sometimes returns a file URL that perhaps the calling Web Extension appex may not have access to (even though Safari should via the Content Blocker extension)? Any other ideas of why this may not be working correctly? Has anyone else experienced this? It seems to happen on both iOS and macOS Safari using the same codebase.

Observed versions: Reproduced on Tahoe / Safari 26 and iOS 26 Safari. Not reproduced on v18 Safari. Not reproduced in Chrome with the same reduced test setup. We are seeing a Safari-only rendering issue affecting an ad creative inside an iframe on both desktop Safari and iOS Safari. What we observe: The issue is reproducible in Safari on OS X and iOS v26. We do not reproduce it in Chrome with the same test setup. We can reproduce it in a minimal test case, outside our site app code. The issue appears tied to the rendered iframe document/layout, not our outer page layout. The problematic rendered structure inside the iframe looks like this: <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script src="https://www.googletagservices.com/dcm/dcmads.js"></script> </ins> </div> Here is a simplified, local-reproducible version for testing: <div class="GoogleActiveViewInnerContainer" style="left:0px; top:0px; width:100%; height:100%; position:fixed; pointer-events:none; z-index:-9999;"></div> <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script> document.write( '<a target="_blank" href="#"><img ' + 'src="data:image/svg+xml;utf8,' + encodeURIComponent( '<svg xmlns="http://www.w3.org/2000/svg" width="320" height="50">' + '<rect width="320" height="50" fill="#ffd8d8"/>' + '<text x="160" y="30" text-anchor="middle" font-family="Arial" font-size="14" fill="#222">' + 'img placeholder' + '</text>' + '</svg>' ) + '" ' + ' alt="Advertisement" border="0" width="320" height="50" style="display:block" /></a>' ); </script> </ins> </div> In Safari, this produces extra vertical spacing / cutoff above the ad. In the test code you will only notice an added top spacing, but when rendered in a live ad, the bottom gets cut off. A few details that may help: If we manually change the inner ins.dcmads from display:inline-block to display:inline, or adding overflow:hidden, the spacing issue goes away. If the loader script is moved outside the ins during manual experimentation, the issue also goes away. This makes it look like a Safari layout/rendering issue involving an inline wrapper around an inline-block ad container during script-driven rendering. Questions: Is this a known Safari/WebKit layout issue involving inline + inline-block content in iframe documents? Has there been any recent Safari/WebKit change that could affect this rendering path? Is there a preferred reduced repro format for reporting layout issues like this?

Background We are investigating Safari’s Prevent Cross‑Site Tracking feature (part of Intelligent Tracking Prevention / Link Tracking Protection) on iOS and macOS (latest versions). We fully understand and respect Safari’s privacy objectives and are not requesting any whitelisting or relaxation of protections. Our goal is to understand how Safari determines when and where query parameter stripping is applied, so we can design a compliant and predictable implementation. Based on public WebKit and privacy documentation, it is understood that Safari’s tracking prevention behavior may be influenced by: Tracker classification sources such as: DuckDuckGo Tracker Radar https://github.com/duckduckgo/tracker-radar EasyList / EasyPrivacy https://easylist.to/easylist/easyprivacy.txt WebKit privacy architecture and heuristics, including behavior described in: WebKit “Private Browsing 2.0” / Link Tracking Protection documentation https://webkit.org/blog/15697/private-browsing-2-0/ Request for Guidance To help us align fully with Safari’s privacy model, we respectfully request guidance on: How Safari determines, at a domain or subdomain level, when to apply query parameter stripping under Prevent Cross‑Site Tracking. Whether evaluation may be influenced by: Tracker classification sources (e.g., domain reputation or known tracking endpoints) Runtime network behavior (such as cross‑site analytics requests) Subdomain‑specific context or historical behavior Whether Prevent Cross‑Site Tracking is evaluated: Per navigation event Per domain or subdomain Based on cumulative or runtime signals Whether Apple recommends specific design patterns or alternatives for handling essential, non‑tracking URL data in a way that is compatible with Safari’s privacy protections. Our objective is to design a solution that respects Safari’s intent and avoids reliance on fragile or unpredictable URL‑based behavior.

Safari on iOS 17, when entering characters into text input box after deleting characters, the layout is off. Here's the HTML: <body> <div id="J001" style="display: inline-block;"> <div id="J001__0" style="display: inline-block;"> <input id="J001__0__input" style="display: inline-block; height: 28px; padding:2px; border:1px solid gray;"></div> <div id="J003__0" style="display: inline-block;"> <button id="J003__0__btn" style="display: inline-block; height:34px;">a</button> </div> </div> </body> Enter "A" into text input box. Delete "A" with the backspace(x). Enter "A" into text input box, the button position will be shifted down. iOS 17 の Safari にて、テキスト入力ボックスで文字を削除した後、文字を入力するとレイアウトが崩れます。 テキスト入力ボックスに「A」と入力します。 バックスペース(x)で「A」を削除します。 テキスト入力ボックスに「A」と入力すると、ボタンの位置が下にずれます。

I would like to script my Mac to close a specific iCloud Tab of my choice that is open on my iPhone. This is for Accessibility reasons. Ideally, I’d prefer to do this without using GUI scripting. AppleScript methods only seem to see tabs in Windows Extensions also do not seem to have visibility of the other types of tabs I've tried many options so far, but all seem to not work and are also far too brittle even if they did. I have a feeling I'm missing something! 1. Toolbar Dropdown In Desktop Safari you can enable a toolbar button “iCloud Tabs” which when clicked shows a list of the tabs currently open on your other devices. If you hover one, an X appears which can be clicked to close the tab. When you next use Safari on the remote device that tab will be closed. If it’s already open and awake then the removal happens around one second later. It’s quick. (But I did try GUI scripting and I can get to the row in the outline in the popup, but I can’t get the cross to appear to click it) 2. Start Page they’re also listed on favorites:// “start page” but there are issues viewing all and no way to search them. There used to be a search field until Safari ~15. 3. Omnibar They’re also shown in omni/address bar, but getting the correct item to appear at all or in a predictable position is fragile. 4. Sidebar Another alternative to the favorites/"start page" layout. Same issues. 5. Modifying Safari Database directly Changes are not mirrored to the cloud. It seems Safari does a cloudd request that I can't do.

After I updated to visionOS 26.4, I noticed my website environment would suddenly turn off occasionally while I was watching YouTube in Safari. My M2 AVP was still warm after the update. Is turning off a website environment expected behavior when the headset gets warm (e.g., perhaps to reduce load)? If not, anyone have an idea this might happen?

After updating to visionOS 26.4, I went to Safari's Feature Flags page to reenable Website environment, and I found the Website environment switch had been moved from the top and into the list of switches below. In its place is "Immersive API". I could not find any documentation on this. Anyone know what it is for or can point me to documentation?

We're developing a service that requires webtransport support in the browser. Currently, the only browser that doesn't provide support is the IOS version of Safari. Our current way forward for client use is to flag iphone and ipad as non compliant and recommend either desktop use or android. Is there any ballpark date as to when WebTransport will be included in IOS Safari (- webkit supports webtransport)?

Safari continues to display a "Fraudulent Website Warning" for openvan.camp despite the domain being clean across all major security databases for over a week. Chrome, Firefox, and all other browsers open the site without any warnings. Domain: openvan.camp Warning appeared: March 18, 2026 Warning type: Fraudulent Website Warning (red screen) Current security database status: Google Safe Browsing: ✅ Clean (transparencyreport.google.com) Google Search Console: ✅ No security issues Spamhaus DBL: ✅ Removed from blocklist Fortinet FortiGuard: ✅ Category "Travel" VirusTotal: ✅ 0/65 vendors URLVoid: ✅ 0/35 engines Steps taken: Removed the third-party ad network (Adsterra) that caused the original flag — March 18, 2026 Migrated hosting to Scaleway (AS12876, France), IP: 151.115.84.228 Configured SPF, DKIM, DMARC records Created functional abuse@ and postmaster@ role accounts Submitted review via websitereview.apple.com — no response after 5 days What we believe is happening: Apple's Safe Browsing database appears to have an independent entry for this domain that has not been updated despite all underlying security databases clearing the flag. Safari's warning persists even after deleting ~/Library/Safari/SafeBrowsing/ cache and re-downloading the database — which confirms this is not a local cache issue. Steps to reproduce: Open Safari on macOS or iOS Navigate to https://openvan.camp/ Safari displays "Fraudulent Website Warning" Open the same URL in Chrome — no warning Expected behavior: No warning should be shown. The domain is legitimate, clean, and verified. Has anyone experienced a similar issue? Is there any additional channel to escalate beyond websitereview.apple.com?

Thank you again for pushing the web forward in VisionOS 2, super exciting! The latest WWDC24 video touched on VR experiences for VisionOS2.0 using WebXR, however there was no mention of passthrough AR experiences. Samples such as this one are not supported: https://immersive-web.github.io/webxr-samples/immersive-ar-session.html In Settings > Safari, there is a feature flag for the AR WebXR module, but enabling it did not seem to change anything. Is this the expected behavior at this time? Any developer preview(s) we could try?

Considering how important smooth/continuous corners are for Apple throughout their various native platforms (and hardware), can we expect Safari to soon adopt this CSS feature? It's already live in Chrome https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/corner-shape For those who are unfamiliar with smooth corners and how Apple uses them: https://www.youtube.com/watch?v=YElVQqNwrJ4&amp;t=110s

Hi, We're experiencing a WKWebView issue where the screen intermittently turns pure magenta (#FF00FF) in our production iOS app. After investigation, we traced this to WebKit's internal WKCompositingView.mm where [UIColor magentaColor] is used as a pending state indicator when coverView.hidden == NO. This matches rdar://163597990 / WebKit Bug 303157 ("Magenta flash when loading page"), which was fixed in commit 303720@main on 2025-12-01 via PR #54499. My question is simple: which iOS/Safari release includes this fix? We're on iOS 26.3 and still seeing the issue. We need to know: Is the fix already in iOS 26.3? (If so, there may be another unfixed code path) If not, which upcoming iOS version will include it? Our environment iOS 26.3, iPhone 15 Pro Max WKWebView with complex web content App codebase contains zero magenta color usage — this is purely from WebKit Related rdar://163597990 Bug 303157 — RESOLVED FIXED Bug 230531 — "Pages render as magenta after being in background" PR #54499 — Merged to main 2025-12-01 Any information about the release timeline would be very helpful. Thanks!

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.

Steps to reproduce: Create a CSS grid with fractional column widths e.g. grid-template-columns: repeat(3, 518.7875px) Set browser zoom to 85% or 115% Observe columns misalign with background-size pattern Expected: Columns render consistently at all zoom levels Actual: Subpixel rounding causes visual misalignment macOS: 13/14/15 inch MacBook

We are developing a mobile-first, browser-only web application that requires users to upload 20–200 images stored inside a single folder (for example, a merchant product directory). On iOS Safari: window.showDirectoryPicker() is not supported. is not supported. File System Access API is not available. Users must manually multi-select images from the Photos picker. This creates significant friction for bulk upload workflows. We are NOT requesting unrestricted file system access. We are asking whether a privacy-preserving, user-granted folder-scoped permission model is being considered for web applications. For example: User explicitly selects a folder. The web app receives scoped access only to that selected folder. Access is session-bound and revocable. No background or global storage access is required. Questions: Is folder-level access for web apps being considered for iOS Safari? Does installing a PWA provide any enhanced file access capability? Are there recommended best practices for handling bulk image uploads in browser-only iOS applications? Is there any roadmap alignment with the File System Access API standard? Our goal is to remain browser-only and maintain strict user privacy while improving usability for high-volume image workflows. Any clarification on intended platform direction would be appreciated.

I created a form field using: On Safari and Chrome desktop, it behaves as expected. Safari shows the current date in grey by default, and Chrome displays a format hint like dd.mm.yyyy, which is perfectly fine. On iOS, however, the field appears completely blank. I understand that the placeholder attribute is not part of the iOS date input behavior, which is technically fine. Still, it would be helpful if developers had the option to define a default display value. In the past, browsers prefilled date inputs, but many developers objected because they needed the field to be empty by default. I have searched extensively and tried several AI tools, and everywhere it says that this cannot be changed. Am I missing something, or is there any way to display a placeholder, the current date, or some kind of visual hint in iOS Safari? Right now, the empty field creates poor UX because users may overlook it. Since the field is required, this can easily lead to validation errors and additional friction. As a workaround, I used a CSS hack with input[type="date"]::before and a content attribute. I also added JavaScript to toggle a pseudo-placeholder value specifically for iOS. Is there a cleaner solution that avoids this workaround? Thanks in advance for your guidance.

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

We're trying to implement Cross-domain session check for SSO by making CORS request. is Intelligent Tracking Prevention blocks all cookies in CORS requests? I saw all cookies are blocked in CORS requests. We are not able to check the auth session in source domain. Are there anyway to bypass this without user interaction? benefitier.com -> source.com