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.

Using an App Clip link encoded into a QR Code shows an error when scanning the encoded QR Code on an iPhone or iPad. After being scanned, the App Clip's banner is visible, but a message says: "App Clip Unavailable". Accessing the same App Clip URL via Safari works as expected. I've filed a feedback with more details and screenshots of the issue here: FB17891015 Thanks!

Even default Safari Web Extension project is not displayed on iOS 18.4 simulator ("No extensions installed"), so it's not possible to test extensions in simulator, only on real device.

I have a UI application built with the Vue framework, using Vuetify for the UI components. There's a div with the class v-application--wrap, which is provided by Vuetify. This class internally includes the following style rule. .v-application--wrap { backface-visibility: hidden; display: flex; flex: 1 1 auto; flex-direction: column; max-width: 100%; min-height: 100vh; position: relative; } The pages were rendering correctly up to version 18.3, but after upgrading to version 18.4, we encountered layout issues related to height. Upon investigation, we discovered that the min-height property was no longer being interpreted or applied correctly. Replacing min-height with height resolved the issue, and the pages began loading as expected. Any insights into why this behavior is occurring would be greatly appreciated.

Hi! Is there any fix: Sounds are not recreated while using websites with, for example, virtual piano keyboard or metronome.

Dear Apple Developer Support Team, I am writing regarding critical issues we are facing with Safari web push notifications in our application iLiveMyLife.io, which is severely impacting our ability to maintain reliable communication with our users. Issue Description: We are experiencing persistent problems with Safari push notification tokens expiring or becoming invalid without any notification to our server. This creates several critical issues: Users stop receiving notifications without any indication of failure Our notification delivery system has no way to detect token expiration The expiration appears to happen frequently (seemingly almost daily in some cases) There is no reliable mechanism to re-establish push communication without users manually revisiting the app Technical Impact: Our messaging functionality becomes completely unreliable We must resort to email or SMS as fallback mechanisms, which is not feasible for a real-time communication platform This makes building any reliable messaging application on Safari practically impossible The Broader Context: What makes this situation particularly challenging is that all potential alternative browser APIs that could help address this issue appear to be deliberately disabled or restricted in Safari: Background Service Workers don't function in the background on iOS Safari Background Sync API is not supported WebSockets cannot operate when the app is closed There's no way to programmatically check the validity of push tokens The combination of these limitations creates a situation where developers have no viable technical path to build reliable notification systems for PWAs on Safari. This appears to be a systematic restriction rather than individual API limitations. Requested Information: Is there a recommended approach to detect Safari push token expiration? Are there alternative notification mechanisms for PWA applications on Safari that offer more reliability? Is there documentation on the lifecycle of Safari push tokens that could help us implement proper handling? Are there plans to improve the Web Push API implementation in Safari to address these reliability issues? Could you clarify if these limitations are intentional design decisions or technical constraints that might be addressed in future updates? Business Impact: This issue fundamentally undermines our platform's core functionality. For a collaborative tool, reliable notifications are essential - users cannot collaborate effectively if they miss updates because their push tokens silently expired. The current state creates confusion among our users, who don't understand why they suddenly stop receiving notifications. Any guidance or assistance you could provide would be greatly appreciated. We're committed to providing an excellent experience on Safari, but the current push notification limitations make this extremely challenging. Thank you for your time and consideration. Best regards, Ilya

Hi Team, Our team member trying to enroll through the invite in Apple Developer portal Note: Phone number is valid but still we are getting this error. It happens in all the browser

Hi, I’m working with the SFExtensionProfileKey in my Safari Web Extension. As I understand it, this key is to get the UUID of the profile currently in use. However, it seems to be missing (no key in userInfo) when the default profile is active. Also, I haven’t found any API to get a profile’s human-readable name or list all available profiles. Could someone clarify: If the value of SFExtensionProfileKey is absent, can I safely assume the default profile is in use? Is there a supported way to get a profile’s display name? Does Safari expose an API for getting all profiles? Thanks in advance for your insights!

WKWebview of iOS 18 includes Safari browser. When playing videos, some videos show "NotSupportedError: The operation is not supported.", but it is normal on iOS15 devices. The video link is as follows. Even if it is downloaded and referenced locally in HTML, it cannot be played, so it is ruled out that it is a network problem. https://ydtj-adas.oss-cn-shanghai.aliyuncs.com/e6yun.com/exam/exam/a35447b496b94e5e9a6aab27d62c867e.mp4 cannot be played https://ydtj-adas.oss-cn-shanghai.aliyuncs.com/e6yun.com/exam/exam/82d970957a7d4e8d88c13cd101143005.mp4 can be played

