You bought a smartwatch. Within a week, you stopped checking the watch face. The dashboard, the streaks, the weekly chart — all of that lives on the phone.
That phone app is called a companion app, and it's the most underrated piece of any fitness wearable product. The watch captures. The phone interprets, stores, and visualizes.
This post is a code-first walkthrough of how to build one in React Native. We'll cover the architecture, HealthKit (iOS), Health Connect (Android), an optional Apple Watch bridge, and the sync model that doesn't fall over in production.
TL;DR for the impatient:
- Read from
HealthKiton iOS andHealth Connecton Android — you cover 90% of wearables without writing firmware. - Use
react-native-healthandreact-native-health-connect. - Make your backend
POST /samplesidempotent on the HealthKit UUID. This single rule prevents most sync bugs. - The dashboard UI is the time sink, not the integration. Plan accordingly.
The Architecture (Internalize This Before Writing Code)
[Wearable] → [OS Health Store] → [React Native bridge]
→ [Local DB (SQLite / WatermelonDB)]
→ [Sync queue] → [Backend]
→ [Other devices / Web dashboard]
Three things to internalize:
- The OS health store is the source of truth for samples, not your app. If the user reinstalls, HealthKit still has the data. Your local DB is a cache for fast UI plus a write buffer for user-generated samples.
- Reads are one-directional, writes are bidirectional. Reads pull from HealthKit/Health Connect. Writes hit both the OS store and your backend.
- Background delivery is a constraint, not a feature. iOS will throttle aggressively. Design as if your app wakes every 15–30 minutes, not every second.
Pick Your Wearable Target First
The biggest mistake I see: shipping for "wearables" generically. Each platform has a different data model and review hurdle.
| Wearable | Data path | Library | Watch-side code? |
|---|---|---|---|
| Apple Watch | HealthKit | react-native-health |
Only for watchOS UI |
| Pixel / Galaxy Watch | Health Connect | react-native-health-connect |
Only for Wear OS tile |
| Fitbit | Health Connect / Web API |
react-native-health-connect + OAuth |
No |
| Garmin | Garmin Health API | OAuth + REST | Optional (Connect IQ) |
| Whoop / Oura / Polar | Vendor REST APIs | OAuth + REST | No |
| Custom BLE hardware | Direct BLE | react-native-ble-plx |
N/A |
For most consumer apps, start with HealthKit + Health Connect. They cover every major retail wearable, the user already trusts the permission dialog, and you skip juggling six OAuth flows. Vendor SDKs are a v2 problem.
Step 1 — Scaffold the Expo Project
You need a custom dev client since both health libraries are native modules.
npx create-expo-app fitness-companion --template
cd fitness-companion
npx expo install expo-dev-client
npm install react-native-health react-native-health-connect
npx expo prebuild
In app.json:
{
"expo": {
"ios": {
"infoPlist": {
"NSHealthShareUsageDescription": "Read your activity to power your dashboard.",
"NSHealthUpdateUsageDescription": "Save workouts you log in the app."
},
"entitlements": {
"com.apple.developer.healthkit": true
}
},
"android": {
"permissions": [
"android.permission.health.READ_STEPS",
"android.permission.health.READ_HEART_RATE",
"android.permission.health.READ_SLEEP",
"android.permission.health.READ_EXERCISE"
]
}
}
}
Step 2 — Read Health Data on iOS (HealthKit)
import AppleHealthKit, { HealthKitPermissions } from 'react-native-health';
const permissions: HealthKitPermissions = {
permissions: {
read: [
AppleHealthKit.Constants.Permissions.Steps,
AppleHealthKit.Constants.Permissions.HeartRate,
AppleHealthKit.Constants.Permissions.SleepAnalysis,
AppleHealthKit.Constants.Permissions.Workout,
AppleHealthKit.Constants.Permissions.ActiveEnergyBurned,
],
write: [AppleHealthKit.Constants.Permissions.Workout],
},
};
AppleHealthKit.initHealthKit(permissions, (err) => {
if (err) console.error('HealthKit init failed', err);
});
Fetch today's step count:
const startOfDay = new Date();
startOfDay.setHours(0, 0, 0, 0);
AppleHealthKit.getStepCount(
{ date: startOfDay.toISOString() },
(err, results) => {
if (err) return;
setSteps(results.value);
}
);
Three production gotchas
-
Aggregated queries can double-count. If the user has both an Apple Watch and a third-party app writing steps, the default aggregate may count both. Use
getSampleswith explicit source filtering when accuracy matters. -
iOS won't tell you if read permission was denied.
getStepCountjust silently returns zero. Render an empty state, not an error. -
enableBackgroundDeliveryneedsHKObserverQuery. Budget half a day to wire it up properly the first time.
Step 3 — Read Health Data on Android (Health Connect)
Health Connect replaced the Google Fit dev API in 2025. Pixel Watch and Galaxy Watch already write to it.
import {
initialize,
requestPermission,
readRecords,
} from 'react-native-health-connect';
await initialize();
await requestPermission([
{ accessType: 'read', recordType: 'Steps' },
{ accessType: 'read', recordType: 'HeartRate' },
{ accessType: 'read', recordType: 'SleepSession' },
{ accessType: 'read', recordType: 'ExerciseSession' },
]);
const result = await readRecords('Steps', {
timeRangeFilter: {
operator: 'between',
startTime: startOfDay.toISOString(),
endTime: new Date().toISOString(),
},
});
const totalSteps = result.records.reduce((sum, r) => sum + r.count, 0);
Health Connect's permission UX is cleaner than HealthKit's (one consolidated screen), but you can only read the past 30 days unless the user explicitly grants extended history access.
Step 4 — Apple Watch Bridge (Optional)
If you want a watchOS app — say, a quick-start workout button — you need a watchOS target in Xcode bridged to RN via WCSession. The watch app itself is Swift (RN doesn't run on watchOS).
Minimal Swift bridge:
class WatchBridge: NSObject, WCSessionDelegate, RCTBridgeModule {
static func moduleName() -> String! { "WatchBridge" }
func session(_ session: WCSession,
didReceiveMessage message: [String : Any]) {
if let event = message["event"] as? String, event == "workoutSample" {
RCTBridge.current()?.eventDispatcher().sendAppEvent(
withName: "WatchWorkoutSample", body: message
)
}
}
}
On the RN side, subscribe with NativeEventEmitter and update your store. A reasonable v1 scope: start/end workout from the watch face, with samples flowing back live. Anything more (full watch UI, complications) is multi-week work.
For Wear OS, the equivalent is the Data Layer API with MessageClient. Same pattern: native module, JS bridge, event emitter.
Step 5 — The Dashboard UI (Where Time Actually Goes)
Data flows. Now you need the actual app. Standard companion-app screens:
- Today — steps, heart-rate ring, active calories, latest workout
- Trends — weekly/monthly bar charts
-
Workouts — list of
ExerciseSession/Workoutrecords with detail view - Goals — editable daily targets, local + synced
- Settings — permissions, units, connected devices
Stack I'd recommend:
-
Charts:
victory-native(maintained, gesture support, works on both platforms). Skipreact-native-svg-charts— unmaintained. - List: virtualize aggressively. Users routinely have thousands of historical workouts.
- State: Zustand or Redux Toolkit. Avoid Context for high-frequency updates from health observers.
Honest aside: this is the part of the build that's the least interesting and the most time-consuming. The integration code lands in week one. The dashboard eats the next two-to-three weeks if you write every screen by hand.
The third time I built one of these, I described the spec in plain English to an AI mobile app builder and got a full Expo project — components, navigation, theming — in under an hour, then plugged my HealthKit hooks into it. The tool I used was RapidNative, which generates real React Native + Expo code (not a proprietary runtime — you own the output). Worth a look if the dashboard is the part you'd rather not write by hand.
Step 6 — Sync, Offline, Conflicts
The pattern that survives production:
-
Local-first writes. WatermelonDB or
expo-sqlite. Every user-logged workout → local DB → HealthKit/Health Connect → upload queue. -
Pull-based reads from the health store. On app open and on background fetch (~30 min cadence on iOS), pull deltas since
last_sync_timestamp, dedupe by UUID, upsert. -
Idempotent uploads. Every HealthKit sample has a stable UUID. Make
POST /samplesa no-op on duplicate UUIDs:
// Backend pseudocode
async function ingestSample(sample) {
await db.samples.upsert({
where: { healthkit_uuid: sample.uuid },
update: { value: sample.value, modified_at: sample.endDate },
create: { ...sample, healthkit_uuid: sample.uuid },
});
}
This single rule prevents 90% of the sync bugs that haunt fitness apps.
- No cellular uploads by default. Gate behind a setting. Battery-sensitive users uninstall fast.
Edge case that bites everyone: a user edits a workout in the Apple Health app. HealthKit emits an "updated" sample with the same UUID but a new modification date. Your sync code must handle this — most don't, which is why so many fitness apps quietly drift out of sync.
Realistic Timeline
For a single full-stack dev who's shipped React Native before:
| Phase | Time |
|---|---|
| Setup, permissions, HealthKit + Health Connect reads | 3–5 days |
| Dashboard UI (5 screens, charts, theming) | 5–8 days |
| Local DB + backend sync | 4–6 days |
| Apple Watch companion (basic workout start/stop) | 5–7 days |
| Polish + App Store review prep | 5–10 days |
| v1 ship | 3–5 weeks |
The dashboard phase is the easiest to compress because it has nothing to do with wearables. Scaffolding it with an AI tool can take that week down to a day.
App Store Gotchas That Kill Submissions
-
PrivacyInfo.xcprivacyis mandatory for any iOS app touching HealthKit (since 2024). Missing it = auto-reject. - HealthKit data cannot be used for advertising or sold. Period.
- Health Connect requires a published privacy policy URL in your Play Store listing.
- You cannot transmit another user's HealthKit data. "Share with a friend" features need each recipient's own HealthKit permission grants.
FAQ
Can I use Expo for this?
Yes, with a custom dev client. npx expo prebuild then eas build --profile development. Expo Go won't work because of the native modules.
Do I have to ship a watchOS app to support Apple Watch?
No. The watch already writes to HealthKit. Read from HealthKit and you support every Apple Watch user without writing Swift. A watchOS app is only for on-wrist UI.
Google Fit vs Health Connect?
Health Connect replaced Google Fit's dev API in 2025. New apps should use react-native-health-connect.
Can React Native do live heart-rate streaming?
Not via HealthKit (samples arrive on a delay). For real-time streams, either a watchOS app over WCSession or a direct BLE connection via react-native-ble-plx.
Wrap-up
The integration work — HealthKit, Health Connect, WCSession — is irreducible. You write it yourself. The UI on top is boilerplate you've seen in fifty other apps, and it's where most of the calendar disappears.
Start with the system health stores. Make your sync endpoint idempotent. Don't ship a watchOS app until you've validated the phone experience.
If this was useful, drop a comment with what you're building — happy to dig into specific edge cases (sleep data is a rabbit hole, ask me how I know).
Cover photo by Onur Binay on Unsplash.
Top comments (0)