Someone saw this before?
Do you have the actual build you can run “file” on the dylibs on to be sure they are correct?
Doesn’t happen here.
So back to the client. Maybe it’s an older Xojo 2020r2 build.
I made case 62805
1 Like
I wonder if that happens if you run app on older macOS version?
No, its a today fresh downloaded and installed 2020R2 - had no beta versions on this computer, MBS Plugins version 20.5. System is macOS Mojave, with xCode 11.3.1 (latest version for Mojave) installed…
Problem still exists and is growning…
Building a Universal Binary under Xojo 2020r2 on Big Sur 11.0.1 on an MacBook Pro 16 with MBS Plugins 20.5 and xCode 12.2 results in an app that can only be opened under Big Sur and fails on older systems (tested on Mojave 10.14.6 and High Sierra 10.13.6).
Its a quite simple project, only one window with a label, a textinput area and a push button and the use of NSWindowMBS to make the titlebar transparent:
Testproject can be downloaded at: https://roemert.de/UB_Test.xojo_binary_project
Any ideas, hints, solutions?
Can you zip app and upload it, too?
@Greg_O_Lone may also want to check it.
No problem, its available at https://roemert.de/UB_Test.zip (not notarized, just as is build…)
Sorry, no idea currently. The plugin dylib there has arm and intel code and is adhoc signed.
Do you have an older machine with Mojave - to verify that the app can be opened?
I did try it on four different machines (MacPro late 2013 (xCode 11.3.1), two MacMinis (2011/2012 without xCode) and another MacBook Pro (2013) with Mojave and High Sierra) and everytime I get the error message… it is only opening on the machine it is build on, a MacBook Pro 2019 with Big Sur…
Have you tried signing it with App Wrapper and your developer ID certificate?
Yes, tried AppWrapper 4 Beta 3, everything works fine, it gets notarized, but app won’t start on none Big Sur systems…
If you like to see such an example (Xojo 2020r2, MBS Plugins 20.5, AppWrapper 4 b3 packaging) - I published a small app (a simple shell wrapper to remove quanrantine bit) yesterday evening (without proper testing on older systems): https://deltaworx.de/download/Ausbruch_UB.dmg
Looks a bit like the customer describes in this one here:
Yea same as in mine, and I bet you cannot either reproduce it in simple test.
I think something triggers incorrect copy or wrong book keeping when Xojo is compiling. We just need to get our hands on sample project that can reproduce it I think.
Could you check and see if they have their drives formatted with case-sensitive turned on?
It would also be helpful to know what the full path to their project and the name of their app is.
AFPS - case-sensitive is off, FileVault is off.
Path to project is “/Users/thomas/Desktop/UB_Tester/UB_Test.xojo_binary_project”, App Name is “UB_Test”. Project file and app are attached inprevious posts…
Any other information helpful?
Try finding the error in Console (which is not easy, given the amount of junk getting logged these days). You may see a more detailed message indicating whether it’s really not finding the right architecure, or it is finding the right architecture but there’s a code-signature problem.
That is my concern, I’ve seen similar things in the past when the code signing isn’t quite right and the nested items do not match the main app. Once I’ve had breakfast I’ll download Thomas’ app and take a look.
Which is one of the reasons I started the App Report project, especially given that Console will only show you data that it has recorded while it is open (or least thats how it worked for me since 10.12). I want to change the operation of the filters in App Report, so you can filter out certain libraries rather than focus on a specific one.