Environment App built with Xcode 26.3 (iOS 26 SDK) Deployment Target: iOS 16+ Issue occurs only on devices upgraded to iOS 27. Works perfectly on iOS 26.x. Problem description: After end‑user upgrades their iPhone to iOS 27, a persistent stale frosted‑glass / blur rendering effect appears at the top area of screens. This symptom occurs both on native UITableView and inside WKWebView. No blur‑related code (UIVisualEffectView / backdrop‑filter) is added by our application. Layout frames, insets and contentOffset are all correct. Reproduction hints: The issue can be triggered after presenting then dismissing a WKWebView which loads H5 with overlay popup. Rendering state seems to leak to the whole app process. The leftover blur remains until push/pop the view controller. Is this an iOS 27 system bug, or do we need special adaptation for existing apps built with older Xcode 26.3 SDK? What is the proper workaround for apps compiled with Xcode26.3, since liquidGlassEffectEnabled is only available in iOS27 SDK and cannot be accessed in our current build environment.

For a UIKit app embedding a WKWebView across the inner display, what is the recommended way to keep web content and interactive controls clear of the fold’s division reserved region? Are these regions exposed to web content through public CSS or JavaScript APIs, or should the UIKit host query them and communicate the geometry to the page? How should this work alongside CSS safe-area insets and the web view’s scroll-view inset adjustment, so that native and web layouts don’t apply the same spacing twice? A small UIKit + WKWebView example would be very helpful.

I filed FB24577577 about the Dock disappearing after WKWebView element fullscreen in a macOS accessory app. I retested the original minimal reproduction on macOS 27.0 (26A428), and the symptom still occurs on the built-in display alone. Is this combination of public AppKit/WebKit APIs supported? Is there an application-side workaround that preserves both an accessory activation policy and a window that joins all Spaces? Reproduction The app uses: NSApplication.ActivationPolicy.accessory (no Dock tile). NSWindow.CollectionBehavior.canJoinAllSpaces on the window hosting the WKWebView. WKPreferences.isElementFullscreenEnabled = true. Element.requestFullscreen() to enter fullscreen. A normal titled window at normal window level and a local HTML page containing a single div are sufficient. No external website, video, networking, custom window subclass, or private API is involved. The key AppKit/WebKit configuration is: NSApplication.shared.setActivationPolicy(.accessory) window.collectionBehavior = [.canJoinAllSpaces] configuration.preferences.isElementFullscreenEnabled = true Load a local HTML page with one clickable div whose click handler calls requestFullscreen() on that element. Keep the application running and retain the window/web view. With Dock auto-hide disabled, enter element fullscreen, then exit and inspect the Dock. The macOS 27 retest entered by evaluating a click on the div through WKWebView.evaluateJavaScript, confirmed document.fullscreenElement was non-null, and exited with document.exitFullscreen(). The original macOS 26 testing also reproduced with Escape. Expected: the Dock resumes its normal always-visible behavior after fullscreen ends. Actual: the right-side Dock disappears despite auto-hide remaining disabled. macOS 27 retest (September 16, 2026) macOS 27.0, build 26A428. NSScreen enumerated exactly one built-in display at the start of this run. Dock on the right, auto-hide disabled throughout. Fullscreen entry was confirmed, and document.fullscreenElement was null after exit. Both NSApp.presentationOptions and NSApp.currentSystemPresentationOptions returned to 0. The Dock was visually absent after exit. Its on-screen window count changed from 1 to 0 and was still 0 six seconds later. Window counts were supporting evidence, not the sole visual criterion. An external display was reconnected later, so this retest does not establish indefinite persistence or that restarting Dock is the only recovery route. Earlier comparisons and product impact The original report was reproduced on macOS 26.6.2 (25G83). In those earlier comparisons, removing canJoinAllSpaces avoided the symptom; using native AppKit window fullscreen instead of WebKit element fullscreen also avoided it. These controls were not rerun on macOS 27. Restarting Dock restored it in the earlier tests. This affects Nifro, a desktop-wallpaper app using WKWebView. The current app keeps element fullscreen disabled. Joining all Spaces and having no Dock tile are useful parts of its wallpaper behavior, so changing either has a product cost. Could an AppKit/WebKit engineer advise whether this is an unsupported configuration or a system issue tracked by FB24577577, and whether a supported public-API workaround exists? I can provide further targeted diagnostics if needed.

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.

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?