Jump to content

Failure to run a LabVIEW 2021 standalone app on macOS Monterey


Recommended Posts

I usually develop LabVIEW code on and for Windows (I used a MBP in the past, but exclusively developed within a Windows VM running on Parallel Desktop).

A colleague of mine wanted to run an old app I had released on macOS a few years ago (labVIEW 17 was in the error log), and he reported that the app did not run anymore.

I figured that since he was using macOS Monterey on an Intel MBP, there might be a chance that releasing the app using LV 2021 would work. Since my MBP runs macOS Catalina, I released it on that, sent him the executable and instructed him to download the 2021 RTE.

That still doesn't work. I can't even make sense of the mangled error message he sent me.

I know that Monterey is not even a term on NI's website, but I would assume that some have tried it already and maybe even released LabVIEW apps on it.

Any hint as to what could be a problem in my workflow would be helpful.


PS: the app is native G, there is no .NET, Active X or whatnot. I can actually upload the executable if someone wants to try it out on a Monterey Mac.

Link to comment

Sending my source code to my colleague, he was able to run it as a LV 2021 VI on macOS Monterey, which makes me hopeful that it can be released as a standalone app compatible for this platform, but I am not clear why doing so from a Catalina platform fails.

Link to comment

@mahgust BTW, my problem was not to run this standalone app on a M1 machine. The target was an Intel MBP running Monterey. Running it on M1 silicon would be even less likely to work. This being said, if you manage to get it to work, that would be a useful datapoint for me (NI is clueless and doesn't seem to be able to read my report correctly, so I gave up on them).

Link to comment
  • 2 years later...

If you have the Professional Version of macOS LabVIEW or have purchased the macOS Application Builder, 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. through at least the last release of LV for macOS: 2023 Q3.  The post-processing VI installs the respective runtime framework in Application.app/Support.  You need to be using the same version of LV and the runtime engine so that the copied files will compile and 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.

See https://forums.ni.com/t5/Example-Code/Standalone-LabVIEW-built-Mac-Application-with-Post-Build-Action/ta-p/3498155.

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.

Link to comment
On 2/10/2024 at 10:53 PM, ClinTrialist said:

If you have the Professional Version of macOS LabVIEW or have purchased the macOS Application Builder, 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. through at least the last release of LV for macOS: 2023 Q3. 

I am not sure I get it. What is that "post-processing VI" you are talking about?

Link to comment

Thanks for the question.

A Post-Processing VI may be used on LV 2012 or later in the Application Builder.  In this case, the Developer uses the Post-Processing VI to copy over the installed Run-Time Engine (or any other installed Framework) to the Application.app so that it can run without the need to install separately the same version of RTE (or any other installed Framework) on the client's i386, x86_64, or arm64 hardware.  Despite NI not providing an installer for the macOS LV, there is a pathway to create an application that "stands alone", i.e., that binary is self-sufficient.  Obviously, you can use Packages, Nix, RPM Package Manager, Jamf, etc. to create an installer.  However, it turns out that you can handle most of these issues inside LV itself.

As for Apple Silicon (arm64) native LV (2023 Q3), it is also possible to create a standalone application.  I finally got this to work early this morning and will post it on the the link above after doing some testing.  What this means is we can send zipped application files out to anyone who has macOS hardware and they will work as standalone apps.  Macophiles don't like installing "drivers" in the sense of heading over to https://www.ni.com/en/support/downloads/software-products/download.labview.html#443308 .

My concern is that NI is pulling LV for macOS in March after 40 years and that Apple may drop Rosetta 2 at some point in the future.  At least, LV "development" can continue on the macOS side on both x86_64 and arm64 for the foreseeable future for those who own permanent licenses.  NB: macOS LV development is limited by drivers, especially for the arm64 native LV (2023 Q3).  Native LV (2023 Q3) is fast on the newer M1 & M2 processors, but doesn't have drivers for NI hardware because of the challenges in developing for Apple's latest derivation of the Darwin kernel.  Many of us, hope the Emerson will see the benefit and open source LV.   Until then, the installed base will keep coding in G as is.

BTW, for a 2021 LV application and the 2021 RTE, it should run on Catalina.  As above, you could build a standalone app and test it on a Catalina VM....

Install Runtime Engine 2012 NIVerified.vi

Edited by ClinTrialist
  • Thanks 1
Link to comment
  • 2 weeks later...

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


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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.