ABOUT THE WORK

Aston Dynamics builds brake-by-wire systems for trailers and autonomous vehicles. Our electric-over-hydraulic (EoH) platform replaces conventional mechanical override and electric-drum trailer braking with electronically controlled hydraulic actuation, giving faster, more precise, independently controllable braking.

You'll be working on software with a physical consequence. The app you work on is how users actually meet the product: it connects to an actuator over Bluetooth, shows live data from a physical machine, configures hardware that stops a loaded trailer, and pushes firmware updates to it. You will spend time at the bench and on vehicles, working closely with the firmware and electronics engineers who build that hardware.

Our architecture is unusual and worth understanding before you apply. Our BLE stack is not a JavaScript library - it is a Rust core exposed to React Native through UniFFI, sharing protocol definitions with our microcontroller firmware. Every device-facing feature in the app - live telemetry, gain, sway, calibration, OTA - is a Rust function behind that boundary. The TypeScript is a thin layer over generated bindings.

That means there is no such thing here as a purely TypeScript mobile role.

TWO POSITIONS, ONE ADVERTISEMENT

We're hiring two engineers into the same codebase and weighting them differently.

Apply once; tell us which end you lean toward:

1. Device-weighted - you'd own the Rust BLE core, the UniFFI boundary, the OTA path, and the protocol seam with firmware.

2. App-weighted - you'd own the Expo/React Native app, the offline data path, release engineering, and the product surface.

Both need to be able to read and change async Rust behind a UniFFI boundary.



Neither needs to be expert in the other's half on day one.

WHAT YOU'D WORK ON

- Extend the Rust BLE library and its UniFFI bindings into the React Native app.

- Build reliable device pairing. Several visually identical actuators may be in range, some belonging to other customers, with no operator-visible identifier on the housing. You'd design the disambiguation and make it durable.

- Ownership of the over-the-air firmware update path.

- Strengthen the security of the device link, including pairing, bonding and signed firmware images.

- Implement device configuration and calibration at protocol level, including reading from and writing to device storage.

- Design and build the offline data path: durable local queuing, retry, deduplication, and survival across restarts and reinstalls. This is current work, defined end to end with our incoming backend engineer.

- Extend real-time visualisation of live actuator data, including choosing the right rendering approach for it.

- Build a guided first-run setup flow so a technician can get started without training.

- Implement multi-brand theming and build configuration so branded variants are configuration rather than app forks - themes, assets, bundle identifiers, signing identities and store listings.

- Own store releases across variants: build configuration, signing, TestFlight and submission.





- Debug BLE behaviour on physical hardware across iOS and Android: connection stability, backgrounding, timing and reconnection.

- Build out automated test coverage for device-facing code.

REQUIREMENTS

- A systems programming background. Our device library is async Rust and the firmware it talks to is embedded Rust. We don't require Rust on day one if you have strong C, C++ or similar, but expect to be writing non-trivial async Rust within weeks.

- Working knowledge of React Native and TypeScript. We're an Expo app end to end - expo-router, EAS, config plugins - which is materially different from bare React Native CLI.

- BLE from the app side: connection lifecycle, notify/subscribe semantics, and the Android 12+ runtime permission model.

Additionally, for the app-weighted position:

- App signing, provisioning and store submission - ideally at least one app you have personally shipped to both the App Store and Google Play.

- Performance-sensitive rendering. We build our own instrumentation rather than leaning on a charting library.

- Comfort making small changes to a Node/Express backend, with enough Prisma and relational-schema literacy to add a model or a migration.

NICE TO HAVE

- UniFFI, or comparable cross-language binding and FFI work.

- Native build-toolchain experience: Gradle, CMake, NDK, CocoaPods, JNI. Our native layer is generated rather than hand-written, so build-system skill is worth more here than native app development.

- Prior OTA firmware update experience.

- Embedded Rust, or embedded C with an interest in moving to Rust.

- White-label or multi-variant app architecture.

- Automotive, industrial or other safety-relevant systems.

- Familiarity with NixOS.

📌 Mobile BLE Engineer (Clayton)
🏢 Aston Dynamics
📍 Clayton