Visit Monitoring in iOS
June 4, 2020, 3 min to read
Visit monitoring requires the Always authorization for location. The service is not available when When In Use is requested. You can find all the location services and their needed authorizations here.
Visit monitoring is meant to be used in background. Like the other background services, it will continue to run even when the app is suspended, and will launch the app in the background to deliver events. Make sure to enable Location Updates in the application background modes capabilities and to set allowsBackgroundLocationUpdates to true for the location manager.
Start monitoring visits
The use is really straightforward, as for other location services.
First create your CLLocationManager and call the method startMonitoringVisits(). If the service is authorized and running, you will receive callbacks on the delegate method locationManager(_:didVisit:).
Here is a skeleton of implementation of such a feature.
The service runs in background and you have no idea when the system will choose to trigger a visit update. That’s why it’s difficult to debug it.
Something you can do to help debug the application is to trigger a local notification on the device every time the device logs a new visit. That way, when using your device in your daily life, you’ll be able to know precisely when and where the visits occur.
Pros and cons
- The major feature of visit monitoring is to be able to receive user locations with a very minimal impact on battery life. Apple even describes this service as the most power-efficient way of gathering location data. The goal here is not to be very accurate about the user trace, but to be able to retrieve context from a user location.
- Apple uses sophisticated algorithms to monitor for places that the user might consider a noteworthy part of their day. For instance the property pausesLocationUpdatesAutomatically automatically pauses the service if the user is unlikely to move. That means the framework learns from your habits and trigger events accordingly.
- Some visits returned by the system are incomplete and the documentation is misleading. The documentation states that Visit objects contain as much information about the visit as possible but may not always include both the arrival and departure times.
In Swift, though, the visit class contains non optional arrivalDate and departureDate, as we could have expected. These two properties rather contain invalid data (like distantPast or distantFuture):
That means you can’t trust the visit dates and have to discard invalid visits if you rely on both arrival and departure dates.
- What’s more, the precision of the visit, described in the property horizontalAccuracy in meters, is not very precise. The center of the visit (described as the coordinate property) may not be the exact location where you were during the visit. That means you should not rely on the coordinate property to track the precise location of the user.
- Another issue about precision is that you can’t know the elevation of the user. That means you may have a single event when the user visits a building, although he may have been in very different levels for different purposes.
Visit monitoring is a powerful service that should be considered as an alternative to Significant-change monitoring in some cases. Its minimal impact on battery life makes it perfect to use in situations where you just need to get context from a noteworthy place: restaurant, gym, home, work, etc.
In our use case we wanted to match locations of multiple users during the same period of time. But as we have seen previously, arrival and departure dates are not always present and the location is not precise. So visit monitoring is not well suited for this situation.