Hi everyone, I'm hoping someone can help with an issue I'm having with Apple's Web Content Restrictions. I manage a legitimate fitness and wellness website, but some iPhone/iPad users are unable to access it when they have: Settings → Screen Time → Content & Privacy Restrictions → App Store, Media, Web & Games → Web Content → Limit Adult Websites enabled. They receive: Website Not Allowed The website is a restricted website. I've been able to reproduce the exact same issue myself by enabling this setting on an iPhone. The important point is that the website is not adult content whatsoever. It is a normal fitness/wellness website providing workouts, fitness programmes, nutrition guidance and related content. There is no pornography, sexually explicit content or adult services. I've also tested blank pages and different URLs associated with the site, and the restriction still occurs. Everything works normally when the Web Content setting is changed to Unrestricted Access. I've contacted Apple Support and Apple Developer Support but haven't been able to get the issue in front of someone who can review the website's classification. Does anyone know how to request a review or reclassification of a website that appears to have been incorrectly flagged by Apple's Web Content Filter? I'm not trying to bypass Apple's parental controls. I simply want to understand how a legitimate fitness website can be reviewed and removed from whatever classification is causing it to be blocked under Limit Adult Websites. Any advice from anyone who has dealt with this before would be hugely appreciated.

Hello I am developing a web application using Next.js and attempting to implement Passkeys / WebAuthn for session unlocking on iOS Safari. My specific requirement is to achieve a seamless, zero-click biometric unlock experience (Face ID) for returning users upon page load or refresh, similar to native app behavior, without requiring any physical user interaction (such as tapping the keyboard suggestion in Conditional UI or tapping a system modal like ⁠ASAuthorizationController⁠). Could you please clarify: Does the WebKit / Safari architecture strictly prohibit silent, programmatic invocation of ⁠navigator.credentials.get()⁠ with ⁠mediation: 'conditional'⁠ or any other configuration without a direct, user-initiated gesture or touch event? Is there any existing or upcoming API in Safari/iOS that allows web apps to trigger Face ID verification automatically upon page load, or is user presence (tap/interaction) a permanent, hard requirement enforced by iOS security for web browsers?

I am implementing push notifications using Web Push for a web application running as a PWA on iPad. When sending a push notification to the web application, the push service returns an HTTP 200 response. However, no notification is displayed on the PWA, and the Service Worker's push event is not triggered. If I create a new push subscription and send the notification using the newly issued endpoint, notifications start working again. Notifications are not disabled in the iPad notification settings, so I would like to understand what could cause this situation. I am using a commonly used JavaScript Web Push library to send the push notifications. I would also like to know whether there is any way to detect or confirm that a push subscription is in this state, other than observing that notifications are no longer being delivered. In particular, if the push service returns HTTP 200 but the notification is not delivered and the Service Worker's push event is not triggered, is there any way for the application server or the PWA to determine that the existing push subscription is no longer usable and needs to be renewed?

Hello, I am trying to package and distribute a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. My Apple Developer Program membership is active, and I have already completed the following: Created an explicit Bundle ID. Created an iOS app record in App Store Connect named Kuzey SGK. The app is currently in Prepare for Submission status. I can access the app's Xcode Cloud tab. I can also access Users and Access > Xcode Cloud. According to Apple's documentation: “After creating an app record, navigate to the Xcode Cloud tab. Under Safari Web Extension Packager, click Upload.” However, there is no “Safari Web Extension Packager” section at all under the Xcode Cloud tab for my app. The page only displays the standard Xcode Cloud information and “Get started in Xcode.” I am using App Store Connect from Windows in a web browser. My understanding from Apple's Safari Web Extension documentation is that the web-based packager should allow packaging an existing web extension without requiring a Mac or Xcode. I have not configured a standard Xcode Cloud workflow or connected a source repository, because the Safari Web Extension Packager documentation does not list those steps as prerequisites. Apple Developer Program Support reviewed my request and referred me to the Developer Forums because this appears to be a technical issue. My support case number is 102956602442. Could someone please clarify: Is there an additional step required to enable the Safari Web Extension Packager for a newly created developer account or app? Is a standard Xcode Cloud workflow required before the Packager becomes visible? Is the Packager currently available to all Apple Developer Program members? Thank you.

Hi everyone, I am new to this forum, and I have a question about Safari not displaying my .mp4 videos on my corporate website. This is probably an issue that has been posted before, but any help is welcome. I manage a major Travel portal, and I don't want to disappoint about 30% of my traffic coming in via Safari. Thanks in advance for any help or advice, -Paul

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.