Your extensions can now describe their own pages to Trackunit Manager's AI assistant. Add an aiNavigation field to a manifest — a list of in-app routes, each with a path, a title, and a description — and the assistant can take a user straight to the page inside your app that answers their question instead of dropping them on its root.

This works today for every extension type that has a page a user can land on: Fleet, Admin, App Settings, Asset Home, Site Home, Customer Home, and Asset Events Actions. The field is opt-in and purely additive — apps that don't declare it behave exactly as before.

See Extension Point Types — AI navigation for the full reference: the manifest shape, both Tanstack Router styles, and in-app paths for entity-scoped extensions.

Manager is moving content inset for Asset Home, Site Home, and Admin extension iframes onto each app. After you upgrade @trackunit/iris-app to 2.5.13 or later, the host stops applying its transitional 1rem inset. Your extension must pad itself with p-content-space on the scrollable content region (or intentionally stay edge-to-edge).

Run the automated migration before or as part of that SDK upgrade — not as optional cleanup afterward. It ships as v2-5-12-p-content-space-codemod in @trackunit/iris-app 2.5.13.

npx nx g @trackunit/migrations:migrate
npx nx g @trackunit/migrations:run-migrations

@trackunit/react-drawer has been reworked to align with Sheet and Modal: a new useDrawer hook owns state and dismiss, a new DrawerHeader component provides the standard toolbar, and the panel now has explicit variant="default" | "modal" semantics. Legacy inline props on <Drawer /> (open, onClose, onOpen, hasOverlay, keepMountedWhenClosed) and the DrawerToggle component have been removed.

You can now inspect serverside function logs for your IrisX Apps directly in the Developer Console.

Open an app that includes Serverside API Extensions, select the Logs tab, then filter by date range and verbosity, search by message or function name, follow live entries when the range includes now, and open any row for full details.

See Viewing serverside function logs for the full guide.

@trackunit/react-components's MenuList claimed Up/Down keyboard navigation and nested-menu support in its docs that it never actually implemented — it was just a role="list" div with click handlers. It's now been rewritten with real WAI-ARIA menu semantics and renamed to MenuContent to reflect that. MenuItem also gains a new submenu prop for building nested menus, and the MenuTree/useMenuTree tree-coordination primitive that powers it is now public API.

In this version of our Iris App SDK, we have upgraded NX to v23.1.0. This release also moves Iris App builds onto Vite 8.

Make sure to upgrade your extensions to the latest version of NX.

npx nx migrate 23.1.0
npx nx migrate --run-migrations

Please refer to Maintaining Your Application for more information.

The @trackunit/iris-app-sdk-webpack, @trackunit/iris-app-sdk-rspack, and @trackunit/iris-app-webpack-plugin packages have been removed. Vite (@trackunit/iris-app-sdk-vite) is now the only supported build system for Iris Apps.

The Device Health Issues API is now generally available. The endpoints have been promoted from v1beta1 to v1, and the API is no longer marked as beta.

Below is a list of all available REST endpoints:

Issue API​

➕ GET: /v1/assets/{assetId}/issues

Get issues by asset

➕ GET: /v1/issues

Get issues

➕ GET: /v1/issues/{issueId}

Get issue by id

Breaking changes

⚠️ The v1beta1 endpoints have been replaced by v1. Update any integrations to use the /v1/... paths.

⚠️ The issue type LOW_DEVICE_BATTERY_VOLTAGE has been renamed to LOW_DEVICE_BATTERY. Update any filtering or handling that relies on this value.

The @trackunit/iris-app-sdk-webpack and @trackunit/iris-app-sdk-rspack build executors are deprecated and will be removed in the coming months. Vite is the supported path forward — migrate your Iris app to the Vite executor.

The Telematics Device API now lets you roll back a previously executed configuration job. Rollback creates new configuration jobs that restore each device to the configuration it had before the original job ran.

Devices that have had their configuration changed since the original job (manually, by another job, or by automation) are excluded from rollback so the rollback never silently overwrites a newer change. A rollback request can produce more than one rollback job because devices are grouped by the previous configuration they shared.

Today, rollback is supported for CAN profile, Modbus profile, and Operating Mode changes. Other configurations the original job touched are excluded from the rollback's desired state — additional configurations will be announced as they become available.

➕ POST: /v2/configuration-jobs/{id}/rollbacks

Rollback a configuration job