On x86_64, following on Marc Page's work, I’ve created a post processing vi that works through macOS LV 2023 Q3. It's taken some time to get to this point because the versioning now uses the decimal point again, e.g., 22.3 depends on a 22.0 RTE framework, 23.3 depends on a 23.3 RTE framework.
This allows the application builder to create a support folder with the matching RTE, meaning the application can run without installing the RTE.
These “x86_64 RTE” standalone applications run on Apple Silicon (arm64) through Rosetta.
The RTE framework sits in a “Support” folder inside of the Application.app—next to Contents.
It works.
It does not need to be codesigned, even when run of Apple Silicon (arm64).
When I try to do the same process on Apple Silicon (arm64) using the native Apple Silicon 2023 Q3 LV,
either the required codesigning breaks the application because you are not allowed to have a folder other than Contents and symbolic links at the Application.app folder level,
or the codesigning will work but the “arm64 RTE” standalone application will not run because it cannot locate the RTE framework if you place the support folder elsewhere (e.g., in the Contents folder).
Trying the allowed symbolic link from the Application.app folder level to the Contents folder level does not work in arm64 or x86_64.
Request: is there a workaround other than trying to go through the Apple Developer Program and obtaining a formal certificate to try to force this?
I’ve tried many versions of codesigning components and the build, e.g., using
codesign --force --deep -s - <path to app>
or
codesign -s - <path to app>
as you suggested in
do not work when the application has "unsealed contents present in the bundle root" (i.e., the Support folder)
as well as taking it out of quarantine (when opening the application causes "damaged" window) to pop-up by using:
xattr -l /path/to/application.app
to check the provenance list, and
xattr -dr com.apple.quarantine /path/to/application.app
to clear it.
Developers have asked for a post-processing VI that would make arm64 LV create a standalone application, because this would really open up the client space for developers, e.g., developers could send completed standalone applications to customers without involving them in the RTE installation process.
A solution would be to update the LV 2023 Q3 Application.app to include Application.app —> Support (or Application.app —> Contents —> Support) to it's search path for the RTE framework instead of limiting it to ~/Library/Frameworks/LabVIEW 23.0 (or 23.3) Runtime.framework
