LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Standalone Application for Apple Silicon (arm64) using native LV 2023 Q3

Solved!
Go to solution
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
0 Kudos
Message 1 of 3
(628 Views)

The Post-Processing VI that creates the

Application.app/Support/LabVIEW 23.3 Runtime.framework

for native LV 2023 Q3 on arm64

0 Kudos
Message 2 of 3
(621 Views)
Solution
Accepted by topic author wjdwyer

For Apple Silicon native LV 2023 Q3, you can embed the LabVIEW 23.0 Runtime.framework, etc., so as to create  a standalone application by drag and drop copying from /Library/Frameworks/LabVIEW 23.0 Runtime.framework, etc. directly to the Application.app/Contents/Resources folder.  This entails entering your admin or equivalent password to preserve security information that is lost if you cp, ditto, rsync, AppleScripts etc. over the frameworks using a Post-Processing vi.  A kludge, but it works to send standalone applications out with involving a client a trip to ni.com to download the RTE or to involve creating an installer.app to bundle installing an RTE.

 

For those who wish to stick with a Post-Processing vi for Apple Silicon native LV 2023 Q3:

-Rework the above Install Runtime Engine.vi substituting arm64 for x86_64 (or i386).

-Modify the paths created to place the frameworks at Application.app/Contents/Resources

-Use

sudo -S cp -Rp '/Library/Frameworks/%s/' '%s/%s'

to allow the copying to proceed completely in the Application.app without the need to involve drag and drop copying from /Library/Frameworks/LabVIEW 23.0 Runtime.framework, etc.

-Modify the sudoers list via sudo visudo, to include

<username> ALL=(ALL) NOPASSWD: /bin/cp

This effectively "whitelists" cp command at its path "/bin/cp" to have sudo privileges.

NB: Consider how to "sandbox" the time you allow even one command to have sudo privileges.

When finished building apps to test or deploy with this shortcut, REVERT to baseline security by deleting the entry in the sudoers list.

0 Kudos
Message 3 of 3
(487 Views)