iOS Significant Location Change (SLC) in iOS 7.0 and 7.1

iOS Significant Location Change (SLC) in iOS 7.0 and 7.1 Matt is product manager at Wandera, focusing on mobility and enterprise integrations. He has personally written multiple iOS apps for enterprises and consumers alike, delivering capabilities that range from mobile content collaboration to enhancing smart home thermostats. With other technical expertise in MDM, networking, security, and VoIP, Matt helps manage Wandera’s mobile initiatives in a holistic, full-stack manner. Prior to working with Wandera, Matt worked at Unwired Revolution, a boutique mobility integrator and consultancy that focuses on assisting medium-to-large enterprises with the design, deployment, and management of large-scale mobile initiatives.

Since the introduction of iOS 4.0, in which multitasking was first introduced to the platform, Apple included a feature known as Significant Location Change (SLC) that would allow the OS to ‘wake-up’ a suspended or killed app to notify it that the device has physically move a ‘significant distance’. When woken up, the app would be allowed to run for a minimal amount of time in the background to perform whatever location-oriented task it has to do, and then the OS would suspend the app again.

Though straightforward in concept, the actual implementation of SLC was a bit of dark magic. SLC events would be fired based upon a user’s movement between cell towers, but there was no promised expectation of how far that distance is. Interestingly some people ended up building utility apps that would simply measure how much distance was travelled between SLC events and report those value to a database such that an empirical average could be derived. From those exercises, it was found that 90% of devices would fire an update within 5km of movement and 50% within 1km, though even those values vary based upon the density of the user’s location amongst other variables (and may have changed since those measurements were taken a few years ago).

On top of that, there is no way to effectively test SLC events while developing an app in XCode. Even as of the time of this writing, the only way to truly test SLC events is to run the app on a physical device, hop in your car or on a train, and wait for events to fire and debug from there. I have done both, having circled many neighbourhoods and reaching the end of many bus lines in the process. Of course you can do some core debugging using non-SLC location updates, which in production consumes much more battery, but your options are truly limited if you want to make sure your SLC-enabled app is functioning exactly as it should.

As mentioned earlier, up until the release of iOS 7.0, SLC events would wake up apps that were suspended or killed in the background whether that was due to the OS or the user. It is common for the OS to periodically kill suspended apps if there is memory pressure such that the app the user is actively using is given all of the memory it needs to work optimally. The average user will also terminate apps (by double tapping the home button and swiping the desired app) out of the common misconception that doing so makes your device run faster with better battery life (this is only true for a very small percentage of “misbehaving” apps). However, SLC events have the special ability to resurrect apps that were terminated in these cases, enabling the app to wake up and do what it was intended to do after the location change… that is until iOS 7.0 was released.

With the release of iOS 7.0, and without any announcement or technical documentation indicating otherwise, SLC events would no longer wake up apps that were task killed by the user, though it would still restart system-killed apps. This sudden and unannounced change wreaked havoc on businesses and their customers that had built apps that were predicated on the pre-iOS 7.0 SLC app-restarting behaviour. For us at Wandera, we rely on our app and SLC to let us know when a user changes countries to detect roaming state, and if a user kills our app, we lose this detection ability. This was a major headache for us.

Dozens of companies, some with millions of subscribers and devices, saw an alarming decline of mission-critical “check-ins” from their apps across a growing percentage of their subscriber base. Bugs were filed with Apple, but it was deemed by Apple engineering that the user should have the ultimate right to kill any application that they don’t want running, and keep it from running again. This is the believed impetus for the change made in iOS 7.0.

In a desperate “Hail Mary” attempt, the CEO of Life360 sent an open letter directly to Tim Cook explaining that this sudden and undocumented change is having a devastating impact to his business along with many others. To his surprise, and to that of the rest of the Apple development community at large, he received a response that the old SLC functionality would be restored in iOS 7.1.  Lo and behold, the functionality was restored in iOS 7.1 beta 5 as well as the production 7.1 build released earlier this month. Like Life360, we also spent a lot of time finding a work around to this problem.

As our users upgraded to iOS 7.1, we saw immediate improvements of check-ins. Apps we hadn’t heard from in months started checking in reliably and consistently, exactly as they had prior to iOS 7.0.

The mobility arena is fast moving and delivering enterprise mobility solutions requires a highly responsive and agile team. While we always find ways to work around any challenges, it’s always more simple to work with rather around, so it’s great to see Tim Cook and Apple listening to the developer community.

Have you experienced the improvements to SLC in iOS 7.1? Let us know in the comments.

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *