Right okay, first thing I spot is that the code signature contains a blank dictionary. This is App Wrapper 4 adding entitlements, but there are none set. So I’ll get onto that ASAP.
Edit: In the mean time, if you unselect “Uses Entitlements” in the sidebar under the Code signing heading, this will also stop it.
I’m now booted into macOS BS and this app runs on my machine. Earlier I tried it on macOS 10.15 and it worked also.
This on a 2020 16" i9 2.3 Ghz MBP.
Console message is not very helpfull, but in ReportCrash its talking about a unknown siganture3 (whatever this may be):
OS is macOS 10.14.6 “Mojave”:
Console
Nov 29 09:38:57 nMacPro com.apple.xpc.launchd[1] (com.deltaworx.ubtest.324516[53418]): Service exited due to SIGABRT
ReportCrash
com.apple.message.domain: com.apple.coreservices.applaunch
com.apple.message.__source__: SPI
com.apple.message.path_bucket: 2
com.apple.message.volume_is_network: no
com.apple.message.quarantined: no
com.apple.message.volume_is_removable: no
com.apple.message.volume_is_ejectable: no
com.apple.message.volume_is_root: yes
com.apple.message.volume_is_disk_image: no
com.apple.message.bundle_identifier: com.deltaworx.ubtest
com.apple.message.bundle_version: 1.0.0.0.4
com.apple.message.bundle_short_version: 1.0.0
com.apple.message.domain: com.apple.crashreporter.writereport.crash
com.apple.message.signature: UB_Test
com.apple.message.signature2: com.deltaworx.ubtest ||| 1.0.0 (1.0.0.0.4)
com.apple.message.signature3: UNKNOWN
com.apple.message.result: NO
com.apple.message.summarize: YESThanks, Catalina is the only OS I can’t test on my own - nice to know it is working.
But if I didn’t miss anything, a Universal Binary should also work on older OS (for them, the Intel part should be the only one visible/useable), right?
AFAIK it should. But it wouldn’t surprise me if they changed something about the code signing. I can also test on High Sierra (tomorrow) and maybe it’ll crash there and I can gleam something useful.
App starts fine on High Sierra.
Have you done the usual tests:
The MAS version of my app doesn’t start in debug mode when sandboxed. Not-sandboxed everything starts fine. But when sandboxing I need to do a build of my app.
I noticed when I was “wrapping” up Iconographer Mini for the App Store, the receipt wasn’t being written until the application was in the /Applications folder.
Didn’t used to be like that (I’ve spent a lot of time debugging App Store apps over the years).
Tested it with four diferent machines (MacPro late 2013 - macOS 10.14.6, MacMini 2011 - macOS 10.13.6, MacMini 2012 - macOS 10.14.6, MacBook Pro early 2013 - macOS 10.14.6), rebooted, different user - always the same error message “Location: Common/plugin.cpp: 1048 …”
The only VM I currently have is with Mountain Lion 10.6.8, for converting old .fp5 filemaker databases.
The UB_Test.app is not code-signed nor sandboxed - just the result of a build on Big Sur with Xojo 2020r2 using MBS Plugins 20.5 (or the current ones from Einhugur - e.g. SearchControl).
A codesigned, wrapped and notarized app to test with: https://deltaworx.de/download/Ausbruch_UB.dmg
MAS is the reason for me to do this UB testing - i would like to offer my customers a universal binary. In direct sale I can offer seperate downloads for x86_64 and arm64, but MAS builds needs Universal…
This behaviour changed in the last weeks, must have been within one of the last security updates…
What exactly did you test? Did you try to build the app or did you open the built app? Which works fine for me on High Sierra. What I wanted to see as test result was to try to do a build on a different user/computer.
I mentioned my sandbox problem just as example that there are sometimes odd problems.
Building works fine - build app can be opened on the building machine itself, but not on one of my other test machines…
Currently i have only one machine with Big Sur which is able to build UB - as XCode 12.2 is neccessary.
If I only use xojos own plugins (e.g. build the mysql example as UB), the build app can be opened on all test machines. But if i start using an mbs (or einhugur) plugin, the error occurs on older macOS machines…
This is not true. You need Mojave and not BS to build UB. Thanks the Gods.
Sorry, my mistake. But the result of a build with Mojave is the same, trying to open the build app results in the runtime error…
Can you describe in excessive detail what you are doing? How do you sign the app?
As I’ve mentioned before, the app is simply build and directly after succesfully finishing the build process its started - no (additional) codesigning, no wrapping, nothing > Runtime Error
The result is the same if I use AW4 b3 with codesigning for Web Deployment, packaging as zip or dmg and notarization > Runtime Error
You must be doing something different than we do.
Maybe, but what? Everything works fine and as expected when I use none or only the plugins shipped with Xojo 2020R2 (e.g. MySQLCommunityPlugin). Such an app can be opened on all of my test machines - ranging from 10.11 up to 10.14
When I start to use one of the latest MBS (or Einhugur plugins) - all cleared for UB - I’m only able to start the build app on my Big Sur Machine. On four other machines with older macOS the app crashes with the Runtime Error. So, what am I doing wrong?
So my 10.13.6 machine (2012 rMBP) refuses to launch either of your apps, producing the same error.
These are the messages from the XojoFramework that get logged to the console. The same for both.
08:57:37.812 Df Ausbruch[504:1bfa] (XojoFramework) dlopen(/Volumes/Ausbruch/Ausbruch.app/Contents/Frameworks/MBS_MacBase_NSAttributedString_Plugin_20393.dylib, 5): no suitable image found. Did find: /Volumes/Ausbruch/Ausbruch.app/Contents/Frameworks/MBS_MacBase_NSAttributedString_Plugin_20393.dylib: no matching architecture in universal wrapper /Volumes/Ausbruch/Ausbruch.app/Contents/Frameworks/MBS_MacBase_NSAttributedString_Plugin_20393.dylib: no matching architecture in universal wrapper 08:57:37.812 Df Ausbruch[504:1bfa] (XojoFramework) Runtime Error Please report what caused this error along with the information below. Common/plugin.cpp: 1048 Failure Condition: false Could not open plugin MBS_MacBase_NSAttributedString_Plugin_20393.dylib (dlopen(/Volumes/Ausbruch/Ausbruch.app/Contents/Frameworks/MBS_MacBase_NSAttributedString_Plugin_20393.dylib, 5): no suitable image found. Did find: /Volumes/Ausbruch/Ausbruch.app/Contents/Frameworks/MBS_MacBase_NSAttributedString_Plugin_20393.dylib: no matching architecture in universal wrapper /Volumes/Ausbruch/Ausbruch.app/Contents/Frameworks/MBS_MacBase_NSAttributedString_Plugin_20393.dylib: no matching architecture in universal wrapper)
I’ve checked the MBS_MacBase_NSAttributedString_Plugin_20393.dylib and both slices are signed with Thomas’ Developer ID certificate. The architecture order is the same as the main executable, and the UB byte order is the same.
I’ve seen this message myself in the last year, when I set up a test to capture code sign failure codes. I’d marked my app to not sign the XojoFramework (so it had the default Xojo code signature). Code sign didn’t report a failure under Catalina (it does in other OS versions), but the app wasn’t allowed to open the XojoFramework either. Image not found.
So I downloaded BBEdit 13 as that is UB. The first thing I noticed is that it requires macOS 10.14.2. It’s a very specific OS version IMHO. I’ll reboot into 10.14 and test again.
Mac OS 10.14.6. The same errors for both the signed and unsigned apps.
BBEdit 13 works.
The BBEdit frameworks use the same byte order, same architecture order and both slices are signed. So I don’t think that is the problem.
At this point, I’ve exhausted all I can think. I think I’ll hold off shipping the UB version of AW4 until we get a better idea.