Just received an exception ticket related to a (App-Wrapper) code signed desktop app, in this case on an MacBook Pro equipped with a M1Pro chip running Monterey. From first crash log it looked like a declare into NSAlert would fail, which would be very strange. Deeper inspection revealed several lines like this:
kernel AMFI: constraint violation /Applications/myApp.app/Contents/Frameworks/XojoFramework.framework/Versions/A/XojoFramework has entitlements but is not a main binary\
all related to usual Xojo frameworks which I suspect to be the cause of the app not starting at all for this user.
Did someone run into this too? What could be causing such a system behaviour?
2022r4.1. And the question about the app location is one point on my questions to the user. Also to try that funny “amfi-get-out-of-my-way” command line command.
I hope they simply tried to start it from a wrong location. Otherwise the question still remains is “What makes their system react this way?”
So IIRC, “Technically” only bundles (excluding Frameworks) and unbundled commandline apps (helpers) should be signed with entitlements.
However, I don’t recall exactly why, but when adhering to this, some apps had trouble loading nested dylibs. Really rummaging my mind leads to believe it was either an early Harden Runtime or it was dylibs loaded via code (instead of being hard linked in the LC_commands)…
I can reproduce the same console messages with the latest Ventura and so I will investigate this, but it will probably have to be an option as I don’t want to release an update that may cause some apps to no longer work. I also didn’t make any notes in the code as to why or when I made this change
Further more, while this message is present in the console, it doesn’t appear to prevent the application from launching or cause it any perceivable problems.
I did however have a crash on some Macs with the NSAlert, I’m trying to recall what it was.
I have found one of the NSAlert crashes, this was the part of the stack trace, does it match your customer’s crash report? Customers Machine is 12.6. I was never able to reproduce the crash locally. And other tests on the customers machine worked fine, it was just this error dialog, which included a Xojo stack trace. It’s part of my error reporting functionality.
if I get this again, I’ll remove the use the Xojo message dialog and go direct to NSAlert, just to rule out any possibility of it being a bug in the Xojo framework.
Thanks, Sam! Looks like the user somehow managed to trigger a deadly Apple watchdog. He installed a newer version in a different directory and both stopped to work.
And the NSAlert issue is exactly the opposite: I do use a custom declare into NSAlert already …
Me, the idiot, did some testing for sending emails with an API. I wanted to use multiple emails. My test domain worked fine. But the iCloud email went into dev0 after a couple of tests. The email wasn’t even recognised as spam like Gmail does for legit emails. It just disappeared.
Thanks Greg, I was using the Xojo framework to show the modal.
Apple Mail can’t find the original mails, Spotlight can, but only shows me the customers e-mail and not the entire conversation. IIRC this issue doesn’t occur on Ventura and only happened when (in my case) when displaying the Xojo stack trace. Other mesgbox worked fine.
If it still occurred in Ventura then I’d probably replace the messagedialog calls with direct declares, bypassing Xojo, just to rule out it being a Xojo bug.