iOS 13 and Android Q Support
Android Q and iOS 13 support is available now for the Background Geolocation SDK:
- React Native: v3.2.0
- Cordova/Ionic: v3.2.0
- Flutter: v1.2.0
- Pure Native: v1.0.0
iOS 13
iOS 13 introduces a radical new change to location authorization. No longer will apps be able to immediately request “Always” authorization.
Below is the new initial location authorization dialog presented by iOS 13— notice there’s no more “Allow Always” button:
When the user grants the most positive option on the dialog above, “Allow While Using App”, your app will be granted what’s called “Provisional Always Authorization” . This means that your application actually believes it’s been granted Always authorization.
Now imagine a user who has clicked “Allow While Using App” on the dialog above, puts her phone into her pocket and starts driving to work. Normally, the BackgroundGeolocation SDK would automatically initiate tracking after the device moves about 200 meters.
However, with iOS 13, the user must now explicitly authorize an upgrade to “Always” before background location-tracking will occur, via a second dialog presented by iOS, which the user won’t see until the next time they unlock their device.
For the imaginary user driving to work, she won’t see the following dialog until she next unlocks her phone, presumably after she’s arrived at her destination. Her entire drive to work will have been lost:
Assuming she authorizes the transition to “Full Always” by clicking “Change to Always Allow”, the Background Geolocation SDK will now operate in the traditional manner, automatically initiating tracking in the background when the device moves about 200 meters, just like iOS 12.
This, of course, means you’re probably going to miss initial tracking events until the “provisional always” authorization has been upgraded to “full always” authorization. Here’s a video of the full interaction:
Furthermore, iOS 13 will now periodically warn the user of those apps found tracking their location in the background, along with a map summary and strongly prompting them to “Change to Only While Using”. You will want to write a very good LocationAlwaysAndWhenInUseUsageDescription
to promote clicking the “Always Allow” button:
However, if you can manage to coax the user to manually select “Always” authorization via navigating to Settings->Privacy->Location Services->Your App, then everything operates in the traditional manner.
For more information about these changes in iOS 13, see this video from WWDC 2019 “What’s new in CoreLocation”
Android Q
With version Q, Android now follows the pattern established by Apple back in iOS 11, requiring the location authorization dialog to offer both “Allow all the time” and “Allow only while using the app”:
In addition, the Android Motion API now requires run time permission from the user for “Physical activity”.
See here for more information about location authorization changes in Android Q.
These new changes introduced by iOS 13 and Android Q give the user more awareness and control over how their location is used by applications. Application developers are going to scream “My users are getting scared and deleting my app!”, but everyone is in the same boat, even popular apps such as Life 360:
It will be important for application developers to clearly state exactly why you require the device location and how that helps them help you, perhaps by presenting the user with your own custom dialog before you #start
the SDK, stating something like “We’re about to request permission for location and physical activity — we require this for features X, Y and Z”.