Well, without a GKMatch it's not possible to exchange data with the other players.

Thank you for your insight!

That guide is only useful if you can actually reproduce the issue, but like I said, I cannot reproduce it and the crash was downloaded by Xcode (it happened on another user's Mac).

Unfortunately, like mentioned previously, this is a crash report downloaded by Xcode, and I have no idea how I could reproduce it.

I often have the same issue with crash reports from other users downloaded by Xcode. Right now I had this issue with a crash report transferred from a different partition on my Mac where I tested my app on an older macOS version (macOS 12). Usually I use the atos Terminal command, but surprisingly this time that command never returns or prints anything, even after waiting for 10 minutes. When dragging the crash log to Xcode, the console prints out error: unable to locate main executable (arm64) "~/Downloads/myApp.app/Contents/MacOS/myApp" error: unable to locate main executable (arm64e) "/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit" error: unable to locate main executable (arm64e) "/usr/lib/system/libdispatch.dylib" error: unable to locate main executable (arm64e) "/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation" error: unable to locate main executable (arm64e) "/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox" error: unable to locate main executable (arm64e) "/usr/lib/dyld" error: unable to locate main executable (arm64e) "/usr/lib/system/libsystem_pthread.dylib" error: unable to locate main executable (arm64e) "/usr/lib/system/libsystem_kernel.dylib" crashlog.create_target()...2 crashlog.create_target()...3 crashlog.create_target()...4 error: Unable to locate any executables from the crash log. Try loading the executable into lldb before running crashlog and/or make sure the .dSYM bundles can be found by Spotlight. error: invalid target error: invalid target error: invalid target error: invalid target error: invalid target error: invalid target which seems strange, as it isn't even able to locate the system libraries. Then I opened the crash report in TextEdit and replaced all references to the app path (previously in /Downloads) with the location of the Xcode archive (\/Users\/username\/Library\/Developer\/Xcode\/Archives\/2025-02-12\/myApp macOS 12.02.2025, 08.45.xcarchive\/Products\/Applications\/*\/myApp.app\/Contents\/MacOS\/myApp) and then Xcode symbolication seemed to work ("seemed" because the crash still doesn't make sense to me: apparently it crashed on the line window.toolbar = toolbar which works fine on macOS 15).

Thanks for the detailed explanation. I filed FB16470722. I ran the sample app again but after unmounting the volume and resolving the bookmark with an error, the Files app doesn't show the volume.

Thanks for the detailed explanation. I filed FB16481526.

Thanks for checking. I opened FB16457804. What do XX_NECESSARY_INFO_1 and XX_NECESSARY_INFO_2 mean?

[quote='824169022, DTS Engineer, /thread/770421?answerId=824169022#824169022'] There's a lot of inter-process communication that happens with system features that are hidden away from what you need to worry about at the API level. [/quote] Of course that's very pleasant for us in the end and how it should be. It's just unexpectedly easy for someone used to various XPC mechanisms and distributed notifications to communicate between processes.

Thanks for confirming. Combining the information in this thread and this other thread about App Intents, I was finally able to understand better how they work. It's somewhat unfortunate that there's little to no (written) documentation about AppShortcuts.xcstrings.

Thanks for the explanations. I thought App Intents needed to always be a separate target as they would be executed in a separate process, but for an App Intent that needs the app to run it makes sense that it's declared inside the app. Although I'm still wondering how the Shortcuts app displays the App Intent UI. I guess it's somehow extracted at build time so that it can be loaded and displayed even when the app is not running? That's somewhat counterintuitive to me: the relevant code is in the main target, but available outside the app (in the Shortcuts app).

Thank you for the detailed explanation. == is perfect, I didn't know I could use it.

Thanks for your answer. I assumed this was different than that other thread because in that thread, there's a libc++abi.dylib frame in the stacktrace, which I assume was why the DTS engineer concluded that it's a C++ exception. In this case, there is no such frame.

Another macOS 14.7.2 user contacted me with this issue. Angry that my app isn't "compatible with macOS". I told them to contact Apple support, but they just wouldn't listen. Anyway not sure if that would have helped, as Apple support usually tells people that they should contact the third party developer. Then, with two conflicting answers, the user believes that I refuse to help them. Does nobody at Apple see how frustrating this is for us developers? Is there nothing you can do to mitigate the anger our users have towards us because of issues in your operating system? People apparently are more inclined to believe that the small third party developer is at fault. I even sent them a link to this topic to convince them that it's a known macOS issue, but not sure if they visited it or could even understand it. Would it be too much to ask for Apple to make public announcements about these issues that normal users can understand and that we can point them to when they direct their anger towards us?

Yes, I've already tried GKMatchmakerViewController(invite: invite) as the sample code above also demonstrates. I was already asked this question in FB15864883 1 month ago.