In the Xcode 16.2 release notes, it says to avoid a memory leak in Swift 6 you should "Pass -checked-async-objc-bridging=off to the Swift compiler using “Other Swift Flags” in Xcode build settings." https://developer.apple.com/documentation/xcode-release-notes/xcode-16_2-release-notes#Swift However, when I add this value to OTHER_SWIFT_FLAGS (either in the Xcode build settings interface, or in an .xcconfig file), it yields a build error: error: Driver threw unknown argument: '-checked-async-objc-bridging' without emitting errors. Does anybody know if there's a trick to get this working that isn't explained in the release notes?

Due to changes in macOS 15 Sequoia with respect to container privacy/privileges, I have observed warnings with one of my apps (non-sandboxed) when its subsidiary crash reporter process tries to access the host app's data folder. I THINK I've worked around this issue by granting the crash reporter and the host app access to the same application group. I'm not 100% sure how all this works except that the problem went away :) The problem is, once the problem goes away on a given system, it goes away for good! Even with subsequent attempts to open a version of the app before the fix was in place, the system warning is not presented. I've tried to reset SystemPolicyAppBundles on the app via tccutil, but it makes no difference. Using the wisdom from one of Quinn's posts (https://developer.apple.com/forums/thread/706442) I set up a log stream invocation to try to gather clues, and I notice that when I launch my app now, I see messages like: Found provenance data on process: TA(82542d1beaf132a6, 2), 51084 Process was already in provenance sandbox, skipping: 51084, TA(82542d1beaf132a6, 2) I suspect this "provenance" may reflect the change in how the system treats my application. First: I wonder if it's a bug that any change in "provenance" should retroactively apply to versions of the app before the change was made. Second, I wonder if there's some way to RESET this provenance so that I can reproduce the bug again? I might be able to reproduce it by changing the bundle ID for the app but for purposes of testing against existing, shipped versions of the app, I'd love to be able to reset things for sanity-checking.

I have a persistent "crash" with at least one of my apps, which appears to be a case of the app either quitting or being force-quit without generating a crash log. The app doesn't subscribe to any sudden termination compatibility or similar. I have a good friend who is a developer who is able to reproduce the issue within minutes, so I've captured a trove of information from him including a complete sysdiagnose. Unfortunately nothing is jumping out at me, and the only things that show up that seem like they might be related are keys like ApplicationWouldBeTerminatedByTAL and NSCanQuitQuietlyAndSafelyKey. I am kind of grasping at straws and would welcome any inspiration anybody can share. What is TAL and is it something the system could be imposing on my app? If there are circumstances where macOS will preemptively terminate a running app, what are they, and how can I figure out which one is causing the quits in these situatoins? I'd love to be able to reproduce the behavior on my own Mac. If it's something I can prevent, great, if it's not, it would be good to know how to distinguish it from a regular crash for reporting purposes. Thanks for any help!