AppMatic Tech builds companion apps for wearables and smart accessories, handling Bluetooth Low Energy sensor pairing, offline-first data sync, and health data integration with Apple HealthKit, Android Health Connect, and the Google Health API, in Swift, Kotlin, and Flutter. AppMatic Tech is based in Ahmedabad, India, and has shipped six BLE device integrations.
Wearables are becoming sensor platforms. Many new trackers have no screen at all, so the phone app is where every reading, trend, and insight lives. That puts the companion app at the centre of the product, and 2026 has made it harder to get right: Google is retiring the Fitbit Web API and the Google Fit APIs, and hardware makers are opening their devices to third-party accessories that need companion apps of their own. This article explains what a wearable companion app has to handle, what changed this year, and what building one costs.
Key takeaways
The companion app, not the hardware, decides whether a wearable feels reliable.
| Point | Detail |
|---|---|
| The app is the product for screenless wearables | Pairing, readings, trends, and insights all live on the phone. |
| Two Google health APIs retire in 2026 | Fitbit's developer site deprecates the legacy Fitbit Web API in September 2026; Google Fit APIs are supported only until the end of 2026. |
| The replacements are split | Google recommends Health Connect for on-device Android data and the Google Health API for cloud integrations. |
| Sensor contact is an app problem too | Poor skin contact degrades optical readings, so the app must detect and flag low-quality data. |
| BLE reliability is designed, not assumed | Queued commands, reconnection, and background behaviour decide whether readings arrive. |
| Pricing follows device complexity | From $15,000 for a single-platform MVP to $100,000 for a full connected platform. |
What does a wearable companion app have to do?
A companion app does five jobs, and each one fails in its own way if it is treated as an afterthought.
| Layer | What it does | What goes wrong without it |
|---|---|---|
| Device connection | Pairs with the wearable over Bluetooth Low Energy and receives sensor data | Missed readings, failed pairing, battery drain from polling |
| Local storage and sync | Stores readings on the phone and syncs them to a backend when connected | Data lost when the phone is offline or the app is closed |
| Health platform integration | Shares data with Apple HealthKit or Android Health Connect, or reads data from them | The product is isolated from the health apps users already rely on |
| Insights and presentation | Turns raw readings into trends, scores, and plain-language explanations | Users see numbers without meaning and stop opening the app |
| Backend and firmware support | Stores history, manages accounts, and delivers firmware updates | No long-term history, no way to fix devices already in the field |
Screenless wearables raise the stakes on every layer. When the device has no display, the app is the only way a user experiences the product, so a pairing failure or a gap in the data reads as a broken device, not a broken app.
What changed for wearable apps in 2026?
Two Google platform changes affect any app that reads fitness or health data from Fitbit, Pixel, or Google Fit.
| Change | What happens | What to do |
|---|---|---|
| Legacy Fitbit Web API | Fitbit's developer site states it is being deprecated in September 2026 and that apps need to migrate | Move cloud integrations to the Google Health API, the Fitbit Web API rebuilt on Google infrastructure with Google OAuth 2.0 |
| Google Fit APIs | Google's Android documentation states they are supported only until the end of 2026 | Move mobile-first Android reading to Health Connect, and cloud reading to the Google Health API |
Google's own migration guidance splits the replacement by app type: Health Connect for mobile-first apps reading aggregated on-device data such as steps, the Google Health API for fitness tracker companion apps and web platforms that need OAuth-based cloud access, and both for broader health and fitness platforms.
Because the Google Health API authenticates with Google OAuth 2.0 rather than Fitbit's original sign-in, apps should plan for users to reconnect their accounts during migration, and should build that reconnection prompt into the app rather than relying on users to notice broken syncing.
Pro tip: Audit every place the app or its backend reads Fitbit or Google Fit data before choosing a migration path. Teams often find a forgotten server job or analytics export still calling the old API, and those are the integrations that fail silently after the cutoff.
How should a wearable connect over Bluetooth Low Energy?
Almost every wearable talks to its phone over Bluetooth Low Energy. The connection is where most companion app reliability is won or lost.
Some device types can use standard Bluetooth profiles, such as the Heart Rate Profile, which any compatible app can read. Most wearables use proprietary profiles instead, which means the app must implement the manufacturer's protocol exactly, and the schedule depends on how complete that protocol documentation is.
AppMatic Tech applies the same rules across every BLE build:
- Queue every operation. Firing reads and writes concurrently drops packets; on Android it commonly surfaces as GATT error 133. Each operation waits for acknowledgement before the next.
- Treat disconnection as normal. Users walk away from their phones, and wearables sleep to save battery. Reconnection belongs in the connection logic from day one.
- Subscribe instead of polling. Notifications deliver new readings without draining battery on either side.
- Design for the background. iOS and Android restrict background Bluetooth differently, so readings captured while the app is closed need platform-specific handling.
- Store before sending. Every reading is written to the phone first and synced later, so nothing is lost when the network drops.
The full failure-mode breakdown, drawn from six shipped integrations, is in BLE mobile app development: cost and timeline, and the choice between BLE, Wi-Fi, and MQTT is covered in BLE vs Wi-Fi vs MQTT.
Why is sensor contact a companion app problem?
Optical heart rate and blood oxygen sensors only work when they sit flat and steady against the skin. That sounds like a hardware concern, but the consequences land in the app.
Google's accessory guidelines for the Fitbit Air, published in June 2026 alongside CAD drawings for third-party band makers, make the point concrete: bands must keep the optical sensors unobstructed and maintain at least 35 mmHg of contact pressure during normal wear. A band that lets the sensor lift or shift produces readings that look like data but are not reliable.
For a companion app, that means:
- Detect low-quality signal and mark readings as unreliable instead of charting them as real.
- Tell the user why, in plain language, such as "tighten the band for accurate heart rate," rather than showing a gap or a spike.
- Exclude flagged readings from trends, scores, and anything shared with health platforms.
Third-party apps that read Fitbit Air data, rather than make bands for it, go through the Google Health API, as covered in Fitbit Air app development. The same logic applies to any accessory that carries sensors. The app, not the band, is where bad data is caught before it reaches the user or a clinician.
Should a companion app share data with HealthKit and Health Connect?
Usually, yes. Apple HealthKit on iOS and Health Connect on Android are where users expect their health data to live, and a wearable that does not participate feels isolated.
- Writing data to HealthKit or Health Connect lets users see their wearable's readings alongside other apps, with their permission.
- Reading data from them lets the companion app enrich its insights, for example combining the wearable's heart rate with steps recorded by the phone.
- Permissions are granular, per data type, and the app must work gracefully when a user declines some of them.
Medical-grade products need more care. When readings feed clinical decisions, the data pipeline, audit trail, and any FDA or regional regulatory classification shape the architecture, as covered in remote patient monitoring app architecture. As a healthcare app development company, AppMatic Tech defines HIPAA-aware storage, audit logging, and EHR integration for medical-grade wearables in week one, before development begins.
Pro tip: Decide early which platform is the source of truth. If the companion app writes to Health Connect and also reads from it, it must avoid counting its own data twice, which is a common and very visible bug in step and heart rate totals.
What does a wearable companion app cost?
AppMatic Tech prices wearable companion apps at a fixed scope, based on the number of platforms, the device protocol, and the backend required.
| Engagement | Scope | Timeline | Investment |
|---|---|---|---|
| BLE companion MVP | Pairing, sensor reads, core screens, one platform | 4 to 6 weeks | From $15,000 |
| Dual-platform device app | iOS and Android, read and write commands, backend sync | 8 to 12 weeks | $30,000 to $60,000 |
| Connected device platform | Apps, backend, real-time telemetry, admin dashboard, analytics | 12 to 20 weeks | $60,000 to $100,000 |
The biggest cost variable is on the hardware side: a documented, stable device protocol integrates in weeks, while an undocumented or still-changing protocol adds months. Health platform integration and a Google Health API migration are scoped as additions to whichever tier fits the device.
How AppMatic Tech builds wearable companion apps
AppMatic Tech has shipped 330+ products since 2017 with an 83% client retention rate and a 5.0 Clutch rating, including six BLE device integrations across medical, consumer, and vehicle hardware:
- EYVA: a non-invasive wellness device measuring six vitals. AppMatic Tech took the app over mid-development from a stalled vendor, stabilised the inherited codebase, completed BLE read and write integration, and shipped the iOS and Android MVP in eight months.
- Trackwel: a connected kitchen scale with a Flutter companion app and a custom BLE integration layer, shipped in ten weeks with zero app-side BLE errors.
- Capmedic: a medical spirometry device with a native Android app deployed at Northwestern Medicine.
For wearable and sensor products, see AppMatic Tech's wearable and IoT practice, the use-case breakdowns for IoT apps for wearable health sensors and Flutter fitness wearable companion apps, and IoT application development. For products that already have a companion app and need intelligence added on top, see how to add AI to an app your vendor built.
The full service overview, device platforms, and shipped BLE work are on the AppMatic Tech wearable app development page.
Contact AppMatic Tech at contact@appmatictech.com to scope a wearable companion app or a Google Health API migration.
Related wearable guides from AppMatic Tech: HealthKit vs Health Connect vs Google Health API, BLE background sync for wearables on iOS and Android, Fitbit Air app development with the Google Health API, the WHOOP API integration guide, how to build a screenless fitness tracker app, wearable health data APIs compared, when a wearable app becomes a medical device, and smart ring app development. Regional guides cover India and Saudi Arabia and the UAE.
Sources
| Claim used in this article | Source |
|---|---|
| Legacy Fitbit Web API deprecated in September 2026; apps need to migrate | Fitbit developer site |
| Google Health API is the Fitbit Web API rebuilt on Google infrastructure, using Google OAuth 2.0 | Google Health API |
| Google Fit APIs supported until the end of 2026; Health Connect and Google Health API recommended by app type | Android Developers, Google Fit migration guide |
| Fitbit Air accessory CAD drawings and 35 mmHg minimum contact pressure guideline | 9to5Google, Fitbit Air blueprints |
| BLE failure modes, six shipped integrations, and pricing tiers | BLE mobile app development: cost and timeline |
| EYVA takeover and eight-month delivery | EYVA case study |
Frequently Asked Questions
- What is a wearable companion app?
- A wearable companion app is the mobile app that pairs with a wearable or smart accessory over Bluetooth Low Energy, collects its sensor data, stores and syncs it reliably, turns it into readable insights, and optionally shares it with Apple HealthKit or Android Health Connect. For screenless trackers, the companion app is the entire user experience. AppMatic Tech builds these apps in Swift, Kotlin, and Flutter.
- Is the Fitbit Web API being shut down?
- Yes. Fitbit's developer site states that the legacy Fitbit Web API is being deprecated in September 2026 and that apps need to migrate. Cloud access to Fitbit and Google device data moves to the Google Health API, which uses Google OAuth 2.0. Separately, Google's Android documentation states the Google Fit APIs are supported only until the end of 2026.
- Should a wearable app use Health Connect or the Google Health API?
- It depends on where the data is read. Google recommends Health Connect for mobile-first Android apps reading aggregated on-device data such as steps, and the Google Health API for cloud-based integrations and fitness tracker companion platforms that read Fitbit or Google device data through a server with OAuth. Health and fitness platforms often need both.
- Can a companion app read data from another brand's tracker, such as a Fitbit?
- Only through the brand's sanctioned platform, not by connecting to the tracker directly. Fitbit and Google device data is available through the Google Health API with the user's consent, and many devices share data into Apple HealthKit or Android Health Connect, where an app can read it with permission. AppMatic Tech designs companion apps around these platforms rather than unsupported direct access.
- How much does a wearable companion app cost?
- AppMatic Tech prices BLE companion apps in three tiers: a companion MVP with pairing, sensor reads, and core screens on one platform from $15,000 in 4 to 6 weeks, a dual-platform iOS and Android app with read and write commands and backend sync at $30,000 to $60,000 in 8 to 12 weeks, and a full connected device platform with telemetry, admin dashboard, and analytics at $60,000 to $100,000 in 12 to 20 weeks.