You've already figured out that -[ExtensionsPreferencesOld canEnableExtensions] in /System/Library/PrivateFrameworks/Safari.framework is buggy, hopefully?

Did this change recently? I'm not seeing my extension in a private window with Safari 13.1, but I am seeing it with Safari 14 and Safari Tech Preview.

Sorry, my mistake! The extension was not properly loaded. It's working now in private windows.

I tried to renew my membership a number of times, using Safari, Chrome, and Firefox, and 2 different credit cards. It always failed at the step where it needed further authorization from the bank. My iPhone would even get an authorization code from my bank, but then I couldn't enter it because Apple's page reloaded to an error. Finally I called up developer support on the phone and asked to pay over the phone. I was escalated to another person, and I was able to successfully pay and renew. They had to take my credit card info verbally.

Are you building on the same machines or different machines? If different machines, you may need to manually download the new WWDR intermediate certificate and install it in the keychain.

I can confirm this. The externalPort is 0 in my DNSServiceNATPortMappingReply despite kDNSServiceErr_NoError. I'm calling directly in my app's code, not via XPC.

Update: This Slack channel has been shut down. There was a lot of initial interest, but it never really caught on, and it was mostly quiet after the first couple of weeks. If the Developer Forum moderators could delete my post, I'd appreciate it. I can't seem to do it myself.

The Remote Audio Output Protocol, AKA AirTunes, AKA AirPlay, has been using port 5000 since the year 2004. This is nothing new. All AirPlay receivers including AirPort Express and Apple TV use port 5000. If you've ever used Airfoil on your Mac (Airfoil Speakers was released in 2008), that also uses 5000 for the same reason. AirPlay receiving is new to macOS Monterey, but AirPlay itself is very old, predating Flask and these other web development environments. No, Apple is not trying to make web development difficult.

According to Chrome's own documentation, "DOM-based timers, such as window.setTimeout() or window.setInterval(), are not honored in non-persistent background scripts if they trigger when the event page is dormant. Instead, use the alarms API." https://developer.chrome.com/docs/extensions/mv2/background_migration/#timers

This has always worked for me in Safari. Are you using Manifest V2 or V3?

Quinn, I just got this warning, but I don't want to use TestFlight for Mac. Is there any way to avoid getting the warning?

By the way, this sounds like a great way to get rejected by App Review: "How you do that depends on how your app is built. With Xcode it’s as simple as enabling a restricted entitlements on your app target." I've gotten rejections in the past for unused entitlements.

By the way, I'm maintaining a public list of Safari extension bugs, if anyone is interested in adding theirs here: https://github.com/lapcat/SafariExtensions/issues

I've discovered that this is a bug in Xcode 15 that doesn't correctly handle a symlink from ~/Library/Developer to /Users/Shared/Developer The symlink was never a problem in Xcode 14 and earlier. FB12363725

See this bug, with workaround: https://github.com/lapcat/SafariExtensions/issues/41