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!

I'm debugging an odd situation wherein my app MarsEdit, which is sandboxed but has entitlements to send Apple events to BBEdit, is blocking from sending those events only with the newest version of BBEdit (13.5). For example, sending events to BBEdit 13.1 I have debugged the problem enough to learn that the failure occurs in the Apple events infrastructure, attempting to locate and open a port for the delivery of events. In the working case, I witness the following debug console message: SUCCESSFULLY found another process by bundleID using the new appleeventsd server, "com.barebones.bbedit", port=( port:124783/0x1e76f rcv:0,send:2,d:0 limit:0) Whereas in the broken case, I see: debug 22:57:10.873976-0400 MarsEdit Couldn't find a process with pid 11325 SUCCESSFULLY found another process by bundleID using the new appleeventsd server, "com.barebones.bbedit", port=(null machport) My best guess is that BBEdit 13.5 is being made "invisible" to MarsEdit based on a failure to apply the entitlement MarsEdit has to send Apple events to "com.barebones.bbedit", when targeting BBEdit 13.5. I have confirmed that disabling the sandbox for my app causes the event delivery to succeed. I have also reproduced the error, which culminates in a -600 OSStatus error from AESend, in a trivial sandboxed test app which just tries to send an event to BBEdit. Anybody have any ideas why BBEdit 13.5 might cause the system to exhibit this nuanced difference in behavior? It kind of smells like a "linked on or after" behavioral difference, which might make sense given the BBEdit 13.5 release seems to have been built on and linked with a newer SDK than previous releases. Here is the complete source code for a sample app's App Delegate that exhibits the bug. Create a new, sandboxed Mac app with this as the app delegate source if you interested to reproduce the problem. Make sure to add a com.apple.security.temporary-exception.apple-events entitlement for com.barebones.bbedit. (NSAppleEventDescriptor*) targetDescriptorAppWithIdentifier:(NSString*)bundleIdentifier { // Prefer a running instance NSRunningApplication* runningApp = [NSRunningApplication runningApplicationsWithBundleIdentifier:bundleIdentifier].firstObject; if (runningApp == nil) { NSWorkspace *workspace = [NSWorkspace sharedWorkspace]; NSURL* targetURL = [workspace URLForApplicationWithBundleIdentifier:bundleIdentifier]; if (targetURL != nil) { NSDictionary* launchConfig = @{}; NSError* launchError = nil; runningApp = [workspace launchApplicationAtURL:targetURL options:0 configuration:launchConfig error:&launchError]; } } if (runningApp != nil) { return [NSAppleEventDescriptor descriptorWithProcessIdentifier:runningApp.processIdentifier]; } return nil; } (NSAppleEventDescriptor*) appleEventForOpeningFileAtPath:(NSString*)filePath withApplicationBundleID:(NSString*)appBundleID displayingCustomPathString:(NSString*)customPathString { NSAppleEventDescriptor* targetDescriptor = [self targetDescriptorAppWithIdentifier:appBundleID]; NSAppleEventDescriptor* openFileEvent = [NSAppleEventDescriptor appleEventWithEventClass:kCoreEventClass eventID:kAEOpenDocuments targetDescriptor: targetDescriptor returnID: kAutoGenerateReturnID transactionID:kAnyTransactionID]; // Dont need actual file parameters to exhibit the connection return openFileEvent; } (void)applicationDidFinishLaunching:(NSNotification *)aNotification { AEDesc reply = {typeNull, NULL}; NSAppleEventDescriptor* openFileEvent = [self appleEventForOpeningFileAtPath:@"/tmp/hello" withApplicationBundleID:@"com.barebones.bbedit" displayingCustomPathString:@"HI"]; OSStatus status = AESend([openFileEvent aeDesc], &reply, kAENoReply, kAENormalPriority, kAEDefaultTimeout, NULL, NULL); NSLog(@"Got AESend status %d", status); } If you launch BBEdit 13.5 so that it is running while the test app runs, you will see a -600 error from AESend, whereas if you launch BBEdit 13.1 so that it is running, you will see a noErr.

Just in case it's affecting anybody else, I have filed a feedback FB7834896 detailing the fact that Big Sur crashes in AppKit's toolbar-based title view code, when I change the fileURL of my document. This is the head of a typical crash log: 0	 CoreFoundation											0x00007fff2a9e66a3 __exceptionPreprocess + 242 1	 libobjc.A.dylib										 0x00007fff70324837 objc_exception_throw + 48 2	 CoreFoundation											0x00007fff2aa0f34e +[NSException raise:format:arguments:] + 88 3	 Foundation													0x00007fff2d545519 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191 4	 AppKit															0x00007fff277e5baf -[NSStackView insertArrangedSubview:atIndex:] + 924 5	 AppKit															0x00007fff27fa3f0d -[NSToolbarPrimaryTitleContainerView _configureWithRepresentedURL:] + 97 6	 AppKit															0x00007fff27fa3d68 -[NSToolbarPrimaryTitleContainerView updateTitleProperties:] + 217 7	 AppKit															0x00007fff27fa5ac8 -[NSToolbarTitleView _updateTitleProperties:] + 1103