dsym file

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is Open In Place compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the In Place capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider suppor

I am developing an application on macOS in SwiftUI which exchanges files with other processes on a network. Some of these processes may be on Linux and write to a network drive. The files are refreshed at 10, 15 or 60 second intervals, and keep the same name. The software is supposed to run 24/7 and have persistent paths, so that on restart it does not need setting up. And it runs in the sandbox. I have got this working with macOS-only external processes by putting the exchange files in a fixed folder on the network storage and using security-scoped bookmarks to the file and or folder. But it doesn't work so well when one of the writing processes is a Linux process writing to its own storage. I can put a symlink in my fixed folder and if i select the folder and the symlink after each app restart, it works. but how can i make such a set-up persistent so it works after app restart without manual selection?

We are trying to implement a custom encryption scheme for our Core ML models. Our goal is to bundle encrypted models, decrypt them into memory at runtime, and instantiate the MLModel without the unencrypted model file ever touching the disk. We have looked into the native apple encryption described here https://developer.apple.com/documentation/coreml/encrypting-a-model-in-your-app but it has limitations like not working on intel macs, without SIP, and doesn’t work loading from dylib. It seems like most of the Core ML APIs require a file path, there is MLModelAsset APIs but I think they just write a modelc back to disk when compiling but can’t find any information confirming that (also concerned that this seems to be an older API, and means we need to compile at runtime). I am aware that the native encryption will be much more secure but would like not to have the models in readable text on disk. Does anyone know if this is possible or any alternatives to try to obfuscate the Core ML models,

This is stemmed from another forum post on Apple Unified Logging. A few additional questions were raised towards a relevant but different topic - activity tracing, starting a new post following The Eskimo's suggestion. The first question is on log capture from an activity chain. The related documentation stated something but very vaguely. https://developer.apple.com/documentation/os/generating-log-messages-from-your-code?language=objc#Choose-the-Appropriate-Log-Level-for-Each-Message If an activity object exists, the system captures information for the related process chain We had hoped that this would somewhat play into the speculative logging approach we had touched upon in the original post, in the sense that if we try to log an error or fault within an activity, then it helps to capture and persist other logs on the activity chain even though they are originally not meant to be. But unfortunately from our test it didn't seem to be behaving towards that understanding. Then our question is, if we may ask -