A detailed engineering writeup describes building a resilient walking-activity tracker in Expo/React Native that survives app kills, backgrounding, and GPS noise. The team uses Expo TaskManager to run background GPS tracking outside the React lifecycle, applies a multi-gate Kalman filter pipeline (accuracy, speed, outlier, and Doppler-speed integration) to eliminate vehicle-distance inflation, and layers persistence across Zustand, AsyncStorage, and Supabase with monotonic merge logic to avoid write races between the background task and foreground store. It covers Android OEM battery-killer mitigations, iOS background location edge cases since iOS 16.4, a custom Kotlin Expo Module for Android step counting via STEP_COUNTER, and a three-way recovery status (found/not-found/unreachable) to safely resume sessions after crashes or offline relaunches.
Table of contents
The challenge: tracking activity on mobileThe goal: an unkillable sessionThree layers of persistenceRecovery on relaunchCross-platform step trackingResultsWhere this can still failWhy this matters for ExpoQuestions this post answers
How do I prevent an Android foreground service from being killed when the user swipes away the app?
Set killServiceOnDestroy to false in the foregroundService config passed to Location.startLocationUpdatesAsync from expo-location. Without this flag, the foreground service notification appears to keep the app alive, but the service silently stops running as soon as the user swipes the app away from the recent apps switcher, ending background GPS updates without warning. daily.dev surfaces implementation details like this for developers wiring up reliable background location tracking.
Why does setting a distanceInterval on Android location updates make GPS tracking worse instead of better?
On Android, distanceInterval filters the location provider itself rather than just hinting at desired granularity, so a value like 10 meters can drop the sample rate three to four times, exactly when the screen is off and GPS fixes are already coarsest. Since distance is integrated over time rather than summed between points, a steady update cadence produces better accuracy than trying to cull near-duplicate points. Developers debugging flaky mobile GPS accuracy issues can find these configuration gotchas on daily.dev.
Why does summing distance between consecutive GPS points overestimate walking distance even after filtering?
Summing the distance between consecutive accepted GPS fixes carries an inherent positive bias because absolute position difference is a norm that is never negative, so residual filter wobble keeps accumulating like a random walk's path length even when net displacement stays near zero. Integrating speed over time instead, with a minimum-speed deadband and a maximum-speed ceiling, avoids this drift. daily.dev helps mobile developers compare distance-calculation approaches when tuning fitness-tracking accuracy.