Happy to announce that version 2.2.5 of LocationKit for iOS has been released!
Run pod update or download the latest version of the framework here.
This was mainly a bugfix release. Below I’ve put way more details into some of the highlights.
Lower battery drain for Custom Operation Modes
LocationKit has its default operating mode which we informally call “best for venue detection” which couples the highest accuracy venue detection with the lowest battery drain always-on background location that we can pull together.
In simpler terms, this mode will do the best job of detecting when your user visits a place while keeping battery drain to a minimum.
We accomplish this by using some location intelligence paired with the other sensors on the device (accelerometer, magnetometer, gyroscope, altimeter, whether or not the device is connected to wifi, and more) to intelligently throttle the GPS and keep battery drain low while the device is sitting on a table but accuracy high while the user is walking out in the world.
However, being a general location toolkit, this isn’t the best mode for all use cases of LocationKit so we provide a super easy way for developers to override our default behavior with what we call Custom Operation Modes which pair nicely with our Activity Modes feature. This pairing allows developers to explicitly say “I want the GPS on high while the user is driving” or “I want the GPS on low while the user is walking” and LocationKit is happy to oblige.
Previously, we allowed developers to alter those GPS settings, but internally we throttled the other sensors on and off according to our internal state machine regardless of the custom operation mode the developer chose.
In the 2.2.5 release, we altered the behavior so, rather than turning the accelerometer, magnetometer, gyroscope, and altimeter on our schedule and ignoring the developer request, if the developer has requested a custom operation mode, we turn those other sensors off. The end result is that apps using custom operation modes should see lower battery drain.
Fixed some stale places
One of LocationKit’s core features is its ability to automatically detect when a user starts a visit at a location and when they leave. We make these available to developers in the LocationKitDelegate methods didStartVisit and didEndVisit.
In the past, when a developer called getCurrentPlaceWithHandler, we fired up the GPS, retrieved the latest latitude/longitude of the device, sent it to our server, resolved it, and returned information about the place represented by that latitude/longitude. This meant the place we sent back was always current.
GPS accuracy while indoors is generally quite poor so there was a tendency to report a different place from getCurrentPlaceWithHandler than we did from didStartVisit and developers found that very confusing.
Part of how we are able to get such high accuracy with LocationKit is that, by constantly monitoring the location of the user, we can determine while they’re outdoors and they have a good GPS signal, which place they’ve entered. Then while they’re indoors and the GPS signal is poor, we already know where they are and can provide best of breed venue information.
But by using the momentary GPS coordinate for getCurrentPlaceWithHandler, we were using some of that potentially inaccurate GPS information to retrieve information on the user’s current place.
So, back in LocationKit 2.2.2 we made a change to return the place matching the currently in progress visit if you called getCurrentPlaceWithHandler and a visit was ongoing, even if the GPS signal seemed to indicate that the device was in another location. This made things more consistent and helped with the GPS drift, but could yield inaccurate or stale results.
This is because it takes us a decent amount of time to recognize, with certainty, that the user has left the place (in summary, GPS signal drifts, particularly when it is attenuated such as when you’re indoors so we must gather enough data that seems to indicate that you’ve left before we confirm it) so a call to getCurrentPlaceWithHandler could sometimes return a stale result when the user had left the building.
Based on developer feedback, we have rolled back this change to the pre 2.2.2 behavior, so we’ll use the device’s location at any given moment to determine the current place, avoiding this issue of sometimes returning a stale result, pending a better solution.
Widen radius of the getPeopleNearby call
Another of our features which has been getting more adoption lately is the getPeopleNearby call in LocationKit which will quickly deliver other users of your app near the device which makes the call.
However, based on feedback from developers, we decided to widen the radius for which users are included in the “nearby” users. For apps that depend on finding users nearby, developers suggested it was better to return a greater number of users in the area than to miss users nearby and we agreed.
Re-enable “Burst Mode”
One of the many things we do to refine user location in LocationKit is determine when we think a visit has started (based on a weighting function including factors such as the GPS signal dropping due to attenuation from a building, connecting to a wifi network, reduction in movement by looking at accelerometer data, a sharp turn preceding said drop in signal, duration in a location, and a whole lot more).
Once we think that a visit has started, we enable what we refer to internally as “burst mode” where we crank the GPS up to high and gather data for a short period of time to more accurately determine which venue a user has truly entered.
In 2.2.4, we had a bug which prevented us from entering this “burst mode” which resulted in slightly lower accuracy for determining venue visits. This has been fixed in this 2.2.5 release.
There are a handful of less noteworthy other bugfixes which were included in this release as well.
We are constantly cranking and iterating on LocationKit to enable developers to create ever more powerful location-based interactions.
For our next release, we are working hard to add functionality for providing calls to our LocationKitDelegate not only when a user enters a venue, but when a user is in proximity to a venue. In a more traditional location service, this is often referred to as a “geofence” but our technology will make these kinds of interactions much more seamless, easier to provide, and with higher accuracy.
Traditional geofences have a basic problem in that they define a radius around a point and alert when a user enters the specified radius around a point. In the past, for a developers to deliver a feature like this, they had to manually upload thousands of latitude/longitude points and then try to define radii around those points for alerting users.
Not only is it a monster pain to upload/manage all of these points, but they’re often flawed due to the fact that buildings are different sizes and shapes.
For instance, say you want to pop up an alert when a user gets within 50 meters of a Papa John’s to let them know they’re only 50 meters from a delicious slice. Your developers can upload thousands of latitude/longitude points representing every Papa John’s franchise in the US, but if you take the naive approach and simply create a 50 meter radius around each of those points and alert only when users enter them, you’ll miss a ton of potential hits.
What about cases where the restaurant is in a baseball stadium or strip mall or shopping mall or airport (and the 50 meter radius doesn’t even go outside the bounds of those places)? Well unless your user is visiting the larger place and happens to be passing by, you’re going to miss them.
Our approach we think makes a lot more sense.
(1) From a management perspective, because rather than uploading and managing thousands of points with radii, a developer only needs to input a venue name or category, for instance “Papa John’s” or “Pizza” and we’ll handle all the rest of the heavy lifting.
(2) Since our proprietary venue and address database includes polygons with the outlines of the venues and addresses, we are able to take the outline of the actual parcel of land or building for the venue and increase each boundary by the supplied radius to arrive at the “proximity” so our solution automatically scales with the size of the actual address or building in which the venue of interest resides. Now we can deliver the “within 50 meters” functionality to a far greater degree of accuracy, automatically scaling based on the size of the containing building or land parcel so your users won’t miss triggers if a venue happens to be in a big building or on a large land parcel.
This functionality is coming soon, stay tuned for more details!