Hello, Is it a normal/usual/expected practice that a Mac App Store submission of a Safari extension takes 3 weeks to review? We have submitted an update for our Safari extension on September 20. Few hours after the submission we got an update stating that the submission state changed to "In Review". Since then it was a complete silence. No updates, no visibility of progress, nothing. We tried to ask Apple Developer Support for help several times and every time got a quite generic response stating that it's still in review which is not helpful considering it takes so long. We also tried to expedite the review a couple of days with no reaction so far. So I am at a bit of a loss on how to proceed. The reason we are stressing this out in several channels is this Safari extension update brings compatibility fixes for the recently released Safari 18 and we are getting customer reports that the old version is not working with Safari 18. That was expected but the hope was that review will not take 3 weeks to complete. Any advice from Apple here or anyone else how to proceed?.. Thanks!

Hello! We have been testing the upcoming Safari 18 on macOS 15 Sequoia betas and noticed one inconsistent detail about Safari Web Extensions support compared to other browser which implement Web Extensions (Chrome, Edge, Firefox). Background We have a Safari Web extension which is monitoring navigation events using browser.tabs.onUpdated API. navigation event subscription code sample browser.tabs.onUpdated.addListener((tabId, changeInfo, details) => { onTabUpdated(tabId, changeInfo, details) }); navigation event handling code sample onTabUpdated(tabId, changeInfo, details) { console.log(`onTabUpdated: ${tabId}`, changeInfo, details); // check URL in the tab for safety } }); If the extension detects that the user navigates to an unsafe URL, it redirects the user to a page hosted by the extension. It's an HTML resource from the extension bundle. The extension is using browser.tabs.update API to redirect a specific tab to an internal page. const internalPage = browser.runtime.getURL("popup.html"); browser.tabs.update(tabId, { url: internalPage }); Discovered problem When we use browser.tabs.update API browser.tabs.update(tabId, { url: internalPage }); to redirect the user from an unsafe page, we notice that the redirected tab changes its identifier. We know that is the case because we see another API firing. It's called browser.tabs.onReplaced. We have a similar subscription for those events. When the page is redirected, the onTabReplaced handler is firing and informs us about the tab ID change after the redirect. onTabReplaced(addedTabId, removedTabId) { console.log(`onTabReplaced: ${removedTabId} -> ${addedTabId}`); } This is problematic for us in several ways: The extension keeps track of the tab ID so that when the embedded HTML page is loaded, it can still tell the user about the original URL that was blocked. The behavior observed in Safari 18 breaks current expectations of our code and breaks the functionality of our extension. This behavior is specific to Safari 18. Safari 17 does not behave this way which means that we will need to deploy an update to our Safari extension to mitigate that bug on the upcoming Safari version. Moreover, this behavior is not observed in other browsers which implement Web Extensions standard (Chrome, Edge, Firefox). All these browsers preserve the tab ID after redirect. That is a problem for us as we run the same code in all 4 browsers that we support. This will cause increase of code complexity to cover Safari as an exception out of common rule. Environment Safari version 18.0 (20619.1.26.31.6) and all prior Safari 18 betas. issue does not happen on Safari 17. macOS 15 beta 8 (24A5331b) and all prior macOS 15 betas. issue has been successfully reproduced on macOS 14 with Safari 18 betas which points to the fact that the issue is not exclusive to macOS 15. Safari 18 brings the faulty logic. The issue has been confirmed and reproduced in a sample Xcode prowejt provided by Apple called "Sea Creator". So the issue is not specific to a single extension. Feedback case FB14975378. It contains sample code, the full Xcode project, screenshots and sysdiagnose. Any advice or assistance is highly appreciated!

Hello! I was wondering if any other developers are experiencing issues with accessing the web extension background script console, sources, etc. on the latest Safari Technology preview or macOS Sequoia betas. We have an extension which has a persistent background script. In the latest public release of Safari version 17.5 (19618.2.12.11.6) on macOS Sonoma, everything works as expected. When I enable developer mode in Safari, it shows an additional "Develop" menu and when I select "Web Extension Background Content" in the dropdown, it shows a list of background pages for all installed extensions. Attaching a screenshot for reference. However, if I install the latest Safari Technology Preview 197 on macOS Sonoma or just test with the Safari version that comes with MacOS Sequoia beta 1 or beta 2, the "Web Extension Background Content" dropdown menu does not list any background pages. Attaching a screenshot for reference. We started discussing the issue with Apple during the latest WWDC. If anyone at Apple sees this post, I opened FB13834388 to track this issue. However according to Apple, they cannot reproduce the issue exactly as I see it on all macOS machines around me including clean virtual machines, real hardware (MacBook Pro M1 Max, MacBook Air M2, MacBook Pro Intel based). The "Web Extension Background Content" menu looks as expected on their end which is very confusing to me... I have a reason to believe that new Safari's developer tools are simply broken in the latest release. I base that statement on the fact that I cannot access it in case of our own Safari extension, Apple's sample "Sea Creator" extension and a few random extensions that I got from the App Store. I was wondering if anyone else can observe the same behavior or all machines around me are haunted :) Please share if you have similar issues with Safari Technology Preview 197 or Safari on the latest macOS Sequoia beta. Any feedback is important to us. If it's a widespread issue, then Apple should prioritize is accordingly. If the issue is somehow specific to our testing, we will fix it on our side. But any test results at this point are bringing more clarity to the situation and are highly appreciated.

