I have discovered a system database at: /var/db/SystemPolicyConfiguration/ExecPolicy Which seems to contain the pertinent provenance information. I am hoping there is a command line tool that will reset values in this database so that I don't have to go wild and try hacking the file myself. But this gives me a lead at least! I'll try it in a VM first...

I was able to get this working just now with a simple programmatic demo: struct ContentView: View { var body: some View { VStack { RealityView { content in let sphereResource = MeshResource.generateSphere(radius: 0.05) let myMaterial = SimpleMaterial(color: .blue, roughness: 0, isMetallic: true) let myEntity = ModelEntity(mesh: sphereResource, materials: [myMaterial]) var collision = CollisionComponent(shapes: [.generateSphere(radius: 0.05)]) collision.filter = CollisionFilter(group: [], mask: []) myEntity.components.set(collision) let input = InputTargetComponent(allowedInputTypes: .all) myEntity.components.set(input) let hoverComponent = HoverEffectComponent() myEntity.components.set(hoverComponent) content.add(myEntity) } } .frame(width: 800, height: 800) .padding(30) .background(.black) } } Maybe if you can get this simple example working it will help you see how yours differs. Daniel

From the Xcode 15 Release Notes: Fixed: Resolved an issue where the “Manage version and build number” distribution option in Xcode and Xcode Cloud overwrote the version and build number of framework dependencies in apps. When distributing an app, framework dependencies retain their original version and build numbers. (106869375) So it seems the change was intentional, presumably because other people found it problematic that Xcode was overwriting their framework's Info.plist values. If you have a framework dependency that doesn't include version information it's probably a good idea to file a bug with them to ask them to add the pertinent values.

I wrote extensively about the issue with the warnings, how to suppress them, and how to conditionalize the suppression to only apply to Xcode 15: https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/ https://indiestack.com/2023/10/conditional-xcode-build-settings/ Hope that helps somebody!

It appears that adding -Wl,-no_warn_duplicate_libraries to "Other Linker Flags" will quiet the warnings.

I continue to see this issue as well, including with the new 5.1 beta today. I think the root of the problem is the way Xcode evidently collects inferred library linkage for dependent Swift Packages. At least, that's one easy scenario to reproduce the bug with. @eskimo : I filed FB13229994 with a simple example project demonstrating (I hope) the issue.

I found this explanation very useful in the context of debugging an off-by-one-day bug in my crossword app. It's a classic scenario where crosswords are referenced by date but without a specific time, except that the date is usually reckoned by the time zone of the host publication. I thought I would share an example of how I'm addressing the issue using the defaultDate technique, but generalizing it to choose a "middle of the day" time that should work with whatever time zone (Quinn's example uses a fixed relative time interval that is specific to Sao Paolo). Given a date formatter that already has the desired time zone set on it: var midDayComponents = DateComponents(hour: 12) midDayComponents.calendar = Calendar(identifier: .gregorian) midDayComponents.timeZone = dateFormatter.timeZone dateFormatter.defaultDate = midDayComponents.date It seems that all you need is an hour, a calendar, and a time zone to come up with a suitably mid-day date. I hope this helps somebody!

If anybody is curious, I wrote a blog post detailing the process of diagnosing this issue: https://bitsplitting.org/2022/06/18/purgeable-mac-apps/

I appreciate the extra information. I also was able to discover that it's a public API, CSDiskSpaceStartRecovery, that kicks off the deleted purging behavior. I'll figure out how to detetct this kind of termination and avoid sending a crash report about it!

I managed to trace this down to the system frameworks level inside the private DeleteCache.framework. It seems that this framework runs a daemon, "deleted" which is responsible for handling requests to free up purgeable space. This is likely to happen when the system notices there isn't much disk space left, or when a 3rd party utility such as CleanMyMac specifically requests (I think via SPI) that the space be purged. I guess the system considers this enough of an emergency tactic that it doesn't hesitate to proactively terminate the corresponding apps to which the purged caches belong. Thanks for inspiring me to look into this more deeply, Quinn. I think I'm all set now and hopefully this thread will serve as a reference for others who might run across the mysterious quitting behavior.

Sorry for the blast of follow-up messages, but now with the clue of "RunningBoard" I came across this article, https://eclecticlight.co/2019/11/07/runningboard-a-new-subsystem-in-catalina-to-detect-errors/, which includes an eyebrow-raising sentence: Catalina brings several new internal features, a few of which have been documented, but others seem to have slipped past silently. Among the latter is an active subsystem to replace an old service assertiond, which can cause apps to unexpectedly terminate – to you and me, crash – in both macOS 10.15 and iOS 13: RunningBoard. Given the seemingly pertinent RunningBoard termination in the log, and the allusion to "unexpected termination" by the article cited, I think I am on to something here!

I think I might have a breakthrough. Scanning the sysdiagnose from my friend's Mac I came across this line in launchd.log, which I think correlates with one of the unexpected terminations: 2022-05-03 09:15:22.088718 (gui/501/application.com.red-sweater.marsedit4.384452971.384452977 [13840]) : exited with exit reason (namespace: 15 code: 0xbaddd15c) - OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches requesting termination assertion for com.red-sweater.marsedit4 reportType:None maxTerminationResistance:NonInteractive attrs:[ When I search my own Mac's launchd logs for RBSTerminateContext, I only find it a few times relating to the Apple News app and some message about Catalyst apps not being permitted to "task-suspend."

I see now that there is a distinction between "automatic" and "sudden" termination, and I think the "automatic" termination is the one that correlates with TAL. I'll take a closer look at these keys, maybe even if I don't specify support for either one I can enable them to get a better feeling for whether the behavior I then see matches what other users are seeing.

Oh, thanks Quinn! I missed this reply until now in the hubbub of WWDC week. Yes, when the app crashes it is apparently always "lurking in the background," so it matches up with the profile of what TAL is purported to do. However, the app hasn't opted in to sudden termination, and reports of the problem suggest the app's icon does disappear from the Dock when the issue occurs. It's also affecting a couple other apps on one of the users' systems, but always the same few apps! Any other inspirations about things I can ask the person who reproduces it regularly to try? Or things to look for in the log about reasons it might be terminated? Thanks so much! Daniel

I was frustrated by this today and decided to dig into it. tldr: pass "-cv_note 0" to quiet just these messages and not all system logs. You can read more about my analysis here: https://indiestack.com/2022/03/quieting-cvdisplaylink-logging/