# Eclipse iceoryx: zero-copy IPC that has already chosen its successor

> iceoryx classic moves data between processes through shared memory with no copy at all, giving constant transmission latency whatever the payload size. It is Apache-2.0, listed for five operating systems, and in maintenance mode with a stated end of life tied to iceoryx2's first stable release.

**eclipse-iceoryx/iceoryx** — Eclipse iceoryx™ - true zero-copy inter-process-communication

- Repository: https://github.com/eclipse-iceoryx/iceoryx
- Website: https://iceoryx.io
- Stars: 2,192 · Forks: 494
- Language: C++
- License: Apache-2.0
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/eclipse-iceoryx-iceoryx

## The notice at the top of the README decides this one

Before anything else: iceoryx classic is in maintenance mode and will no longer receive new features, only security fixes. There will be no further major releases. Shortly after the iceoryx2 v1.0 release, iceoryx classic will reach end of life.

The maintainers state where their attention has gone. The focus has shifted to iceoryx2, which the same notice describes as harder to break, feature-rich, and running on more platforms. The recommendation is explicit for both audiences: use iceoryx2 for new projects, and migrate existing projects to it.

That is an unusual thing to find in a README, and it changes how to read everything else here. The last push to this repository was on 2026-08-18, so the project is not dormant and not archived, and security fixes are still arriving. What you are looking at is a maintained component with a scheduled death, which is a normal and respectable thing for a foundation project to do to its first generation.

So the question for an evaluating team is narrow. Adopting iceoryx classic now means adopting something with a dated end of life and a migration already on the roadmap. That is defensible for a vehicle already in production, where the migration cost is larger than the remaining lifetime. It is hard to defend for a new system.

## Zero-copy shared memory, and what constant latency buys

iceoryx is an inter-process-communication middleware, and the mechanism is a true zero-copy shared memory approach that transfers data from publishers to subscribers without a single copy.

The claim that follows is specific rather than general. Because the payload is never copied, transmission latency is constant regardless of the size of the payload. A copy-based transport such as a socket pair or a serialised message bus costs more as the message grows, so the property that matters here is flatness, not speed at a particular size.

The project is honest about what middleware means. It points you to a goals and non-goals document rather than asking you to take the word on trust, and it explicitly positions itself as low-level. The untyped C++ API and the C API are described as plumbing in the sense Git uses that term, and the maintainers say they do not use those APIs themselves, using the typed C++ API instead.

The intended integration is as a transport layer inside a larger framework that supplies the API above it. ROS 2 is given as the example of such a porcelain API, and the frameworks listed as using iceoryx read the same way: ROS 2 through rmw_iceoryx, Eclipse eCAL, RTA-VRTE for AUTOSAR Adaptive from ETAS, Cyclone DDS, Apex.Ida from Apex.AI, and AVIN's AGNOSAR Adaptive Platform. Origins are automotive, and the same mechanisms are said to apply to robotics and game development.

## The platform table is the real specification

The supported-platforms table carries four columns and one of them is the one that matters. Operating system, compiler, whether the platform supports access rights for shared memory, and whether command line parsing is available.

Linux with gcc or clang: access rights yes. QNX with gcc: access rights yes. Those are the two platforms where shared memory can have permissions on it, and therefore the two where you can run processes with different users and rely on the operating system to keep them out of each other's segments.

Everything else is a no, and the table is explicit that it is not planned for implementation. macOS with clang, FreeBSD with clang, both without access rights for shared memory. Windows 10 with msvc is also no for access rights, and its command line parsing column reads will be implemented, which is a promise about a future release rather than a present capability.

Then the sentence that qualifies the whole table. In general unix platforms should work with iceoryx, but only FreeBSD is tested on the project's CI, which is consistent with `.cirrus.yaml` in the repository root, a continuous integration service associated with BSD hosting.

So the platform list in the introduction is a compatibility statement and the table is a feature statement. If your deployment depends on shared memory permissions or on Windows, this is where you find out that the introduction is not telling you the whole story.

## Seven directories, and a layer you did not know you needed

The repository root is organised as a set of C++ subdirectories with distinct roles, and their names are not expanded anywhere in the repository listing.

`iceoryx_posh` is the publisher-subscriber core that the rest is built around. `iceoryx_hoofs` sits beneath it as shared utility and platform-support code. `iceoryx_binding_c` is the C binding, matching the README's description of a C API alongside the untyped C++ one. `iceoryx_platform` holds the per-OS adaptation layer, which is where the differences in the platform table are implemented, and there is a document for adding a platform at `doc/website/advanced/custom-iceoryx-platform.md`.

`iceoryx_meta` is the build definition layer, since the repository uses Bazel and CMake side by side. `iceoryx_examples` is where the worked examples live and where the README sends you after building. `iceoryx_integrationtest` is separated out, which is what you would expect from a project that cares about qualified platforms.

The separation between typed C++ and untyped C is the design decision worth understanding before you write code against it. The maintainers say they do not use the low-level APIs themselves, which is an unusual admission and a useful one: it means the typed API is the supported surface and the plumbing exists for language bindings you may never use directly.

## Two build systems and one unusual CI configuration

The root contains both Bazel and CMake configuration. There is `BUILD.bazel`, `MODULE.bazel` and `.bazelrc` for Bazel, and a `cmake/` directory alongside `WORKSPACE.bazel` and `WORKSPACE.bzlmod`. Having both `WORKSPACE.bazel` and `WORKSPACE.bzlmod` present at once indicates the project is carrying the legacy workspace mechanism while moving to bzlmod, which is Bazel's newer module system.