Hi. We noticed quite a strange behavior in SPM where it does not warn about missing return statements in Objective-C. Is this behavior expected? Create an Xcode project in Objective-C Create an SPM package in Objective-C Add a method in the SPM package that returns a BOOL Leave the body of the method empty (no return statement) Import the package in the project and invoke the method in the project Expected: Build fails due missing return statement Observed: Build succeeds and every time the method is run, it returns random values Feedback: FB11558487 Is there a way to tell SPM to inherit build/compile flags from the Xcode project? When I try to do the same on the Xcode project side, I get the expected behavior. Build fails and I must fix the issue before proceeding. But not in case with SPM.

It looks like notarization submissions stopped going through. According to notarytool logs, the package gets successfully uploaded but processing never finishes. Our current timeout is 30 minutes. After 30 minutes of silence we see: *** Package "package-name" was REJECTED by notary service! The status of notary service looks green on the service status page: https://developer.apple.com/system-status/. But it does not seem to be the case in reality.

Hi, Our product package signing started failing out of the blue earlier today (still happening) 2022-03-09 14:33:24.782 productsign[91848:49800859] CMS signature encoding failed: A timestamp was expected but was not found. (-67882) We were wondering if the timestamp server is down or experiencing issues? What could be an issue here? Thanks. Best regards, Arthur

Hello! The documentation on ATS refers to "apps and app extensions" as scope. https://developer.apple.com/documentation/security/preventing_insecure_network_connections Does this limit its availability to apps that are running in the user context? The question is: do we get ATS protection in case of a launchd job? Let's say there is a launchd job (running in uid 1 context). It initiates network requests using URLSession API. Does it get ATS by default? Is there a way to validate that? Is it correct to assume that high level network API such as URLSession use ATS by default? Thanks. Best regards, Arthur

Hello, We have an AV product for macOS that uses Endpoint Security APIs for authorizing various system activity. The latest Monterey beta 6 introduced support for an event called "ES_EVENT_TYPE_AUTH_COPYFILE" which according to the release notes should be triggered for "copyfile" system call. The problem is I cannot seem to find any activity that actually ends up triggering this system call while using the latest Monterey beta. "/bin/cp" generates two open system calls More high level NSFileManager "copyItemAtPath:toPath:error:" generates a clone event There is a "copyfile" C function that is defined in "copyfile.h" also generates two separate open calls. Did someone figure out how to trigger it or could someone from Apple give a comment? We'd usually ask such question via DTS ticket but it's about beta software so we decided to start her on the forum. Thanks. Best regards, Arthur

Hello! We rely on applications launch date information provided by NSWorkspace. Our main applications of interest are browsers (Safari, Chrome, Firefox). We've noticed that NSWorkspace on Big Sur returns "nil" for all running applications including those that we are primarily interested in. This can be easily reproduced with the code sample below [[[NSWorkspace sharedWorkspace] runningApplications] enumerateObjectsUsingBlock:^(NSRunningApplication * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) { NSLog(@"App %@ launched at %@", obj.bundleIdentifier, obj.launchDate); }]; The issue is observed in all released beta builds of Big Sur including the latest beta 4. Submitted the same report in feedback assistant: FB8098936 Will this be fixed? Or we should start thinking of alternative approaches for getting the launch date? Thanks. Best regards, Arthur