Apex.OS 25-11: Building for Bigger Systems and Longer Horizons

The work of scaling software for autonomy never really stops. Each release teaches us something new about what developers need when their systems grow, distribute, fracture, recover, and interact with the real world, with all its glorious indifference to our abstractions. 

With release 25-11, Apex.OS continues to evolve steadily: sustained determinism, more tooling for insight, more safeguards, greater flexibility across architectures, and more ways to build and debug distributed systems. This release also marks a noteworthy transition: our Docker-based development environment, ADE, is now fully deprecated, and the ecosystem around Apex.OS continues to mature toward long-lived, production-bound deployment workflows based around hermetic builds. 

This post highlights what stands out in the release, not as a list of items from a changelog, but as a narrative of where the platform is heading. 

Cross-Compiling for Tomorrow’s Hardware 

As systems in mobility, agriculture, and heavy industry adopt increasingly heterogeneous compute, developers need toolchains that follow. Release 25-11 introduces full Yocto 5.0 (Scarthgap) cross-compilation support for ARM64 targets, including Bazel C++ toolchains. 

That means you can build Apex.Grace-based applications for the next generation of embedded platforms without juggling mismatched toolchains or duct-taping your way through build reproducibility. 

Ubuntu Focal support has also been fully removed. With Focal reaching end of life, the move protects teams from inheriting security debt and encourages migration to Jammy or newer stacks. 

This is infrastructure maturing, boring in the best possible way. 

Introspection and Debugging for Real-World Systems 

You can’t scale what you can’t see. This release expands the introspection surface of Apex.Grace: 

• A shared fixed-width timestamp formatter provides consistent temporal markers across components 

• The pmtop tool now surfaces per-process CPU, memory, and shared memory usage, improving field diagnostics 

• New tutorials walk through RQt-based graphical introspection and end-to-end workflows for the Apex.Grace CLI, covering QoS, build/deployment patterns, and troubleshooting methodology 

Instrumentation is no longer tertiary; it’s becoming a first-class development workflow. 

More Control Over Distributed Recording 

For teams working with complex multi-sensor systems, or fleets of them, recording isn’t just an offline convenience. It’s part of continuous test workflows, validation pipelines, and sometimes operational monitoring. 

Release 25-11 brings a suite of deeply practical improvements: 

• A direct API for rosbag2_transport::Recorder::record, enabling device-driven or gateway-driven recording without subscription scaffolding 

• A standalone Python API for rosbag2 

• Distributed recording APIs with remote discovery and control 

• Time-based bag splitting, scheduled start/resume times, and unified error_code reporting 

Under the hood, major race-condition fixes and message-ordering guarantees strengthen determinism during playback and capture. 

These features collectively acknowledge an important reality: modern autonomy stacks aren’t monoliths; they’re distributed recording systems with robots attached. 

Process Lifecycle Support That Matches Real Deployments 

Self-terminating processes, common in testing, simulation, and diagnostics, haven’t always fit neatly into deterministic lifecycle orchestrators. Release 25-11 changes that. 

Apex.Grace now allows such processes to declare startup and shutdown phases, meaning the system manager can incorporate them cleanly into multi-stage bring-up and tear-down. 

Combined with UTC timestamping of start/stop events and improved error logging, the process manager is becoming a more transparent, more predictable control plane for complex systems. 

Gateway and Connector Advances for Automotive and Agriculture 

CAN, CAN-FD, ISOBUS, SOME/IP — these are not side quests. They’re the arteries of the industry's Apex.OS operates in. 

This release delivers: 

• Dynamic addressing for the ISOBUS connector, enabling more resilient interactions in agricultural machinery networks 

• Channel-level configuration of the CAN-FD BRS flag via bitrateswitch 

With Apex.Ida, additional correctness fixes address race conditions, segmentation faults, and waitset behavior, exactly the sort of low-level issues that only appear when systems encounter real hardware and real timing. 

Robust communication layers don’t call attention to themselves. They just quietly not-break, and that’s the goal. 

Tools and Libraries for Broader Applications 

Our platform continues to expand horizontally: 

• A DLT writer now integrates Apex.Grace logging with the industry-standard Diagnostic Log and Trace protocol, particularly valuable for automotive OEM workflows 

• OpenCV, OGRE, and Assimp Debian packages are now vendored into the Bazel workspace on Jammy, with aarch64 builds supported 

• A new time_transform library enables conversion of time values across time domains, critical for multi-sensor fusion and simulation alignment 

These aren’t glamorous features, but they remove hurdles that slow teams down. 

A Platform Growing Into Its Future 

If the 25-08 release was about “scaling beyond roads,” the 25-11 release is about scaling beyond the edge cases — the little mismatches, inefficiencies, and hidden technical debts that only surface when software is deployed into real worlds shaped by weather, vibration, electromagnetic noise, and unsympathetic physics. 

This release strengthens the foundation: more determinism, more control, more introspection, more performance headroom, and more alignment with the ecosystem's Apex.OS lives within. 

The work continues, and each release brings us a step closer to making autonomy software not just powerful but also predictable. If you are interested in Apex.AI products for your projects, contact us.