As with the adoption of MV3 standards among all major browser vendors that allow browser extensions at the client-side, I understand that this is the same with Safari as well, as mentioned here (https://www.wwdcnotes.com/notes/wwdc22/10099/). However, as with Firefox, browsers may choose to adopt them incompletely and with few changes. I had a few questions regarding how Safari views this transition and what would be the next steps from here. Thus, it would be really great if the browser team could provide your insights on any or all of the following points: Would Safari adopt the exact standards proposed by the Chromium ecosystem such as with functionalities like header-based modifications in the coming days.  What would be the general timeline be for this in general?  Does this also translate to the fact that existing standards with MV2 standards would not be allowed to operate any further, as with the timeline with Chromium? Regards

The extension popups don't seem to support the dark mode media query. The only way the query gets detected is when a color-scheme is added: <meta name="color-scheme"content="light dark">

On iPhone 16 running iOS 18.0(Xcode 16.2), cookies configured with SameSite=None; Secure fail to apply correctly—iOS forcibly converts the attribute to SameSite=Lax. As a result, cross-site requests from H5 pages within our app cannot carry the required cookies, causing failures. Can anyone help me on this? Thanks in advance.

Hi Apple Devs & WebKit Team, We operate https://outdoorgala.com — a verified, HTTPS-secure Canadian ecommerce site focused on elite outdoor safety gear. We're Indigenous-owned, based in Alberta, and take customer trust and compliance seriously. However, Safari (iOS + macOS) is falsely flagging our site as “deceptive,” preventing customers from accessing us — even though: We use GoDaddy Website Builder with no redirections or malware All product links are clean, HTTPS-secure, and tracked ethically We recently implemented a fully compliant cookie banner (Accept/Decline logic) A public security.txt and OpenPGP key has been published: https://outdoorgala.com/security No phishing, malware, or cloaking behavior exists on the site We’ve already submitted a review via: ➡️ https://websitereview.apple.com And filed a bug report via Feedback Assistant (FB17608544) What else can be done to speed up review or get flagged domains unblocked in Safari? This is hurting our business and blocking consumer access — despite following all Apple guidelines. Would appreciate any insights or escalation tips. Thank you! – Derek Eiteneier Founder, Outdoor Gala

We have an existing Safari App Extension distributed outside the App Store (self-distributed). Recently, we converted another browser extension to a Safari Web Extension and used the same bundle ID as the original application to avoid any change on the CX side. After distributing this updated app, we noticed that the Safari extension was disabled on users' machines, and users are now required to manually re-enable it in Safari's preferences. Is this the expected behavior and is there way to avoid this for future updates ?

Starting in iOS 18.4, (and still in the iOS 18.5 beta), the AVPlayer seems to freeze when we: Replace the current AVPlayerItem, ReplaceCurrentItemWithPlayerItem and then: Call Seek very shortly afterwards (seekToTime:toleranceBefore:toleranceAfter: / seek(to:)) And then subsequent calls to play after have no effect. However, it feels scrubbing to see after works and also changing the playback rate (i.e. fast forward) tends to clear up the frozen state. Our primary workflow involves video playback, replacing video to show new clips and in some cases seeking to specific frames. This appears to only be occurring while streaming video, reports are all that local downloaded video playback remains fine. This same code path has worked without issue on 17.x and 18.3.2 and for years before that. What is particularly strange is that time observers log that video is still playing or feeding frames. The reported status is ReadyToPlay, IsLikelyToKeepUp is true, and there are no indications of stalling or buffering. A similar issue is true for our web application in Safari. While on Sonoma and Safari 17.x, there is no issue. When you update to macOS Sequoia 15.4.1 and Safari 18.4, you begin observing a similar freezing. The same does not occur on Chrome or other tested browsers. There appears to be in the release notes for Safari 18.4, an interesting "fix" note that seems similar to what we are now experiencing: https://developer.apple.com/documentation/safari-release-notes/safari-18_4-release-notes "Fixed an issue where playback doesn’t always resume after a seek. (140097993)" "Fixed playing video generating non-monotonic ‘timeupdate’ events. (142275184) (FB16222910)" "Fixed websites calling play() during a seek() is allowed by the specification so that the play event is fired even if the seek hasn’t completed. (142517488)" "Fixed seek not completing for WebM under some circumstances. (143372794)" "Fixed MediaRecorderPrivateEncoder writing frames out of order. (143956063)"

I want to migrate from a Safari App Extension to a Safari Web Extension, but don't know how to get rid of the message, telling users that my extension can access their passwords. Here is a message which I see: I was thinking that this might be because all Safari Web Extension get this type of access, but I have a Safari Web Extension which does not require such level of access: Here is the manifest: { "manifest_version": 2, "default_locale": "en", "name": "__MSG_extension_name__", "description": "__MSG_extension_description__", "version": "1.1", "icons": { "48": "images/icon-48.png" }, "background": { "scripts": [ "background.js" ], "persistent": true }, "browser_action": { "default_popup": "popup.html", "default_icon": { "16": "images/toolbar-icon-16.png" } }, "permissions": [ "nativeMessaging", "tabs" ] } and here is the Info.plist file: Here is the entire code of the extension: https://github.com/kopyl/web-extension-simplified

updateDynamic rules is blocking ads on my device with iOS 17.4, but on my iOS 18 device the same code is not blocking ads. Is this a known issue?

Hello, According to the documentation: If you provide your extension in macOS and don’t want to use the Mac App Store for distribution, you can sign and notarize your extension’s app with a Developer ID to distribute it outside the Mac App Store. However, I found this to be untrue in practice. Even after signing and notarising the Safari extension correctly, it is not possible to enable it in Safari without turning on "allow unsigned extension". This makes it impossible to distribute your Developer ID–signed and notarized extension outside the Mac App Store. I would like to distribute my web extension directly to employees in my organization using MDM without having each user manually enable "allow unsigned extension" for it to work. Any way to make it work? The documentation is quite confusing in this aspect, it says "Safari only supports signed extensions" but my extension is rejected even if notarised and signed.

Hi Everyone, I’m currently working on a flow where a web page redirects to our app to perform certain actions, and then returns the user back to the browser. However, on iOS, the only way to go back to the browser is by using the openURL method. The issue is that this method can only open the browser app itself—it can’t control which tab or page is shown, so the user doesn’t return to the original tab they came from. The same limitation also applies to Android. Furthermore, iOS doesn’t allow an app to programmatically return to the previous app (in this case, the browser). While Android doesn’t have an official way either, in some cases, the OS automatically returns to the previous app when ours is closed. I’d like to ask: Is there any known method or workaround that allows returning from my app back to Safari (or the default browser) and restoring the previously active web page or tab? Or, is there any way to programmatically return to the previous app from within my app? Thanks in advance for your support!

I’ve been working on a personal iOS project for fun — essentially a YouTube music player, learning how background media playback works in native iOS apps. After seeing that Musi (a famous music streaming app) can play YouTube audio in the background with the screen off — I got really curious. I’ve been trying to replicate that basic background audio functionality for YouTube embeds using WKWebView. I've spent a crazy amount of time (probably 20 hours) trying to figure this out but have achieved no success. Here’s what I’ve tried so far: -Embedding a YouTube video in a WKWebView -Activating AVAudioSession with .playback and setting .setActive(true) -Adding the UIBackgroundModes key with audio in Info.plist -Adding the NSAppTransportSecurity key to allow arbitrary loads --Testing on a real device (iPhone 14, iOS 18.1 target)-- What happens: Audio plays fine in the foreground. If I exit the app and go to the lock screen quickly enough (less than 3 seconds) after pressing play, I can resume playback briefly from the lock screen — but it doesn’t automatically continue like in Musi and other apps like it. Most of the time, the audio stops when the app is backgrounded. I get this error consistently in the logs: Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)" It seems like the app lacks some specific entitlements related to WebKit media playback. I don’t have AppDelegate/SceneDelegate (using SwiftUI), but can add if needed. I’m super curious how music streaming apps using youtube as a source get around this — are they doing something different under the hood? A custom player? A SafariViewController trick? Is there a specific way to configure WKWebView to keep playing in the background, or is this a known limitation? Would really appreciate any insight from folks who’ve explored this before or know how apps like Musi pulled it off. Thanks in advance!