For decades, industrial software followed a simple pattern.
If your application ran on Windows, you probably built it with C#, WinForms or WPF. If it ran on Embedded Linux, you probably built it with C++ and Qt.
The operating systems were different. The languages were different. The developer communities were different. Most importantly, the migration path between them was painful.
Today, that distinction is disappearing.
Modern .NET runs natively on Linux and ARM. Cross-platform UI frameworks exist. Embedded Linux has become the dominant operating system for new industrial devices. For the first time, organisations can build industrial and embedded applications using the same language, tooling and architectural patterns across both Windows and Linux.
That shift is changing how industrial software is built.
Why industrial UIs are moving to embedded Linux
The pattern across machine builders, medical devices, energy systems and factory automation is remarkably consistent. The box next to the machine used to run Windows. Increasingly, it runs Linux on ARM.
The reasons are practical rather than ideological.
Hardware economics have changed dramatically. Modern ARM-based system-on-modules provide more than enough performance for sophisticated graphical applications while consuming less power and costing less than traditional industrial PCs.
Control is another major factor. An embedded Linux image belongs to the manufacturer. Every package, every service and every update policy is under their control. There are no operating system licence fees, no mandatory updates and no unexpected platform changes arriving halfway through a product lifecycle.
Perhaps most importantly, Linux aligns better with industrial timescales. Industrial devices frequently remain in service for ten, fifteen or even twenty years. A Yocto-based Linux image can be archived, reproduced and maintained for as long as necessary. Most consumer operating systems are not designed with that level of stability in mind.
This trend has been building for years.
For much of the 2000s, embedded development followed two parallel tracks. Windows-based HMIs were commonly built using WinForms, WPF and C#. Linux-based systems were typically built using C++ and Qt. As Linux steadily became the preferred operating system for new embedded designs, organisations with significant .NET investments faced an uncomfortable choice: rewrite everything in C++, or remain tied to Windows.
Modern .NET largely removes that trade-off.
The missing piece: .NET becomes genuinely cross-platform
A decade ago, suggesting C# for embedded Linux would have been a difficult argument to make.
Not because the language was incapable, but because the ecosystem wasn't there.
That changed as .NET evolved from a Windows-centric framework into a genuinely cross-platform runtime capable of running natively on Linux, macOS and ARM. Suddenly the same language used for engineering tools, SCADA integrations, configuration software and business systems could also run on the embedded device itself.
At the same time, performance concerns that once dominated these discussions became far less relevant.
Twenty years ago, choosing a managed language often meant accepting a substantial performance penalty. Today, highly optimised .NET code frequently performs within a few percentage points of equivalent C++ implementations for many workloads. Recent benchmark results place SIMD-optimised C# implementations alongside highly tuned C++ code, with differences measured in single-digit percentages rather than multiples.
More importantly, industrial applications are rarely constrained by language runtime performance. User interaction, networking, graphics rendering, database access and external hardware communication are far more likely to determine system responsiveness than whether the application was written in C# or C++.
As a result, many organisations have concluded that the productivity benefits of modern .NET outweigh the additional complexity traditionally associated with C++ development.
What .NET on embedded Linux looks like today
Modern .NET runs natively on Linux and ARM, and Avalonia provides a UI framework capable of targeting embedded devices without requiring a desktop environment.
For embedded Linux applications, that matters in a very specific way.
Avalonia can render directly to the framebuffer or through DRM/KMS, allowing applications to boot directly onto the display without requiring X11, a desktop environment or a window manager.
The same codebase can drive:
- An embedded touch HMI running on ARM Linux.
- A desktop engineering application running on Windows.
- A configuration tool running on macOS.
- A monitoring dashboard running in the browser via WebAssembly.
- A technician application running on iOS or Android.
Historically, that combination would often require multiple frameworks, multiple codebases and multiple specialist teams.
The ability to consolidate those applications around a single language and UI stack is one of the most significant productivity shifts industrial software teams have experienced in recent years.
Why some organisations are moving away from Qt
Qt remains the dominant commercial framework in embedded Linux and has earned that position over decades of investment.
However, organisations evaluating modern alternatives tend to raise three recurring themes.
The first is cost.
For organisations shipping large product portfolios, UI toolkit licensing can become a meaningful operational expense. One medical device manufacturer that adopted Avalonia previously maintained an annual Qt commitment measured in millions of euros.
Qt's commercial licensing model has evolved over time, but many organisations continue to express concern about recurring subscription costs, particularly when products may remain in active development and maintenance for decades.
Avalonia takes a different approach. The framework itself is MIT licensed and can be used in commercial proprietary applications without royalties or per-device fees.
The second factor is development velocity.
Most industrial software teams already employ C# developers. Their engineering tools, configuration software, test systems and internal applications are frequently written in .NET.
Being able to use the same language and tooling throughout the stack simplifies recruitment, training and long-term maintenance.
Modern .NET's build cycle is typically faster than large C++ codebases, while automatic memory management and higher-level language constructs reduce the likelihood of entire categories of defects.
The result is often faster iteration and shorter development cycles.
The third factor is strategic alignment.
Qt has been highly successful within the automotive sector and has invested heavily there. Some organisations outside automotive increasingly feel that their priorities do not align as closely with the company's direction as they once did.
Whether that perception is fair or not is ultimately secondary. It is a concern we hear regularly from organisations evaluating alternatives.
The constraints that make embedded different
Embedded UI development remains fundamentally different from desktop software.
You own the entire software image. Fonts, input devices, GPU drivers, startup behaviour and system integration all become part of your responsibility.
Hardware validation matters more than it does on the desktop. Embedded GPUs vary considerably, and testing on target hardware should happen early rather than becoming a late-stage activity.
Long-term reproducibility also becomes critical. A device shipped today may require maintenance a decade from now. Toolchains, dependencies and build environments must be preserved accordingly.
Input methods introduce additional complexity. Factory operators may wear gloves. Medical environments may impose strict usability requirements. Touchscreens may be resistive rather than capacitive. User interfaces that work perfectly on a desktop monitor can fail completely in production environments.
These constraints are not unique to any framework. They are simply part of embedded engineering.
Air-gapped environments: the requirement nobody talks about
One requirement appears repeatedly in industrial projects and rarely receives attention in marketing material.
Many industrial environments cannot access the internet.
Defence systems, energy infrastructure, pharmaceutical manufacturing and numerous factory deployments operate on isolated networks as a matter of policy. Any tooling that assumes internet connectivity for activation, licensing or operation may be disqualified before technical evaluation even begins.
This is often a more significant deployment blocker than rendering performance or hardware compatibility.
If air-gapped environments are part of your deployment model, it is worth verifying those requirements with every vendor in your technology stack as early as possible.
The WPF estate problem
The most common migration scenario we encounter starts with an existing WPF application.
An organisation may have spent years building HMIs, engineering tools and operational software on Microsoft's stack. The next generation of hardware runs Embedded Linux on ARM. The software does not.
A complete rewrite is rarely attractive.
Industrial software often contains years of accumulated domain knowledge, edge-case handling, validation work and certification effort. Recreating that investment from scratch is expensive and risky.
This is precisely the problem Avalonia XPF was designed to address.
XPF provides a WPF compatibility layer that allows existing WPF applications and many third-party control suites to run on Linux, including Embedded Linux on ARM.
Rather than rewriting the application, organisations can evaluate how much of their existing codebase can be carried forward unchanged and focus engineering effort only where adaptation is genuinely required.
For organisations with substantial WPF investments, that can significantly alter the economics of Linux migration.
A sensible evaluation plan
If you're evaluating .NET for an embedded Linux project, the process is straightforward.
Start by proving rendering on your actual target hardware. Real boards expose real problems far more quickly than development machines.
Next, integrate the application into your Yocto or Buildroot pipeline and verify that the entire system can be reproduced from a clean checkout.
If WPF is involved, test the real application rather than a sample. The resulting compatibility report usually becomes both the migration plan and the business case.
Finally, validate operational requirements such as offline activation, source access and long-term support before procurement begins.
These details often determine project success more reliably than benchmark results.
The bigger shift
The most important trend here is not Avalonia, .NET or any individual framework.
It's that the historical boundary between Windows development and embedded Linux development is disappearing.
For years, organisations were forced to choose between the productivity of .NET and the flexibility of Linux.
Today they can increasingly have both.
That's a significant change for industrial software teams, and one whose effects are only just beginning to become visible.