In my case it was an helper app that needed to launch the main app on boot. The ARM helper app tried to launch the Intel version which caused the problem. So it is another issue that Thomas experienced.
@Thomas : it maybe that some files on your system are in quarantine (even image files can trigger issues). So best is to make sure it isn’t.
xattr -r -d com.apple.quarantine
Both Thomas’s and my own app don’t have helpers.
IMHO it appears to be something related to older processors, they just crash for me and @kevin_g on 2012 hardware running macOS 10.14 or lower, while they work on @Beatrix_Willius 2017 iMac. They also work on a 2020 16" MBP running 10.15 or 10.16.
I have tried all kinds of code signing (the extended attributes get stripped by App Wrapper during a sign), and I still cannot get these apps to run on my 2012, because I am worried that it is a code signing issue that App Wrapper isn’t handling.
To test this today, I deliberately borked a code sign on a test application. I do not get error dialog saying “no suitable image found”, however it does crash and the error message in the crash report is “no suitable image found”, but it is titled as a CODESIGN crash and not a SIGABRT crash.
Does also happens when no plugins are used?
Just so everyone knows, we are able to reproduce this now, but only on machines which were manufactured before 2012.
I can reproduce it on an Apple Silicon Mac running app in Rosetta.
Ah, its good to hear you can reproduce it…
Problem also exists on my MacPro late 2013 and MacBook Pro early 2013, both running Mojave…
Does this mean it is not advised to release a universal binary now?
EDIT:
Well, let me answer my question myself.
No, it is not advised.
This morning I submitted an update to AppStore. 5 minutes ago I received a rejection because … my app crashes on launch. 
Oh boy … I am now going to compile an Intel only and submit it again.
BTW I have asked more details (crash report etc…).
We uploaded newer dmg/zip with a little change to fix Universal builds for 2020r1.
Please try.
Looks good, UB apps can be build and opened on my MacPro late 2013. Hope other people can confirm that, too.
Maybe you can give the other plugin developers like @Björn_Eiríksson a hint, what has to be changed to get things to work on older machines until Xojo fixes the bug…
[Update]As I currently have no M1 Mac to test it I can’t say if there are any problem on the arm side, but AppWrapper 4 beta 4 shows some problems while checking a UB app made with the new MBS plugins…
Björn is probably already is subscribed to the feedback cases related to this.
Am a little bit confused, according to the case and what William said then the temp solution is just to not have the x64 and the arm64 have same name ?
Case does seem marked fixed though so I imagine we are getting hot fix patch soon.
Yes. I just renamed my arm dylibs, so Xojo doesn’t merge them to an universal one.
Not sure about what the fix is beside renaming them.
For the time being, simply ignore the messages about not finding the architectures as the plugins are split into two separate files. Which is not something that App Wrapper is aware of, it’s expecting UB.
In regards to the minimum OS version, I’ve made some adjustments for the moment as I am still awaiting Apple to tell me what the correct identifier for the LSMinimumSystemVersionByArchitecture is. My guess is as several Apple people have told me my best bet is to post on the forums (which has gone unanswered) that Apple themselves do not know.
Thats what I did, app gets sucessfully notarized, codesigning is working (typical Apple warning dialog about downloaded from… is shown) and app starts on my MacPro late 2013 and MacBook Pro 2019. Can’t test it with a new M1 Mac, but if someone will try, the UB app is available at https://deltaworx.de/download/Ausbruch.dmg
Is this a temporary solution (naming the intel and arm different)?
No idea. Even if it’s fixed in 2020r2, we may keep it for some time to support 2020r1.
To me it would depend a bit on when we can expect 2020r2.1 if its like almost there or if its weeks. Since time for me is better spent at adding more Apple Silicon and iOS support than taking u-uturn to rebuild and re-publish.
Sorry, I meant 2020r2 for the compatibility and a potential fix in 2020r2.1 or 2021r1.
I think if we were to get like 2020r2.1 then no-one will care about 2020r2. People usually use the ho-tfix versions since those usually do not brake anything else for them.
