No. This is wrong. All background apps suffer from all the issues I have described. You’ve triggered me with one of my zero tolerance claims there, so brace for an impending essay.
The difference is in the degree of suffering, but all apps are operating under the same conditions and suffer the same risks and often same outcomes.
I’ve spent years doing daily testing on a bag full of test devices, comparing every device model and every Arc competitor in all-day real world conditions in many cities around the world, so that I can say these things with absolute certainty.
Arc has a specific niche in the market, and other apps already adequately serve other niches. Arc’s niche is the highest possible accuracy and detail. If you’re satisfied with less detail, then there’s other apps out there that do that well.
I’ll describe the specifics of why Arc is a more prominent target for iOS’s wrath, and why that can’t be avoided:
-
Effectively all other apps of this kind are in a different technical class, even if that isn’t readily apparent in the UI or data. They operate using different iOS systems, such as the “significant location change” service, or “deferred updates” location service. Arc instead makes use of the raw firehose of location data. These are three separate location update systems.
-
The first, the Significant Location Change service, is what you’ll see sometimes in apps like Google Maps’ timeline feature, with detail ranging from extremely low to sometimes moderate (ie tens or hundreds of metres between location points in the paths). This makes the app much less of a target for iOS’s wrath, due to the app essentially being 100% idle for many seconds or even minutes between location updates. iOS will still kill the app on occasion, because it be like that, but it’s going to be lower down the hit list.
-
The second - deferred location updates - is somewhere between the two, and relies on telling iOS not to inform the app of new location data until the device has moved X metres or it’s been Y seconds since last update. This allows for more detail than the Significant Location Change service, but still comes at the cost of detail and accuracy, due to information being necessarily discarded and the app not seeing it. Again, this also lessens the risk of angering iOS, due to the app sitting 100% idle for potentially seconds or minutes between location updates. But again, that doesn’t mean it’s taken off the hit list - iOS can and will still kill the app off if the mood takes it (for example when opening the Camera app, which is all about memory requirement, not CPU resource or thermal state or any other threshold).
-
-
Arc is the only app of this kind that does all of its processing and data storage directly and only on the phone itself. (Leaving aside raw location data recording apps that don’t process for visits/trips/activity type/etc, which are a separate but related class of app, but of which there are some that don’t have any service side component).
-
Arc does this for privacy and security reasons. Location data is one of the most privacy sensitive classes of personal data, and storing it on a remote server owned and managed by a third party is a significant security and privacy risk. Think of old Moves app, where you were essentially handing over your entire life’s timeline of movements and places to Facebook, of all companies. In retrospect, I doubt many of us would be comfortable with handing over that much to a third party like that again.
-
Apps that store your data service side are able to do all the timeline processing, activity type detection, daily/weekly/monthly summary collation, Machine Learning model updating, and much more all server side. That means that your phone isn’t doing any of those CPU expensive daily tasks, they’re being done on a remote server instead. In turn that means the app’s energy/CPU use averaged out over each day will be significantly lower than Arc’s. Arc instead has to pay all of those costs right on the phone, which increases the app’s profile in iOS’s hit list of apps it doesn’t like, and thus will be more trigger happy with, willing to kill off earlier.
-
Note that means that even when Arc is actively recording and is operating at bare minimal necessary functionality, Arc is still already on iOS’s potential shitlist of apps it’s got less love for and more of an inclination to kill off. Aside: Arc’s recording mode is extremely energy efficient - often even more efficient than less detailed and accurate competitors. I spent years of careful optimisation to make that happen! But no matter how efficient it is, the other processing and collation tasks Arc has to do each day make it a bigger target for iOS’s wrath.
-
I’ll finish with why one suggestion common suggestion won’t work for Arc. People suggest that Arc could sacrifice detail and accuracy under some conditions to avoid iOS’s wrath. But this won’t work. Why?
-
Firstly, because Arc is already running at near peak possible efficiency while recording, and as I said above, often even more efficiently than less detailed and accurate competitors. The recording mode is already extremely optimised for energy use as well as memory use.
-
Secondly, because it’s not necessarily resource use at recording time that attract’s iOS’s anger. Arc’s deferred daily processing/collating tasks each raise Arc’s position on iOS’s shitlist / hitlist of apps it doesn’t feel friendly towards.
So in short: Reducing Arc’s already extremely efficient energy use while recording won’t make a dent in offsetting the reputational damage done by the various deferred/daily processing/collation tasks that are necessary due to Arc’s strict privacy policy. To fix that, Arc would have to move those tasks to server side, offloading them from the phone, which would mean giving up Arc’s strong privacy defences.