Background GPS tracking challenges and approaches

WHAT THIS TESTS Whether you understand that JavaScript does not run freely in the background and that location tracking must hook into native background execution with the right permissions and battery discipline.

A GOOD ANSWER COVERS The central challenge is that when the app is backgrounded, the OS suspends or throttles the JS thread, so a JS timer or a foreground watchPosition stops firing. You need the elevated always-allow location permission, not just while-in-use, and you must declare background location capability, the location background mode on iOS and a foreground service with the appropriate permissions on Android. The general approach is to delegate tracking to native code: Expo offers a background location task registered with TaskManager that the OS invokes natively, and bare apps often use react-native-background-geolocation, which runs a native service, batches and persists fixes, and syncs them to your server. You must manage battery drain by tuning accuracy, distance filters, and update intervals, and on Android show a persistent foreground-service notification so the OS does not kill it. You also handle the OS killing or relaunching the process.

COMMON WRONG ANSWERS Using setInterval or watchPosition and assuming it keeps running when backgrounded. Requesting only while-in-use permission. Forgetting the background mode declarations, so the app is suspended. Polling at maximum accuracy continuously, draining the battery. Not persisting fixes, so points are lost if the app is killed.

LIKELY FOLLOW-UPS What is the difference between while-in-use and always permission, why does Android need a foreground service, how do you batch and upload points efficiently, and how do significant-change or geofencing APIs reduce battery use.

ONE CONCRETE EXAMPLE A running app registers a background location task with Expo TaskManager after getting always-allow permission and declaring the iOS location background mode. The native side wakes the task on movement, appends each fix to local storage, and periodically uploads the batch. On Android a persistent notification keeps the foreground service alive so the OS does not terminate tracking mid-run, and the distance filter is set so fixes come every few meters rather than every fraction of a second.