Resources - links to everything you need to build with UNA

Getting Started
1

UNA Watch SDK: GitHub - UNAWatch/una-sdk · GitHub

SDK Documentation: https://www.developers.unawatch.com/

App Store: https://apps.unawatch.com/

Public Roadmap: https://roadmap.unawatch.com/

3 Likes
2

Hey, what is the App Store account approval process / ETA of it opening? I tried to create an account but it doesn’t seem to be working.

3

Hey Juhani, big push to get this out next week. Few things we’re ironing out to do with config files for the apps.

2 Likes
4

Great, I have been waiting for this too!

5

Hi folks,

Is the firmware itself also open-source?
To be more specific, I have a bunch of BLE sensors/devices any sport watch supports, but Una hasn’t yet. Namely: FTMS smart trainers, Stryd, Core2 sensor, power meters, rear radars. Can third-party developers add support for those without waiting for firmware release, according to the roadmap?

1 Like
6

Hey!

We’re actively working on releasing this. @Ross_UNA has been hard at work bringing the early stages of FTMS to life, and I believe we’re not far away from a first release of indoor bike as an activity.

Not sure about developers getting involved on the BLE protocol side of things (as it’s reliant on the kernel), but it’s something we’re always open to building on.

7

Is the firmware itself also open-source?

UNA has addressed that in Defining Openness

Can third-party developers add support for those without waiting for firmware release, according to the roadmap?

As far as I’m aware the current answer is, “no” and that’s a tough one

8

Awsome that you guys are working on this! I would also really like to have support for the Stryd pod!

I feel like once the app store is saturated with apps covering the base needs it’ll eventually be hard to innovate as a developer, beyond adding minor conveniences for niche activities, new watch faces, or gimmicks. If devs and hardware tinkerers could be enabled to extend the watch with custom BLE sensors/devices that could really open up the space of possibilities.

Instead of opening up the kernel, could a generic option still be viable? For example a sensor kind that takes any BLE device exposing a chosen standard GATT profile, or a small whitelisted GATT-bridge API?