Does anyone have any advice on working a way around this, or through this? My app is wrapped and WKWebView displays HTML/CSS/JAVA and StoreKit is iOS framework. I used choicely up wrap it because i don't own a mac. The only part i can't control is this. I'll likely have to wrap it myself, rent a cloud Mac and submit directly to ensure everything is attached to the binary. I can't control that from choicely. any other ideas!? I’ve been over a month trying to get this going. It’s live but with no way to transact the subscribers I’m already getting. HELP PLEASE!

Two unrelated, legitimate websites I own are both shown as "Deceptive Website — Apple has identified this website as fraudulent" in Safari (iOS + macOS), and even inside my installed PWA on iOS. This is a false positive and I can't find a working way to get Apple to remove it. Why I'm confident it's a false positive: Google Safe Browsing site status: clean Google Search Console (verified owner) > Security Issues: none Yandex Webmaster > Security: no violations VirusTotal: 0/92 detections Chrome, Firefox, Yandex Browser: NO warning on any platform Only Safari shows it, wording is "Apple has identified..." — i.e. Apple's own list, not the Google Safe Browsing feed The sites are genuinely benign: no brand impersonation, no third-party credential harvesting, no malware, no drive-by downloads. The interesting part — it's TWO unrelated sites: Site A: a small web app (SaaS with a login form) Site B: my personal developer portfolio — static, no login at all They share almost nothing: different codebase, different design, different hosting (Site A is behind Cloudflare with a Google Trust Services edge cert; Site B is a plain nginx box with a Let's Encrypt cert), different TLS issuers, different stacks. The ONLY common denominator is me as the owner/registrant (same person, same contact email, same registrar account). This makes me think the domains were clustered by registrant/owner rather than by anything on the sites themselves. The two-sites fact also rules out the usual scapegoats: it isn't Cloudflare (Site B isn't even on Cloudflare and is flagged too), nor the cert issuer, host, or stack, since those differ. What I've already done: Clicked "Report an error" on the Safari warning page Submitted the Google Safe Browsing incorrect-warning report Filed a tracked report in Feedback Assistant (FB number, status Open) Hardened both sites anyway: CSP + security headers, SPF/DKIM/DMARC, and real trust pages (About with owner identity + contact, Privacy Policy, Terms, linked from homepage and login page) It's been about a week with no response. My questions: When Google Safe Browsing is clean but Safari still flags, what feeds Apple's OWN fraudulent-site list? Is registrant/owner clustering a real mechanism here? Which removal channel actually works in practice? Realistic timeline for a false-positive removal? If one domain is cleared, does that clear the owner-level association for the other, or do I appeal each separately? Is there anything that re-triggers it? (Considering a domain migration as a last resort and want to avoid a new domain getting re-flagged.) Any first-hand experience is appreciated — the process is completely opaque.

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?

When I login to an account on a subdomain of a main domain, I want to be able to store a separate password for the same login id on the main domain account. This doesn't seem possible in the current Safari implementation.eg: domain.com is the main domain and is the general information site.my.domain.com is the subdomain that hosts the customer support.I want different passwords on each for the same login ID... Can't I do this?--marcel

I’d like to ask whether Apple plans to enable Encrypted Client Hello (ECH, RFC 9849) opportunistically by default across the iOS/iPadOS system networking stack. Apple already exposes ECH support through sec_protocol_options_set_enable_encrypted_client_hello(), but there currently appears to be no system-wide preference, configuration profile, or MDM policy to enable ECH for normal system networking clients such as URLSession, CFNetwork, WebKit/Safari, and other apps relying on Apple’s networking stack. I tested this with a working ECH deployment: A domain publishes a valid DNS HTTPS/SVCB record containing an ech parameter. The corresponding TLS endpoint supports ECH. iOS successfully queries and receives the HTTPS/SVCB record. Safari / normal system networking clients then connect to the domain. Packet capture still shows the real SNI in the plaintext ClientHello, and ECH is not attempted. If the same connection is explicitly configured to enable ECH at the TLS protocol-options level, ECH can be used successfully. It would be useful if iOS/iPadOS could: Opportunistically enable ECH by default whenever TLS 1.3 and a valid ECHConfig are available. Optionally provide a system-wide / MDM policy for enabling ECH. Ideally provide an “ECH required” policy that fails closed rather than falling back to plaintext SNI. This would improve hostname privacy for applications using the system networking stack without requiring every application developer to explicitly opt in. I have submitted this through Feedback Assistant as: FB24334961 — Enable Encrypted Client Hello (ECH, RFC 9849) by default for system TLS connections Has anyone found an existing system-level way to enable ECH, or does anyone know whether Apple plans to make this the default behavior?

I am implementing push notifications for a web application running as a PWA on iPad using Web Push. When sending a push notification to the web application, I received a 410 response from the server. I would like to understand the cause and reason for receiving this 410 response. The library used for sending push notifications is a commonly used JavaScript Web Push library. Could you please explain under what circumstances Apple Web Push endpoints return a 410 response, and whether this indicates that the existing push subscription is no longer valid and should be re‑registered.

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.

Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] -[WKContentView(WKInteraction) _continueElementDidFocus:...] -[WKContentView(WKInteraction) _elementDidFocus:...] WebKit::WebPageProxy::elementDidFocus(...) Building that container steals key status from the web view. First responder ends up on the enclosing _UIHostingView, so key presses are delivered there and immediately cancelled: pressesBegan: [...], focusedItem: monacoEditor firstResponder at keypress: _UIHostingView<...> pressesCancelled: [...] The catch: -becomeFirstResponder cannot be used to recover, because it is the trigger. Calling it re-enters _elementDidFocus and re-arms the loop permanently. So there is no app-side way back — the only API that reclaims the keyboard is the one that breaks it. Minimal repro is just a WKWebView in a UIViewRepresentable inside a SwiftUI hierarchy, with any focusable . No Monaco needed. Partial mitigation, if you hit this: do not echo focus/blur commands back at the web view in response to its own focus events, and treat a blur where document.hasFocus() is false but activeElement is unchanged as a window-level blur rather than an editing-ended event. That stops the runaway loop and keeps your focus state correct — but it does not restore typing. Has anyone found a way to get first responder back to the web view without calling -becomeFirstResponder? Or a way to stop the keyboard scene delegate engaging on Catalyst in the first place? If you can reproduce on 27 beta, please file a duplicate referencing FB24092251.