Could not open plugin Runtime Error

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:

For MBS those are named all the same:

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.

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: YES

Thanks, 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:

  • rebooted
  • tried a different user
  • tried a different computer
  • tried with a VM

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).

1 Like

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…