ekxide logo
iceoryx2releaserustcppcpythoncsharp

Announcing iceoryx2 v0.8.0

Christian Eltzschig - 23/12/2025

Header

What Is iceoryx2

iceoryx2 is a communication library designed to build robust and efficient data-intensive systems. It enables ultra-low-latency communication between processes — comparable to Unix domain sockets or message queues, but significantly faster and easier to use.

The library provides language bindings for C, C++, Python, Rust, and C#, and runs on Linux, macOS, Windows, FreeBSD, and QNX, with experimental support for Android and VxWorks.

iceoryx2 supports multiple messaging patterns, including publish-subscribe, events, request-response streams, and the recently introduced blackboard pattern, a key-value repository implemented directly in shared memory. Its architecture is fully decentralized and does not rely on a central broker, which improves robustness and scalability.

To get a better impression of the performance characteristics, check out the iceoryx2 benchmarks and try them on your own platform.

benchmark

Release v0.8.0

With v0.8, we expanded the iceoryx2 Book with additional pages, deeper technical explanations, and architectural deep dives into the implementation of our messaging patterns.

The complete list of changes is available here: iceoryx2 v0.8.0 release

This release introduces:

Alongside the open-source release, our new ekxide extensions add support for hypervisor-backed shared memory and cross-core communication - enabling advanced mixed-criticality setups on modern SoCs from NVIDIA, Qualcomm, Renesas, TI, and NXP.

CSharp Language Bindings

Thanks to a community contribution by patdhlk, we are happy to announce the first version of C# language bindings for iceoryx2. The bindings are available in the iceoryx2-csharp repository on GitHub.

The current implementation already supports the Request-Response, Event, and Publish-Subscribe messaging patterns. This makes iceoryx2 a viable option for high-performance zero-copy inter-process communication from C#. In combination with the iceoryx2 tunnel, it can also be used for distributed applications over the network.

no_std and Bare-Metal Support

With v0.8, iceoryx2 can now be built in no_std environments. On POSIX-compliant systems that do not provide the Rust standard library, such as QNX 8.0, this support is fully functional.

In addition, we have a bare-metal proof of concept running. In this environment, data-flow-oriented messaging patterns such as publish-subscribe, request-response, and blackboard communication are already operational. Event-based communication is not yet supported, as it requires interrupt handling or a similar mechanism.

It is important to emphasize that this bare-metal support is still experimental. The current memory footprint is larger than desired, and the stub platform is not yet optimized for production use. Nevertheless, it demonstrates that iceoryx2 can operate without an operating system and lays the groundwork for future improvements.

More details and build instructions can be found in the documentation: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/doc/development-setup/nostd-builds.md

Memory Layout Compatible Data Types

When communicating between processes written in different languages, such as C++ and Rust, developers typically have to serialize data. iceoryx2 offers an alternative through memory-layout-compatible data types, enabling true zero-copy communication across language boundaries.

To achieve this, we implemented our own set of container and data types that are explicitly designed to be safe for shared memory and to have identical memory layouts in both C++ and Rust. This guarantees correctness without relying on fragile compiler or ABI assumptions.

We provide several examples that guide users through zero-copy inter-process communication between multiple languages, including C++, Rust, and for basic data types also C and Python:

Android Platform Support - Proof Of Concept

We have ported iceoryx2 to Android, where it can already be used within a single process to manage communication between threads. Full inter-process communication support still needs funding.

The main challenges on Android are handling the sandboxed execution environment and integrating the Binder IPC mechanism. Depending on the final architecture, this may also involve introducing an additional daemon responsible for managing and distributing communication resources.

If you want to experiment with the current state, the documentation is available here: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/doc/development-setup/android.md

Other Feature Highlights

With this release, iceoryx2 no longer depends on iceoryx classic. The hoofs component has been fully integrated into iceoryx2, simplifying the dependency structure.

Thanks to the new no_std support, QNX 8.0 is now officially supported. Setup instructions are available here: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/doc/development-setup/qnx.md

In addition, language bindings for the blackboard (the shared-memory key-value repository) are now finalized and can be used from C, C++, and Python. The C# bindings do not support the blackboard pattern in their initial release.

Commercial iceoryx2 Extensions

ekxide follows an open-core business model. The core of iceoryx2 remains fully open source, while closed-source extensions are used to finance continued open-source development.

These extensions primarily target requirements found in safety-critical systems, such as additional artifacts, design documentation, or specialized features. They do not impose restrictions on standard iceoryx2 users.

The iceoryx2 architecture was explicitly designed to be extensible without forking. Extensions can be integrated with minimal code changes, allowing users to adopt additional functionality incrementally.

Our first commercial extensions enable zero-copy communication across hypervisor partitions and between ARM A-cores and R-cores.

memory link

Hypervisor

A common safety-critical deployment scenario involves QNX as a host operating system with multiple guest systems such as Yocto or Android. With our hypervisor extension, all of these environments can be connected using zero-copy communication.

In most cases, application source code does not need to be modified. Only the service variant must be adapted to use the hypervisor-backed shared memory instead of POSIX shared memory.

The extension is implemented generically and is intended to work across different hardware platforms and drivers. It also supports zero-copy communication between multiple QEMU instances connected via ivshmem.

Using the tunnel abstraction, a wide range of deployment scenarios can be unified under a single API. Thanks to iceoryx2’s dynamic features, this works without explicit configuration and provides a smooth migration path toward static deployments.

Cross-Core Communication

In many safety-critical systems, real-time tasks are executed on ARM R-cores, while compute-intensive workloads run on A-cores. Efficient communication between these cores is essential.

With this release, it is now possible to run iceoryx2 on an RTOS (Real‑Time Operating System) such as ThreadX, AUTOSAR, or even bare‑metal and enable seamless true zero‑copy data transfer between A‑cores and R‑cores.

Roadmap: What’s Next?

Looking ahead, we plan to provide a vcpkg package for easier deployment of iceoryx2. We will continue improving no_std support by reducing the memory footprint and expanding documentation and examples.

We also aim to bring the hypervisor and A-core to R-core communication extensions to production-ready quality for safety-critical use cases, and to continue development of our UI tooling, Mission Control.

Thank You

We want to thank our community. Your ideas, discussions, and collaborative spirit help shape iceoryx2 every day. Even frustrating bugs become less painful when tackled with humor and openness.

Also a big thank you to the iceoryx team, which was relentless in implementing all those features.

And finally, a big thank you to our customers who share our vision:

To create an open-source, certifiable base and communication library that can be trusted in mission-critical systems.