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've implemented Apple Pay payments in my website. I'm using live environment and real card and not the sandbox. Everything works fine till the last step. When I have to make payment it does not show the pay button or Pay with Touch ID option on Apple paysheet.

Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.

Although I have reduced my Mac's MTU to solve the MTU blackhole problem, Safari is quite slow if I enabled iCloud private relay (scenario 1). At the same time, Chrome functions normally. When I turns off iCloud private relay, the Safari's performance improves immediately. Packets captured by tcpdump at a LAN gateway (FreeBSD) shows iCloud private relay uses UDP protocol and doesn't fallback to TCP protocol. If the MTU blackhole is a problem, the connection will switch to TCP protocol, given prior tcpdump captures. I am waiting for macOS 27 Beta 5 but still no update released yet.

Is it only on my personal M4 Pro, or can someone help confirm the error? Minimal, Reproducible Example (error appears after ~18secs): https://www.oslobalanse.com Exact Environment Details: MacBook Pro, 14", November 2024. 24GB, macOS is Tahoe 26.6.2 Expected results: A kind of film strip behaviour is expected. The images should glide or pan with constant speed across screen from right to left. Images should halt until fully overlapped on left or right screen edge depending on width of image (if larger or smaller than actual window size). The loop should be continuous. Actual results (so far only confirmed on Apple M4 Pro): The only visible error is the appearance of huge black spaces when the images disappear (see after approx 18 secs). The speed of movement is also no longer constant. This bad behaviour has so far only been confirmed on Apple M4 Pro. Console Output: There are no errors visibly shown. Troubleshooting Steps Taken: I have tried and confirmed the error both on version 26.3 and 26.6. The error has also been confirme on both Safari and in Chrome. I have disabled hardware acceleration on Chrome, but it did not help.

I am trying to use Safari Web Extension Packager to upload a web extension ZIP through App Store Connect, following this documentation: https://developer.apple.com/documentation/safariservices/packaging-and-distributing-safari-web-extensions-with-app-store-connect However, I cannot find the Packager upload section at all. Steps to reproduce: Sign in to App Store Connect as the Account Holder of an active Apple Developer Program membership. Open an existing app, then select Xcode Cloud. Scroll to the bottom of the page. Actual result: The page only shows the standard Xcode Cloud introduction, with “Get started in Xcode” and an “Open Xcode” button. There is no Safari Web Extension Packager section or ZIP upload control. Another app under the same team shows the same introduction page. Additional details: The existing Safari extension was previously distributed as an iOS app using Xcode. I want to use the Packager for the next update while retaining the existing app identity. The source is a WXT project and the Safari ZIP has been generated. I cannot reach the upload or build-validation step. During my September 6 checks, the Developer Program and App Store Connect agreements were accepted, with no pending agreement prompt. Apple Developer Support's account-support team directed me to the Developer Forums because they could not diagnose this technical issue. Could an Apple engineer clarify: Is Packager available to all eligible teams, or still being rolled out? Are there country/region restrictions, including mainland China? What prerequisites control the upload section? Must a team first enable a conventional Xcode Cloud workflow through local Xcode, even if the intended input is only a web extension ZIP? Can Packager update an existing app previously built with Xcode, or does initial setup require a new app record? What is the correct page or navigation path when only the Xcode Cloud introduction is visible? This question concerns access to the web-based packaging UI. A documented activation step or confirmation of availability requirements would be helpful. Screenshot of the missing upload section:

My domain vendezo.com is completely clean on Google Safe Browsing and VirusTotal, but Safari still shows a Deceptive Website Warning. Request through websitereview.apple.com was ignored. Please help

Device: iPhone 15, iOS 26.6, Safari. Also reproduced on Android Chrome, so this is not only WebKit, but the missing rotation flag part is. Setup: a web page asks for the front camera with getUserMedia, shows it in a video element, and records with MediaRecorder. Phone held upright. What happens: Requesting portrait dimensions (width 1080, height 1920) returns the sensor's wide preset, 1920 by 1080, unrotated. exact instead of ideal gives the same or an error. aspectRatio 9/16 gives the same. Requesting landscape numbers (width 1920, height 1080) lets Safari pick the preset and rotate the picture to match how the phone is held. Even then, the video track's getSettings() reports width 1920 and height 1080, while the frame Safari draws into the video element is portrait. The preview looks right. The track lies. MediaRecorder records the unrotated sensor buffer. On older iOS the file carried a displaymatrix rotation of minus 90 degrees and players honoured it. On 26.6 that flag is gone, so the file plays sideways. Thread 786803 has other people finding the same. Workaround that works in production: Ask for the camera in landscape numbers. Do not trust getSettings(). Draw one frame of the video element onto a 16 by 16 canvas scaled from the larger reported dimension and check which corner has paint. If the bottom left is painted and the top right is not, the picture is tall. If the drawn picture is portrait but the track says landscape, record a canvas stream of the drawn picture at its own size instead of the raw track. If they agree, record the raw track. Put the H.264 High profile first in your mime type candidates. isTypeSupported says yes to Baseline and High, and list order decides, so Baseline first gives soft video. Working code, MIT, with the dead ends left in as comments: https://github.com/lagudafuadtosin/web-teleprompter (src/lib/camera.ts) Full write-up: https://dev.to/lagudafuad/why-your-web-teleprompter-records-sideways-on-iphone-and-the-fix-549m Question for Apple: is the dropped displaymatrix on MediaRecorder output in 26.x intentional, and is there a supported way to read the capture rotation off the track?