A modern embedded workflow is not one decision. It is a stack of them, made one at a time, usually in this order: pick a build system that is not tied to a vendor's project format. Get CI running on something reproducible. Make sure debugging still holds up once the code leaves a developer's desk. Each decision is defensible on its own. Put them together, though, and most teams find one piece still does not fit: the certified toolchain itself, compiler and debugger, has stayed locked to whichever OS it was originally validated on.
That is the piece this piece is about. Not because it is the most exciting layer of the stack, but because it is usually the last one to move, and until it moves, the rest of the workflow is only half-modernized.
Layer one: A build system that survives contact with CI
CMake did the first job. It replaced project-file lock-in with a build definition that lives in version control, next to the code it builds, instead of buried inside a tool-specific format only one IDE can open. Once the build is portable, it stops mattering whether it runs from a terminal, inside an editor, or inside a CI runner. Same configuration, same output, every time.
Most embedded teams have already made this move, or are far along in making it. It is the least controversial layer of the stack, because the payoff is immediate and the tradeoff is close to zero.
Layer two: CI that does not drift
Containers did the second job. Package the compiler, the build tools, the static analysis tools, once, and every developer machine and every build server pulls the same image. No "works on my machine." No slow accumulation of slightly different compiler versions across a team. In a safety-critical or compliance-driven project, this is not a convenience, it is the difference between a build you can defend under audit and one you cannot reproduce five years after release.
This layer is also mostly solved. Reproducible, containerized CI is close to a baseline expectation now, not a differentiator.
Image: The same IAR toolchain running a Linux-based CI pipeline end to end, build, static analysis, unit testing, and deploy, with a verified artifact to show for it.
Layer three: A toolchain that stays in its comfort zone
Here is where the stack usually stalls. Deep, hardware-aware debugging, trace-level and RTOS-aware, ETM trace, live register views, live watch without halting execution, has historically been the strongest argument for staying on Windows. Add TÜV SÜD-certified toolchains for ISO 26262, IEC 61508, or IEC 62304, and re-hosting onto a new OS stops being a rebuild and becomes a compliance exercise. JTAG and debug probe drivers, alongside licensing infrastructure have also, historically, been more mature on Windows.
None of that was inertia. Those are structural, defensible reasons, and they are exactly why this layer moved last: it was the one place where "just recompile it for Linux" was never actually true.
What changes when the toolchain itself goes cross-platform
The IAR Platform's cross-platform IDE closes this last layer. It brings the certified compiler and debugger natively to Linux, alongside Windows, built on the Qt framework so the UI is genuinely native on each OS, not a compatibility shim.
-
The same certified toolchain and the same reproducible binary results on every developer workstation and every build server, without re-validating the toolchain itself to move OS
-
CMake-ready and CI-ready by default, so the same project configuration runs identically from the terminal, inside the IDE, and inside CI
-
The debug depth that used to be the reason to stay on Windows: trace, RTOS awareness, and live register views, now available natively on Linux as well
-
Standardize the compiler, the build definition, and the analysis tools. This determines whether a build is reproducible, and it belongs in version control, not in a tool-specific project file.
-
Keep CI containerized so every pipeline run pulls the exact same image the desktop uses, with no drift between "the CI version" and "the developer version" of a setup.
-
Let the editor be a preference. One engineer works from the full IDE for deep trace sessions. Another lives in VS Code. A third scripts everything from the terminal. All three now produce identical binaries, on either OS.
That combination, certification, cross-platform reach, and trace depth, all intact at once, is the part worth pausing on. Plenty of tools offer one or two of the three. Keeping all three while adding a second OS is the actual engineering problem, and it is the one this release was built to solve.
Image: A live RTOS-aware debug session in IAR Embedded Workbench, thread list, semaphore states, live locals, and disassembly, running natively rather than through a translation layer.
Standardize the toolchain, not the developer
With all three layers finally aligned, the workflow separates two decisions that used to be bundled together: what produces the binary and where an engineer prefers to work.
Once the toolchain layer is locked down, the operating system stops being a tradeoff. Pick Linux, keep debug depth. Pick Windows, keep CI parity. Pick a lightweight editor, keep trace access when you need it. That is the property worth naming: hybrid teams do not need to mandate a migration, they just stop losing something for whichever choice an engineer already prefers.
The stack is only as modern as its slowest layer
A modern embedded workflow is not defined by its newest piece. It is defined by whichever layer has not caught up yet. For a lot of teams, that was the certified toolchain itself, the one part of the stack still asking developers to choose between the OS they build on and the OS everything else already runs on. Worth checking which layer is still holding your own workflow back.
What's Next
Want to see the full stack in practice? Here is where to pick it up:
- Register for the live webinar, September 17th, "The Cross-platform IDE Made for Developers, Now in the IAR Platform" to see it demoed end to end. Sign up for the Europe and Asia or Americas session. -
- Request a trial of the cross-platform IDE and run it against your own CMake project.
- Book a dedicated demo with one of our experts to walk through your team's specific toolchain, CI, and compliance setup.