# Arc constantly being terminated by IOS **URL:** \ **Category:** Arc App Support\ **Created:** [1 March 2021 10:19 UTC](https://support.bigpaua.com/t/arc-constantly-being-terminated-by-ios/93 "2021-03-01T10:19:20Z")\ **Posts on this page:** 1\ **Showing post:** 31
**Author:** ![matt](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/matt/32/3_2.png) [@matt](https://support.bigpaua.com/u/matt)\ **Post date:** [12 August 2021 08:48 UTC](https://support.bigpaua.com/t/arc-constantly-being-terminated-by-ios/93/31 "2021-08-12T08:48:27Z")
> [@Dinky](#): > > I’m sure you know what you are talking about, Matt, but fact remains Arc is the only app suffering from this as far as I can tell. No other navigation app is doing this. 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. > [@Dinky](#): > > Maybe a bit less aggressive monitoring and recording could help, I don’t know, but I agree with Camson in that less features and accuracy is preferred over not doing what it is intended for at all 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. - 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). * * * 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. --- _[View the full topic](https://support.bigpaua.com/t/arc-constantly-being-terminated-by-ios/93)._