Open Wearables Roadmap

​

Overview

Over the last few months we’ve had a lot of emails, LinkedIn messages, and Discord questions about the roadmap, and we feel we owe you one. So here it is. Usual disclaimer: this is our current plan, and it may change as we learn from teams running Open Wearables in production.

​

Core platform

The core platform keeps growing: new data types, a faster mobile SDK, and hardening informed by instances that now handle far more users than a year ago. This is a dedicated part of the team’s work. At the same time, we’re building a few things on top of the core that we’re just as excited about, see Beyond the core.

​

The road to 1.0

Performance and scale. Early on, most of our effort went into getting the data model right. The scale of current deployments means performance now gets the same attention. We’re in the middle of stress testing the platform and working through what it surfaces: faster parsing and writing of incoming data, a leaner way of storing it, and tuning the infrastructure around it - Celery, Redis, and Postgres. Compliance. Open Wearables is getting a lot of traction in products where data sovereignty matters, and those tend to be heavily regulated: healthcare, clinical research, anything covered by frameworks such as HIPAA in the US or GDPR in the EU. Self-hosting is a big part of why these teams pick us, and we want the rest to work out of the box too: deleting a user really deletes everything, data retention is configurable, and access is auditable. These teams should be able to pass a compliance review without patching the platform first. Data model hardening. Fixing identity and idempotency issues found in production (duplicate events, data source identity, device inference), closing gaps in the unified data model, and filling in data that existing providers expose but we don’t store yet. Nutrition data. Calorie intake and macronutrients as first-class data types, for the providers that expose them (Apple Health, Google Health Connect, and others as their APIs allow). Concretely that means energy (kcal), carbohydrates, protein, and total fat, and because popular tracking apps like MyFitnessPal, Cronometer, Lose It!, Yazio, and Lifesum write their food logs straight into Apple Health, a single integration surfaces nutrition data that millions of users already log in those apps. Women’s health for Apple Health and Health Connect. Menstrual cycle tracking already works for Garmin. We are extending it to the mobile SDK path so the same data model is populated from HealthKit and Health Connect. Since Apple Health and Health Connect aggregate cycle data from apps like Clue, Flo, and Ovia, integrators get that data through a single connection instead of integrating each app separately. Mobile SDK improvements. The biggest one is optional on-device aggregation, which makes syncing months of historical data dramatically faster and cheaper on both the phone and the backend. Next to it, reliability hardening of the whole sync path and support for many new HealthKit and Health Connect data types. A year in, we have learned a lot about how tricky background sync on iOS can be, and we intend to make sure it never becomes your headache in your own product.

​

Beyond the core

Open Wearables is built by Momentum, and the platform started as a data integration layer. On top of it, we have built a lot of custom work for our clients: health scores, insights, AI agents, and other features that turn normalized data into something a product can use directly. The same problems kept coming back, so we’re turning that experience into ready-made modules you can drop into your own product and skip building from scratch. Custom work stays at the heart of what Momentum does. Many of the teams running Open Wearables in production got there with the Momentum team: designing the integration, building the features around the data, and deploying it on their infrastructure. Sometimes it was the whole product built end to end, with wearable data as just one piece of it. The modules change where such a project starts. With the common ground already covered, a custom engagement goes straight into the parts that are unique to your product and take it to the next level. If you’re building on Open Wearables and want the team that knows the platform inside out, talk to Momentum.

​

Later this year

​

Exploring

Things on our radar with no timeline yet. Listed so you know where our thinking is heading.

• Real-time data access - ANT+ and BLE streaming for live metrics like heart rate and steps.
• Workout planner - create and push structured workouts to devices via provider APIs (Garmin, Polar, Coros).
• Lab results and blood reports - OCR and standardization of lab reports into the same data model as wearable data.
• Custom device integrations - niche and medical-grade wearables that do not fit the standard provider model.
• Raw signal processing - working directly with raw biosignals such as PPG and IMU from devices that expose them, and deriving metrics like sleep detection and heart rate from the signal itself. Relevant for hardware teams building their own wearable.
• Observability stack - monitoring for both the infrastructure Open Wearables runs on and the provider connections themselves: whether data is flowing for each user, whether syncs are failing, and whether a provider’s API is having problems on its end.

​

New provider integrations

New providers are the most common request we get, so here is where things stand. The core team’s capacity is limited, and with the work above already committed, we cannot promise new integrations on a timeline. Open provider requests are tracked and prioritized by demand, but a request being open does not mean it is scheduled. There are two ways to get an integration built sooner.

​

Contribute one

Provider integrations are a great contribution, and the architecture is designed for it. Adding a new provider walks through the whole process. That said, before you start, please read the contribution guidelines and open an issue or ask on Discord to get a go-ahead, so we can agree on the scope and make sure nobody else is already on it. For this kind of contribution specifically, we ask that you have solid backend development experience. An integration touches OAuth, background sync, webhooks, and the mapping of a provider’s data onto the unified data model, and a mistake there corrupts data for every user of that provider. Every pull request is reviewed manually by a core contributor, and review time is our main bottleneck. A partial integration that needs to be rewritten during review costs more than building it in-house, which is why we ask for the go-ahead first and for the change to be tested against a real provider account before it is submitted.

​

Prioritize it with us

If you need a specific provider for a commercial product, it is possible to prioritize it as part of the Open Wearables commercial offering, including splitting the development cost between parties that need the same integration. The result is released as part of the core platform. Get in touch if that is an option for you.

​

Contributing to the roadmap