The new .ips format does not seem to provide a way to know whether a binary is part of macOS.
Ref. https://developer.apple.com/documentation/xcode/examining-the-fields-in-a-crash-report
[Q] Is it really the case?
If it's not part of the information inside a .ips file, how is it supposed to be determine now? loadAddress ranges?
Just asking for a friend.
I was curious about this myself, so I ended up discussing it with some colleagues. I don’t have a complete answer for you, but I do have some general thoughts.
The new .ips format does not seem to provide a way to know whether a binary is part of macOS.
…
Is it really the case?
Yes. If, after reading the rest of this response, you still think the JSON should include this info specifically, I encourage you to file an enhancement request to that effect. Please post your bug number, just for the record.
how is it supposed to be determine now?
Apple’s crash reporter is not doing anything clever here. It applies a plus (+) to non-Apple code, where Apple code has either:
A SIP-protected path prefix, like /System
A bundle ID that starts with com.apple.
How valuable is that? I’m not entirely sure. It’s certainly not hard to spoof, but it does provide a quick way to identify potential issues.
*shrug*
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Thanks for the info.
I don't remember where I saw this but indeed, there seems to be some checks with paths such as /System/, /Library/Apple/, /usr/bin, and bundle identifiers such as com.apple.* , Motion,…
The issue with the com.apple.* pattern is that when Xcode crashes (yes, it happens), you end up with something incorrect where the Xcode binary and its linked embedded frameworks are not considered user code but its embedded Swift Libraries are…
