AN OPEN-SOURCE WEARABLE, DESIGNED TO BE OWNED BY YOU.
Most wearables are sealed shut. UNA is built to be opened — the hardware today, and more of the software every month. Here's exactly what's open, what isn't, and why.
UNA was built by nerds. There's no better way to put it.
We set out to make a GPS watch for runners, hikers and cyclists — and somewhere along the way we realised the people most interested in what we were doing were developers. People who wanted to know what was inside, how it worked, and whether they could build on it.
From the very start we wanted to let them. A community of people who all care about one thing, working together to make it better — that's the dream for any brand. So here's exactly what's open, what isn't, and why.
UNA's custom firmware, built on FreeRTOS.
This won't be publicly released, and we'd rather say so plainly than leave it vague. First, we're legally unable to — several component manufacturers, including our PPG sensor, GPS and BLE suppliers, require NDAs protecting their algorithms and IP. Publishing our kernel would expose their work, and that isn't ours to give away.
Second, it protects you. The kernel is the beating heart of the watch and sits closest to your data and your device's safety. What we are exploring is opening the interfaces to it, so your apps can talk to the kernel without the kernel itself being exposed.
The SDK is live. And it isn't a sandbox.
UNA apps aren't sandboxed, interpreted, or run in a virtual machine. You write C/C++, it compiles to ARM machine code, and it executes directly on the watch's processor — at full speed, with direct access to the hardware.
That's rare. Most wearable platforms put a layer between you and the device and decide what you're allowed to reach. We don't.
NATIVE PERFORMANCE
Compiled ELF binaries running directly in MCU memory. No interpreter, no runtime tax, no waiting for a platform to expose a feature.
THE SAME CODE WE WRITE
Every app that ships on UNA — the alarm, the heart rate monitor, the running tracker — is in the SDK as working reference code. Read it, copy it, take it apart, build something better.
DIRECT HARDWARE ACCESS
Sensors, BLE and display at MCU speed, through a service-and-GUI process model built for real applications rather than toys.
STANDARD TOOLING
CMake, ARM GCC, TouchGFX for interfaces, GoogleTest for unit tests. A normal embedded workflow — nothing proprietary to learn, nothing locking you in.
NO MEMORY ISOLATION
There's no MMU on the watch, so apps aren't isolated from each other or the kernel at the hardware level. That's the trade-off for native speed and full access, and worth knowing before you install code you didn't write.
HARDWARE
The hardware questionis the one we haven't solved.
We'd rather tell you where we've got to than pretend this is finished.
CAD and STEP files
We want the community designing accessories that actually fit — straps, mounts, cases, things we'd never think of. That needs real geometry, not guesswork.
The hold-up is licensing. We want makers building for UNA. What we don't want is a factory mass-producing low-quality knock-offs we can't stand behind, sold to people who think they're buying something we made.
Where we've got to
We're a small team and we can only cover so much at once, so this is taking longer than we'd like. We're working through what licence gets us the first outcome without enabling the second.
We aim to publish some industrial design information before the end of 2026.
WHAT'S COMING
Being built now,not yet released.
Kernel interfaces
Not the kernel itself — see below — but the interfaces to it, so your apps can reach parts of the watch that are currently out of bounds.
A data API
Your activity data, available to you directly. Export it, analyse it, plug it into whatever you like. It's your data and you shouldn't have to ask us for it.
An MCP server
So you can point AI tools at your own training data and actually ask it questions. As far as we know, no other watch brand is doing this.
The UNA mobile app
The app isn't open source today. It handles account authentication and the credentials behind third-party integrations like Strava — publishing it would expose those paths in ways that put user accounts at risk.
What we are doing is opening the genuinely useful part: a data API so you can reach your own activity data directly, and an MCP server so you can connect it to AI tools.
Communications and connectivity
The BLE stack and radio layer stay closed, and this one is largely out of our hands. Radio certification is granted against a specific combination of hardware and firmware. Publishing the radio parameters would let people modify behaviour in ways that void that certification, which in most countries makes the device illegal to operate.