Standalone LabVIEW-built Mac Application with Post-Build Action

[MarcPage]

Overview
This VI is intended to be used as a Post Build Action in a Build Application Specification on Mac. The VI installs the LabVIEW Run-Time Engine inside the built application so that it can be used as a completely standalone application and not depend on a separate installation of the LabVIEW Run-Time Engine.

Description
This VI will copy the corresponding version of the LabVIEW Run-Time Engine into the application you are building and then remove all but the core Run-Time engine components. If your application has dependency on other components of the Run-Time Engine (MathScript, HTTP VIs, Sound VIs, etc), you can modify which components are removed by removing the corresponding item from the Unnecessary Runtime Engine Parts control in the VI.

The action then compresses the .app (.zip) to make it ready for distribution and deletes the .aliases and Preferences files.

 
Requirements

• LabVIEW 2012 (or compatible)

Steps to Implement or Execute Code

1. Create a new Project
2. Create a Build Specification (make sure to set the top level VI)
3. In the Pre/Post Build Actions for the Build Specification, set this “Install Runtime Engine 2012 NIVerified.vi” as the "Execute VI after build"
4. Observe that the Run-Time Engine is installed directly in your application and a .zip file of your application is next to it
5. This application can be run on computers without first installing the LabVIEW Run-Time Engine

Additional Information or References
VI Block Diagram

 

 **This document has been updated to meet the current required format for the NI Code Exchange.**

[WNM]

Considering that this example was supposed to be about "an example VI that Installs the LabVIEW Runtime Engine into your built apps. LabVIEW has added pre/post action VIs that you can add to your Build Application Specification. This can be very useful for automating prep-work or post-build tweaks." And that post-action VI does not exist in the zipped file set and the project file that is included makes no mention of application building, I'd say that this example is now pretty-much worthless.  I'm wondering if "Example_Scrubber_Zi" got carried away with his treatment of this example.

http://themacview.blogspot.com/2013/02/build-standalone-mac-app-in-labview-no.html explains what this was supposed to be about.

[dadreamer]

Some evil things have happened to this article, but I restored Revision 5 snapshot (by Fred_V) from the History and now it all seems to be fine. Also I have tested this VI on the recent LabVIEW 2019. Everything is still working. When the build has finished, I got my test app with "LabVIEW 19.0 Runtime.framework" integrated into it (about 50 MB in size) and its zipped variant (about 20 MB). Then I loaded a VM without both LabVIEW and RTE installed and ran that app there. No errors or anything, so I assume we can freely use this method for simple apps. It may not work for some bigger projects though, as the frameworks list is hardcoded into the VI and has to be altered, if the app requires any additional libraries. Moreover I'm kind of unsure, if we really need to strip all those non 32-bit stuff and diagnostic info, but I leave it for those, who had more experience with macOS than I.

[wjdwyer]

If you have the Professional Version of macOS LabVIEW or have purchased the macOS Application Builder from 2014 through at least the last release of LV for macOS: 2023 Q3, you can build standalone applications using a post-processing VI that will run on any x86_64 (Intel) or arm64 (Apple Silicon) MacBook Pro, etc.  The post-processing VI installs the respective runtime framework in Application.app/Support.  As above, you need to be using the same version of LV and the runtime engine so that the copied files will compile and then run on the client's Intel or arm64 (through Rosetta 2) Mac hardware.   Thus as long as Rosetta is installable on future macOS releases, there should be a pathway to develop for releases to clients in this manner without them needing to download the Runtime Engine (RTE) separately.

The RTE setup for Apple Silicon native LV 2023 Q3 entangled the user with other challenges: codesigning, etc. that make solving this problem difficult when trying to stay strictly native, i.e, LV compiled for arm64 without the need for Rosetta 2.

If you get an error code 6, delete your Project and rebuild it from scratch to link the post-processing VI.

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