Static analysis is configured rather than ad hoc. There is a `.clang-format` for formatting, a `.clang-tidy` for linting, and a separate `.clang-tidy-diff-scans.txt` that scopes which checks run on changed lines only. That pattern matters for a project in maintenance mode, because it keeps review cost low on a codebase receiving fixes rather than features.

The README does not give you a build command. Installation guidance is a linked document at `doc/website/getting-started/installation.md`, and for people who would rather not install anything on the host there is a Docker path documented in `tools/docker/README.md` for building and running iceoryx applications in a container. Examples are documented in `iceoryx_examples/README.md`.

The repository also carries `GOVERNANCE.md`, `SECURITY.md`, `QUALITY_DECLARATION.md`, `PLANNED_FEATURES.md`, `NOTICE.md` and a `VERSION` file, which is the paperwork an Eclipse project carries and which tells you where decisions get made when you disagree with one.

## The release timeline tells the same story as the notice

Three releases are listed. v2.0.8 on 2026-05-19, v2.0.7 on 2026-05-08, and v2.0.6 on 2024-04-26.

The gap between v2.0.6 and v2.0.7 is roughly two years, and the two releases that followed came eleven days apart in May 2026. So the project was quiet and then shipped two patches close together, which is the shape of a maintenance-mode transition rather than of a feature line.

The version numbering is consistent with the notice. Two patch releases after 2.0.6, no third digit climbing, and an explicit statement that there will be no further major releases. Nothing in the listed releases contradicts the claim that new features have stopped.

For an adopting team this is a scheduling question. If you are integrating iceoryx classic into something that will run for a decade, you need a date for iceoryx2 v1.0, because the notice ties classic's end of life to it. The README does not give one, which means the migration window is defined by another project's schedule rather than by this one. That is a dependency worth naming early, because it is the kind of thing that is invisible until it is urgent.

## iceoryx against iceoryx2, in the maintainers' own words

The alternative here is not a competing project chosen by an outsider. The maintainers name it, link it, and recommend it, describing iceoryx2 as more robust, feature-rich, and running on more platforms than the classic line.

The README does not describe what changed in the rewrite, so you cannot compare the two architectures from this page. What it does establish is that the classic design left something on the table, since running on more platforms is exactly the weakness the platform table documents, with shared memory access rights missing on macOS, FreeBSD and Windows and Windows command line parsing still listed as unimplemented.

That reframes the platform limitation in section three. If shared memory permissions on macOS are the reason you were considering iceoryx, that gap is one the maintainers have already prioritised elsewhere.

The practical recommendation follows from the two sections together. For a new system, start with iceoryx2 and accept the learning cost, because classic has a scheduled end of life and no feature roadmap. For a system already shipping on classic, keep it patched, plan the migration against iceoryx2's release schedule, and treat the ROS 2 relationship as the thing to verify, since rmw_iceoryx is the layer that would need to track whichever generation you choose.

## Conclusion

Adopt iceoryx classic only for an existing deployment already validated against it, where the remaining lifetime is shorter than the cost of migrating, and keep taking the security fixes. For anything new, start with iceoryx2 as the maintainers recommend. Verify first whether your platform needs shared memory access rights, because the README's table supports them on Linux and QNX only and marks them not planned for macOS, FreeBSD and Windows.

## FAQ

### Is Eclipse iceoryx still being developed?

It is in maintenance mode and will no longer receive new features, only security fixes, and there will be no further major releases. Shortly after the iceoryx2 v1.0 release it reaches end of life, and the last push to the repository was on 2026-08-18.

### Which operating systems does iceoryx support?

The introduction lists Linux, QNX, macOS, FreeBSD and Windows 10. The platform table qualifies that: shared memory access rights are supported on Linux and QNX only, and Windows 10 command line parsing is listed as will be implemented.

### What does zero-copy mean in iceoryx?

Data moves from publishers to subscribers through shared memory without a single copy, which the README says keeps transmission latency constant regardless of payload size rather than growing with the message.

### Should I use iceoryx or iceoryx2 for a new project?

iceoryx2. The README recommends it for new projects and for migrating existing ones, describing it as harder to break, feature-rich, and running on more platforms than iceoryx classic.

### Which frameworks use Eclipse iceoryx?

The README lists ROS 2 through rmw_iceoryx, Eclipse eCAL from Continental AG, RTA-VRTE for the AUTOSAR Adaptive Platform from ETAS, Cyclone DDS maintained by ZettaScale Technology, Apex.Ida from Apex.AI, and AVIN's AGNOSAR Adaptive Platform.

### What licence is Eclipse iceoryx under?

Apache-2.0, per the badge in the README and the LICENSE and NOTICE.md files in the repository root. Check those files for the terms themselves, as this is not legal advice.

## Sources

- [eclipse-iceoryx/iceoryx on GitHub](https://github.com/eclipse-iceoryx/iceoryx)
- [License: Apache-2.0](https://github.com/eclipse-iceoryx/iceoryx/blob/main/LICENSE)
- [Project website](https://iceoryx.io)
- [README](https://github.com/eclipse-iceoryx/iceoryx/blob/main/README.md)
- [Releases](https://github.com/eclipse-iceoryx/iceoryx/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-iceoryx-iceoryx