
Imagine that you have worn the same health tracker for three years. You know where to find your history and have developed a sense of what is usual for you. When it is time to replace it, another device looks more appealing. Perhaps it is more comfortable to sleep in, has a longer battery life, or simply costs less.
Before buying it, you face a question that the specifications cannot answer: how much of the understanding you have built will come with you?
There are several problems hidden inside that question. Your next device needs to work with your phone. Your records need to be accessible to the applications you want to use. And the measurements you collect next month need enough context to be understood alongside those from last year. Solving one does not automatically solve the others.
The hardware dependency is visible. Apple’s compatibility documentation, for example, specifies the iPhone and software versions that work with each Apple Watch model. Choosing a watch therefore involves a choice about the surrounding technology as well as the watch itself. That is a concrete ecosystem boundary, although it does not establish that the health records collected within it cannot be shared.1
That distinction matters, because an argument for greater device independence should acknowledge the work already done.
Apple allows applications, with permission, to read and write information in Health. It also provides an XML export of the health and fitness data stored there. Those are meaningful ways to make information available beyond the application that first recorded it.2
But exporting a history leaves questions about what the receiving application can do with it. Which records will it accept? Will it retain their source? Will it show an older measurement alongside a newer one as though they were produced in exactly the same way? The existence of an export answers the question of access more directly than the question of continuity.
What changes when the device changes?
A useful illustration comes from a 2024 study by Alexandra Jamieson and colleagues, published in Scientific Reports. The researchers fitted 16 healthy adults with a Garmin Vivoactive 4 and a Fitbit Sense and compared their measurements with reference instruments during walking, stepping, and chair-rise tests.
In the standard six-minute walking test, the median absolute percentage error for step counts was 1.8% for the Garmin and 6.8% for the Fitbit. Both watches were observing the same participants performing the same task, yet their agreement with the reference count differed.3
This was a small study of specific models in structured tests, with a young, healthy sample. It cannot establish which brand is best today, or how either watch performs across everyone’s daily life. Its relevance here is narrower: a familiar measurement label does not guarantee interchangeable results.
My interpretation is that any application promising continuity across devices must take that possibility seriously. If a graph changes after someone replaces a watch, the application should make the replacement visible before inviting the person to interpret the change as progress or decline. The study did not test device switching over time; that is a design implication drawn from its findings.
Consider a hypothetical person whose recorded activity rises after a device change. It would be premature to congratulate them on becoming more active solely because the combined chart slopes upward. Equally, discarding the earlier history would throw away potentially useful context. A more careful presentation would preserve both periods, identify their sources, and explain where comparison is uncertain.
This is what makes continuity a harder problem than putting records on one screen.
Existing connections are a foundation
Google’s Health Connect offers a useful example of how source information can be preserved. Its documentation describes metadata identifying the application that supplied a record, fields for device manufacturer and model, and a recording method that distinguishes automatic, active, and manual recording. The device details must be supplied by the application writing the record; they are not a guarantee that every record arrives with complete context.4
For someone reading a chart, the practical value is straightforward. A manually entered value and one recorded by a sensor may deserve different treatment. Knowing which application supplied a record can help explain why two entries disagree. My view is that this information should remain available to the person whose history is being presented, rather than disappear during the effort to simplify the interface.
Access also has conditions that need to be described accurately. Google documents a default limit on reading other applications’ Health Connect records from more than 30 days before permission was first granted. Access beyond that restriction requires an additional history permission. That is an access rule, not a statement that the older records have been deleted.5
It would be misleading to present every permission boundary as evidence of lock-in. People should be able to decide which applications can see their health information. Device independence should strengthen that control, including the ability to decline access.
The more useful question is what happens after someone chooses to share. Can the application explain what it received, what is missing, and what comparisons are justified? Can it acknowledge a gap without presenting it as a change in the person’s behaviour?
These are reasonable expectations for a health experience intended to last longer than a particular device.
The ambition behind Musopana
This is the problem that interests us at Musopana. We want people to be able to choose devices that suit their lives while retaining a useful connection with their health history.
“Your health, beyond any one device” expresses that direction. It also gives us a demanding standard against which to judge our work. Bringing information together is only useful if its origin and limitations remain understandable, and if the result helps someone explore questions relevant to their own goals.
Fitness and workout planning are an early application of that broader ambition. They provide concrete situations in which information, personal goals, and the constraints of everyday life meet. The vision extends beyond those situations, but describing the vision should not imply that Musopana already supports every device or has resolved the differences between them.
The work by platform developers and researchers provides foundations to build on, as well as reasons to be careful. An additional application earns its place by making that existing information more useful and understandable.
When someone considers a new device, they should be able to focus on whether it suits them. Preserving the history they value—and understanding where the new measurements differ—should be part of the experience they can expect.
References
- Apple. Apple Watch and iPhone compatibility. Apple Support. Published September 24, 2025. Read source. ↩
- Apple. Share your data in Health on iPad. iPad User Guide. Sections “Share health and fitness data with apps and devices” and “Share your health and fitness data in XML format.” Read source. ↩
- Jamieson A, Jones S, Chaturvedi N, Hughes AD, Orini M. Accuracy of smartwatches for the remote assessment of exercise capacity. Scientific Reports. 2024;14:22994. doi:10.1038/s41598-024-74140-x. Read paper. ↩
- Google. Health Connect data type format. Android Developers. Section “Metadata attributes.” Updated January 19, 2026. Read source. ↩
- Google. Read raw data. Android Developers. Sections “Read previously written data” and “Read data older than 30 days.” Updated September 8, 2026. Read source. ↩