AppWrapper can't find XojoFramework for ARM 64

I have installed AppWrapper 4.4 on Monterey 12.3 beta with Xojo 2021 R3.1. I had been using v4.3 OK about a month ago.

I can run and build my Universal app, but as soon as I add the AppWrapper Script and run, I get the error:

The error is:
/usr/bin/codesign -vvvv -f -s 226E4761426758C7A1A6C362845ADEB7BA71BA72 -o runtime --entitlements /Users/davidcox/Library/Caches/com.ohanaware.appWrapper/com.holymackerelsoftware.bambambilling/inherited.entitlements
!AWEO {“code”:1,“message”:“Failed, options:193”,“type”:“troubleshooting/issuesCodeSigning.html”}
!AWEO {“code”:1,“message”:“BamBam (for architecture arm64): No such file or directory”,“type”:“troubleshooting/issuesCodeSigning.html”}

Not sure what the issues are with CodeSigning or why the XojoFramework (for architecture arm64) would be missing.

So I did a ‘Check’ in AppWrapper and all sections passed, but AppWrapper gave a whole list of 'Unable to read “”… ’ errors. Any clue how to get rid of these errors as the Help just says what they are, not how to fix them?

My guess is that somethings changed in 12.3 with the system function that gives me a fast directory listing, or AW is unable to actually access those files, due to some security setting somewhere.

Please try the following.

  1. Disable the AW script in your Xojo project.
  2. Open the AW file within App Wrapper.
  3. Build your application within Xojo.
  4. Drag the compiled application into the AW window.
  5. Select “Wrap” from the “Process” menu on the toolbar within App Wrapper.

If that works, then try re-enabling the script and building again.

If that fails, then please use the “Contact Ohanaware” option on the Help menu and choose to include the log files so I can take a look at the processing log. I may need to build you special version of App Wrapper where I can also see the results of the fast directory iteration :frowning:

I guess it’s good that I’ve been experimenting and think I have a much faster directory iteration engine that I own, looks like I might have to escalate it’s priority and finish it sooner than I originally planned.

I did the steps as mentioned above. It suggests the issue may be in resetting permissions:

But clicking the Help… button suggests the issue might be within ‘en.lproj’:

I have emailed @Sam_Rowlands the error report.

Is that the only help page that doesn’t work? If none of the help works, with the existing error messages, it sounds like it’s been locked out of the file system. Not even able to access it’s own files.

Which is weird.

I’m not at home in the office today, but this bothers me massively.

FWW Appwrapper 4.3.2 works fine on macOS 12.3 beta

I am running Appwrapper 4.3.2 works fine on macOS 12.3 beta! Please see below and try it:

New Development — I had been building with AppWrapper for Universal to receive the errors above. When I built for X86, all the issues went away.

So I took a test app and changed it to be Universal and tested it with AppWrapper, and the problems returned.

As a further test, I set the test app to build for ARM only, and the errors did not show up.

In conclusion, the Executable Files errors only happen in a Universal Build, not x86-only nor ARM-only, and it affects multiple applications.

Universal apps works fine here too (with 4.3.2) - no errors.
I do not have 4.4 yet.

It was happening for me with v4.3.2 and I was about to post when I saw that v4.4 was released. So I downloaded v4.4 in case that fixed the issue — it didn’t, so I posted.

AppWrapper 4.3.2 and 4.4 work fine under macOS 12.2 when building UniversalBinary.apps.

Looks like macOS 12.3 beta is the culprit. Maybe Apple changed something or the beta simply contains bugs…

I’ve spent the best part of the morning investigating this, I’ve come to the conclusion that Apple have changed how they report the number of architectures in a Mach-O file.

I’ve added some code to help me test this theory and what I hope will be a workaround. Imma little nervous to update to any 12.x beta on my development machine. Maybe I’ll blast my Big Sur partition and install it there.

If anyone else is experiencing this issue and an official release (from me) isn’t yet available, please feel free to try the current prerelease.

Last year I prototyped a new engine to replace BlackBird, it’s not fully fleshed out, but looks like I might have to re-prioritize it as it appears I can add another Apple API to the list of “Can’t trust while Tim Cook runs Apple”.