Cross-platform alternative to LabVIEW

[lucian.grec]

Given that macOS support ended with LabVIEW 2023 I am looking for alternatives that I could use to build complex cross-platform GUI applications on Mac and Windows.

We've been selling a feature-rich software in the audio industry, think something like TestStand and LabVIEW combined, and that has been developed and sold over the course of two decades, all thanks to this language that we all love, but we will lose the Mac business as soon as we won't be able to build G code on macOS.

The codebase is large and complex and moving to a potentially different language, framework will take years of work for my team so we might not even afford to do it, in which case we'd just have to settle for losing the Mac side of the business.

We're a team of developers that mainly develop in G and to some degree in Python and C++ so we'd need to train ourselves and hire new talent as well.
I was also wondering if there was a way and if it was advisable to gradually transition the codebase to a new technology and ship a product that's both G and this new stack for a while to soften a bit the blow.

Features we'd need are:
1. Interactive graphs since we do a lot of plotting both online and offline.

2. A consistent look and UI API across platforms.
3. We'd like to maintain only one project if possible.
4. Support for multiple windows like we have in G

5. All the UI elements that G has and more: Trees, MCLB, Buttons, Textboxes etc...

[Andrey_Dmitriev]

I will vote for C# with Avalonia UI.In the past I've used C#/WPF and really love Avalonia, because its quite similar to WPF, but also better in some areas, under active development, and corssplatform, I've used this for Linux as well as fro some experiments with Android, it works.

If you're stick on C++, then Qt probably is your choice, but I would like to recommend to give a try with C#. From GUI point of view you can do much more than in LabVIEW.

[Yamaeda]

You can stay on LV2023 for quite some time. I manage systems running LV2010 (and several others ofcourse). Heck, not too long ago i had to fix some issues in a LV6.1 system ...

[lucian.grec]

I'm already seeing bugs on M3 Sonoma(the FP of various VIs goes haywire but it comes back if I reopen it) so I'm worried that with the advance of the macOS ecosystem LV and LV built apps will become more and more incompatible. 

[rolfk]

---

@Yamaeda wrote:

You can stay on LV2023 for quite some time. I manage systems running LV2010 (and several others ofcourse). Heck, not too long ago i had to fix some issues in a LV6.1 system 

---

Definitely a valid solution. I maintain systems in LabVIEW 2009, 2013, 2018 and 2020 and they will never get updated to a newer version because it is just to much effort and hassle. The occasional changes they require do not warrant the effort to upgrade to a completely new LabVIEW version.

I also have some in even 7.1.1 that generally don't require active maintenance but I did recently a check that it can get installed and run in Windows 11. Especially if you don't really use NI hardware but just LabVIEW itself, things are usually very OS independent despite much more strict compatibility tables from NI. That is definitely true on Windows, I did at some point install LabVIEW 5.1 just for the heck of it on Windows 11 to see if that still works, and while the look is awful by modern standards, it did actually work.

On Linux things are usually a little trickier, but with a bit of googling you can get LabVIEW 8.6 and earlier working even on the latest Fedora. Macintosh unfortunately is even more tricky in terms of OS compatibility. That is partly because Apple is very unrelenting about upping the ante in security measures, not shying away from requiring application developers to basically release a new application version for every new OS version to be able to even start up. Sometimes they also simply make changes, because they can!

@lucian.grec wrote:

I'm already seeing bugs on M3 Sonoma(the FP of various VIs goes haywire but it comes back if I reopen it) so I'm worried that with the advance of the macOS ecosystem LV and LV built apps will become more and more incompatible. 

That is usually related to optimizations in the graphic driver that expects applications to follow a new specific flow of operations. There are usually compatibility settings you can add to the app settings on MacOS that work around such issues but it is of course not something you want to have your users do on their own. If you really care about that and are into low level stuff, you can usually find those necessary settings and could add them to your application installer to squeeze out a few more years. It gets of course a hassle over time, but that is what NI has to do with every new version of any OS to keep their software running. The fact that Apple is quite eager to change lots of things with every new version and the size of the Mac developer group within NI, which is related to the amount of sales they got out of LabVIEW for Mac, certainly was a significant factor in the decision to stop releasing a Mac version of LabVIEW.

[wiebe@CARYA]

You could gamble that virtualization (emulation, containers, VMs, etc.) will mature in the next years (5? 10?) and that would make the hole problem go away. In the meantime, you can keep using older versions.

I know MS, Linux, docker, VMWare all make steps towards better virtualization, but IMHO it's not quite there yet.

[lucian.grec]

I don't think it's a valid solution at all. It's like saying that we could've stayed on LV 7 had NI stopped support for macOS then. And sure we could've but at what cost...

From a business point of view both from ours and our customers we can't seriously consider sticking to LV long term(say 5-10 years from now) for developing the macOS version of this software. Sooner or later the consequences and costs of a decision like this will catch up with us. Either customers get wind of this and start looking for alternatives, or competitors do it or we simply become obsolete.

It's not only about maintaining our codebase. We've got a yearly release cadence that we need to pack with new features and some innovation in order to sell licenses and maintain a steady source of revenue.

[wiebe@CARYA]

We're trying to be constructive.

The reality is: no, there are no alternatives.

[Yamaeda]

---

@lucian.grec wrote:

I don't think it's a valid solution at all. It's like saying that we could've stayed on LV 7 had NI stopped support for macOS then. And sure we could've but at what cost...

From a business point of view both from ours and our customers we can't seriously consider sticking to LV long term(say 5-10 years from now) for developing the macOS version of this software. Sooner or later the consequences and costs of a decision like this will catch up with us. Either customers get wind of this and start looking for alternatives, or competitors do it or we simply become obsolete.

It's not only about maintaining our codebase. We've got a yearly release cadence that we need to pack with new features and some innovation in order to sell licenses and maintain a steady source of revenue.

---

LV interfaces can look a bit aged, but it's also very expensive to change platform.

Assuming you have a rather big and solid library of code it's a lot of work to remake it in whatever language you end up with, C#/Java/Python. A happy medium would be to make the current functionality into DLLs and add a new UI on top. Then you can slowly transfer functionality to the other language, maybe implement the added functionality in your new language.

What features in the newest LV are you dependant on in your code? If the answer is none to very few you can stick around on your current version.

[lucian.grec]

I think we're forced to deal with this cost one way or another.
The most recent feature was support for Apple silicon and thankfully that bridge was crossed by NI. Who's to say that in 5 years there won't be another breaking change like this that?

The plan is to stick around on LV2023 but we need to plan ahead.

DLLs/frameworks could be an option but our code is pretty tightly coupled so we need some upfront investment there. We'd also need to separate the UI from the logic of the application.
Anyway these are specifics and don't really matter to the general question I had.
C# - not so much macOS afaik. Visual Studio is being retired for macOS so it doesn't look like a very promising alternative
Java - seems to be a better fit but what GUI library would you standardize on
Python - irrelevant for most of the application. we do have support for calling python script to extend the functionality of our application so we'd need python bindings in this new language.