react-native-background-geolocation: [iOS] App is not receiving location updates after its killed
Your Environment
- Plugin version:3.6.2
- Platform: iOS
- OS version: 13.5.1
- Device manufacturer / model: iPhone
- React Native version (
react-native -v):3.2.1 - Plugin config
// Geolocation Config
desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_MEDIUM,
distanceFilter: 50,
stationaryRadius: 100,
// Activity Recognition
stopTimeout: 1,
// Application config
debug: false, // <-- enable this hear sounds for background-geolocation life-cycle.
logLevel: BackgroundGeolocation.LOG_LEVEL_OFF,
stopOnTerminate: false, // <-- Allow the background-service to continue tracking when user closes the app.
startOnBoot: false, // <-- Auto start tracking when device is powered-up.
// HTTP / SQLite config
url: 'some url',
locationTemplate: `some location template`
extras: {
uid: uid,
},
headers: {
//Some header
},
batchSync: true, // <-- [Default: false] Set true to sync locations to server in a single HTTP request.
autoSync: true, // <-- [Default: true] Set true to sync each location to server as it arrives.
autoSyncThreshold: 5, // Tied with autoSync
persistMode: BackgroundGeolocation.PERSIST_MODE_LOCATION,
//AuthorizationAlert is displayed even if location is ON but not set to "Always"
disableLocationAuthorizationAlert: true,
Expected Behavior
When app is killed by user (app not running in the background), location is tracked (sent to server)
Actual Behavior
When app is on foreground or running in background, location is tracked as expected. When app is killed by user app(not running in the background), location is not tracked (not sent to server)
Steps to Reproduce
- Kill the app (released to users on TestFlight) 2.Start moving (or simulate location by Xcode debugger) more than 1km 3.Notice that location is not tracked and sent to server
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 28 (17 by maintainers)
@mikehardy not true, I think you’re talking about background-fetch, this is background-geolocation.
@rajkumarwaghmare see wiki “Debugging”, set debug: true and test this in the simulator with Freeway Drive.
I’ve testing this nearly every day on my devices for ~6 years. It rarely fails and if it does, it’s due to device settings (eg WiFi disabled, location-services Config) or the environment (rural vs urban environment).
This has been asked and answered in the issues a lot if you search, but the thing is on iOS if you force-close an app (kill it, swipe it away, however you want to describe that), your app is now dead dead. It’s not coming back till the user opens it. It’s a platform limitation.
oh my goodness! You are right, sorry about the misinformation @rajkumarwaghmare - the motion activity API will bring the app back to life on iOS. It was fetch I was thinking about - background fetch stops completely when you force close.
Have a read of the api docs Config.stopOnTerminate.
The sdk is using published, public iOS
CoreLocationapis that are purposely designed by Apple engineers to do exactly what they’re designed to do.This sdk is not a hack of iOS apis. It does the same things that any native app is capable of.
Of course, your app is still subject to Apple’s review process — if Apple feels your app doesn’t deserve to use the Background Location capability checkbox in XCode, they could tell you that and reject your app. That would have nothing specifically to do with this sdk,
Some people try to use this sdk to make an Alarm Clock app, using background location capability to keep an app running in the background to run a timer: of course Apple would reject that app.
Still on the first cup of coffee and already learning stuff 🤣 - thanks 😄
This goes a long way to me understanding the tracks and events I see in my own app, which is comforting btw. Not strictly necessary but tells me sort of the edges of the space I’m in, where to push, where to not waste time even thinking about optimizing behavior etc
Also, your app must call
#readyno matter what, each time your app launches.