Unfortunately I have the same problem and it is getting worse. I have the latest ios update on an iphone 12 pro. I have to close almost all apps in order for Arc to record correctly or at all and even then there’s no guarantee it won’t terminate. I restart my phone regularly as you recommended, but that doesn’t seem to do any good.
@MZwart that sounds quite extreme! It’ll be worth looking for more clues, because that’s definitely not normal.
Things to look out for are:
- What other apps are you using? Are any of them extremely memory hungry, such as games, video or photo editing?
- Are you sometimes using Airplane Mode? Or have Background App Refresh disabled in your phone’s settings? Or have wifi disabled in some indoor locations?
- Does Arc have all the permissions it needs? Those being: Location Services set to “Always”, Background App Refresh on, notifications on (it doesn’t matter with which settings - just needs to be on, to allow the wakeup call silent push notifications), and Motion & Fitness on (though Arc probably wouldn’t start at all without that on).
Also the more detective style context you can determine around the times when the terminations happen will help too. Is it certain times of day? When you’re at certain places? When you’re taking certain trips? After you’ve used certain other apps? When the phone is plugged in, or on battery? Whether the phone feels hot at the time? Basically go Sherlock Holmes on the problem and look for clues in the crime scene, to try to track down the offender causing the problem 
This is still happening to me ALL the time It makes me not becoming a backer. It’s so unreliable for me, that I can’t trust that arc does what it promises. Last 4 weeks I was everyday some where else. My phone usually is out of power now and then, so it reboots now and then. So, the solutions I read here, aren’t working for me.
Agree. I stopped my subscription because of this. Adding all sorts of features to Arc is useless, as long as this issue is not solved.
1 Like
@Dinky @gjbrugman Unfortunately this problem can’t be solved by me, at least not directly. It needs to be solved by Apple.
Apple’s policy with iOS is that apps aren’t guaranteed to be kept alive, and can and will be terminated at any time, for any reason iOS chooses. In practice that means that almost all apps get suspended within seconds of going into the background, then terminated completely some indeterminate time after.
Arc (and apps like it) had to get specific approval for continuous background execution, and that approval doesn’t come with any guarantees. Arc will still be terminated at seemingly random while in the background, and I can never completely eliminate that risk.
When it happens more frequently than about once a day, that suggests there’s a problem with the phone in some way. Or at least the conditions on the phone are such that iOS is choosing to be more aggressive in terminating background apps, to the point where it harms the app’s functionality. As I said, that’s up to Apple to resolve - I can’t fix that.
The best we can do is play detective and narrow down the possibilities of why a specific phone is acting in that way - what the conditions are that are causing the phone to terminate background apps aggressively, then work around those conditions.
That means things like being aware of when you open large memory hungry apps (such as the Camera app), watching for things like thermal state (how hot the phone is), spotting patterns in what times of day the phone is doing it, etc, etc.
I’ve been struggling with the termination issues myself recently too. The app will crash and not record anything. It’s primary function is recording the trail and that should be the most important and protected process. I’d rather have less features, or manually triggered processing than empty recording.
I have noticed a couple of patterns to the crashing however, which might help.
- When the phone is connected to the charger. Not immediately, usually after 5-10 mins when the phone has warmed up from the charge. I’m assuming iOS hits a thermal limit and Arc gets killed. This is usually the case that I find in the morning when I wake up.
- When connected to the car, Carplay starts and it’s also charging which often seems to kill the app too.
- Surprisingly, on low power mode, it seems to crash less often?
- It would crash often on the old backup system when the backup wasn’t complete. The new system is much better.
- Before I upgraded, I had an older iPhone which would always crash it when opening the camera. Now I have upgraded to an iPhone 12 Pro, the camera/big app issues rarely occur.
I really like the app itself and how it displays and exports data. However, I’m struggling to justify the cost against it’s unreliable recording. I’m paranoid that it’s stopped recording and I have to open it all the time just to ensure that it’s still going. I went on a holiday and wanted a trail of my journey, but there were many gaps and sections missing. I ended up using a different trail recording app on my wife’s phone as a backup.
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. 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
I agree with this one. I trust Matt is a great developer, but saying that Apple should solve it, sounds not good. You have to deal with what Apple gives you. And arc is the only app that gets terminated. I have another app that tracks where I am, Life Cycle, and it does that flawless.
So. If you want me to pay for this app, and I want to, you have to fix this.
Agree with the previous posts from today. The constant app terminations are making Arc useless to the point that I’m actively exploring just using Google Map’s Timeline feature combined with Fitness/Apple Watch for when I want more precise tracking.
I was an early adopter of Arc, and have been supporting Matt all the way through. The app shows Matt’s love and care, but it seems like iOS just doesn’t like some fundamental aspects of what Arc is trying to do in the background. It may be necessary to alter what Arc does in the background so it isn’t being constantly targeted by iOS for termination.
I’m happy to pay independent developers for their work, but the product needs to work. For the past week or so, Arc just hasn’t been working.
Yep, and that’s how it works 
While in active recording mode, Arc does literally nothing other than the core essential tasks. It only records the data, and everything else is deferred until either Arc goes into sleep mode (ie you’re not moving anymore and haven’t been for several minutes), or you foreground the app (at which point it’ll do processing on the visible timeline data, to make it presentable for the UI).
Additionally, the processing in sleep mode is also only the essential minimums. All auxiliary processing / housekeeping / data collation is deferred to daily background processing tasks, which are filed with iOS with the flag “requires power”, so that they’re only run once the phone is plugged in to power (and while Arc is in sleep mode, amongst a bunch of other checks such as thermal state).
Thermal state is definitely a trigger for iOS to get angry and start killing off apps. Arc responds to bad thermal state as aggressively as it can - it scales back recording sampling rates relative to the thermal state (the worse the thermal state, the lower the sampling frequencies), as well as of course not running any auxiliary processing tasks at all until thermal state is good again.
Unfortunately if the phone gets too hot, iOS does go on a very aggressive killing spree, and often no amount of mitigation on Arc’s part can avoid iOS’s killer gaze in those cases.
Aside: Bad thermal state is tied to specific iPhone models - the iPhone X and XS were the worst of all, and it’s got significantly better since then.
My suspicion with CarPlay is that it’s a multi pronged bad situation - there’s high thermal state due to charging, due to position in the sun, and due to CarPlay itself being potentially resource hungry and pushing thermal state up even further. I don’t own a car though, so can only go on guesses with this stuff. But there’s certainly more reports of problems with running Arc alongside CarPlay than alongside any other app.
I suspect this’ll be due to less thermal state issues. In Low Power Mode, Arc does similar reduced sampling rate changes as it does for high thermal state. And the phone itself makes changes that help to dramatically reduce the chance of high thermal state (the CPU/GPU are throttled back), and iOS non-essential background services are also disabled.
Unfortunately I still get reports of the Camera app causing terminations even on the latest iPhone models 
Smartphone cameras are a highly competitive area, so Apple keep pushing the processing further with each new phone, so even though the newer models have more memory and power, they’re also making as much use of all of that as possible, to keep camera results competitive with Samsung etc.
But yeah, in general the newer phones present much less risk of Arc getting killed off when the Camera app is opened. It’s not guaranteed though 
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.
Then use that app.
If you’re not happy with Arc or my answers, then move on.
I fix what can be fixed, and give details and explanation for what can’t be fixed. That’s how it is.
That app only records where I where for longer periods and not the route. Only arc does and shows that. And that’s why I like the idea behind the app. The only thing, and that was written before, is that when one can’t trust that this task at random stops, you get paranoid. And the app becomes unreliable.
Again today: nothing recorded, while I was away by car, on foot, stationary, on foot and by car. All in all a period of 5 hours and nada, zip…
Useless
@matt if the constant background processing is making Arc going in the shitlist, how about making a night processing mode like Amazon Photos does for its backup system?
Use those low accuracy stuff for basic display during the day, and give the users the ability to postpone all processing to times they know they can let the phone 100% dedicated and plugged in to it, like at night.
would it work?
@Amido, Arc already does this. All not immediately essential processing tasks are deferred until the phone is plugged in to power, and additionally are filed with iOS’s background tasks system, flagged as requiring power.
That “requires power” flag opts the task out of iOS’s resource use watchdogs. Those watchdogs are things like “sustained 80% CPU for more than 60 seconds”, which going over will result in the app being terminated. So while the scheduled tasks are running, they’re not at risk of going over one of the watchdog thresholds and getting the app terminated.
That however doesn’t opt Arc out of iOS’s overall friendliness metrics it maintains for each app, on daily / multi-day durations. All apps are graded (by undocumented metrics and systems) based on their usage, both by the user and in terms of system resources, and iOS will treat the app more or less kindly depending on those unknown metrics.
All of Arc’s deferred / scheduled background tasks ultimately still need to be done. Backups, ML model updates, database housekeeping, etc. So while they don’t result in the app being immediately terminated, due to being run inside iOS’s background tasks system and flagged as requiring power, they still count against the app’s overall resource consumption metrics over time, and affect how kind or cruel iOS will be towards the app.
Lowering recording accuracy won’t improve anything, as Arc’s recording engine (LocoKit) is already extremely energy use optimised. Reduced accuracy wouldn’t result in energy use reductions of any worth.
I think I understand the situation, but there are things that you very kindly explained that seem at odds with each other.
You state that lowering the accuracy won’t change the situation, but then say that the other apps have easier life because of their lower accuracy and use of other data sources.
I, for one, would love having the ability to lower the accuracy, use “standard and approved” sources and have better reliability of tracking, given that the raw data still sucks ass so I constantly end up with stuff like airplane 5 meters → walking 2000 km → stationary at the store next to my house 9 hours overnight. It’s not like this is dedicated hardware for accurate tracking so I don’t think you’re exactly considering all of the app’s strengths by saying you’re in the super high accuracy niche. I value Arc mostly for its constant export to JSON and its decent UI, for example. But I’m just one guy.
Another thing you say is that all other apps have this termination problem, but I can attest that Tracer and SilentLog have been running on my phone for months, almost a year now and never have skipped one single second of tracking. Whatever they do, I wish I had it in Arc, so I’m not locked into any app if shit hits the fan and you can’t develop this app anymore (and thanks from the bottom of my heart for the open source version for this reason, it truly is a gift to the world).
For the deferred/scheduled, I strongly encourage to take a look to Amazon Photo’s system, for real. Their app also never gets booted from memory, uploads the pictures pronto and has this beautiful “do all the heavy lifting during the night” mode that dims the screen while it uploads all your camera roll. I’d rather have Arc tell me weekly “yo man, time to let me do a night thinking about all of your crap” than having holes in my data/having it never fully analyzed recent stuff because it tries not to get booted from memory. But that’s me.
Regarding this naughty list, this is the first time I read anything about it ever, and I develop for iOS, too. Do you have some evidence/data/documentation about it, or is it just a theory you developed from all your fights with getting booted from the OS?
It strikes me Arc is especially terminated when my phone is stationary for a long time. This would suggest that tracking activity has nothing to do with the termination problem
You won’t get it. Lowering Arc’s detail or accuracy won’t do anything to reduce terminations.
Before reading further: If you want a solution to the terminations problem, install Arc Mini, and add one of Mini’s widgets to one of your home screens. Having multiple recorders will almost completely solve the problem.
There are two specific niches that Arc caters to: 1) highest possible accuracy and detail achievable with current hardware, and 2) best possible data privacy achievable with current technologies.
To reduce the chances of iOS terminating the app in the background, niche 2 would need to be given up on. It’s not recording detail level that causes the terminations, it’s the fact that Arc does all of its work on device, with no server side processing or storage required.
The reason why I highlight differences in the way Arc records versus other apps, is to emphasise how they are fundamentally different classes of apps under the hood. But that doesn’t mean that regressing Arc’s recording functionality to that level will solve any problems - it wouldn’t - it would leave the terminations problem exactly at it is, but with less detail and accuracy, for no actual benefit.
To highlight this: I run Arc v3, Arc Mini, and Arc v4 on several test devices that I take everywhere with me, for testing purposes. All of the apps use the same underlying recording engine, and record at the same accuracy and detail, but v4 doesn’t yet do many/any of the daily background tasks. Arc v4 has typical uptimes measured in multiple days or even weeks, because it only has the job of recording, at this pre-release stage. That makes it similar to competitor apps, that rely on server side processing, so that the app on the phone only has to record and nothing else.
Having Arc v3 and Mini sharing the job of doing the daily background tasks also reduces the risk of each of those apps being terminated, such that each of them often has multi-day uptimes, terminated only when I relaunch the apps during development and testing. Which is why I say installing Arc Mini will almost completely solve the problem for you.
But back to the idea of an option to reduce Arc’s detail or accuracy: As I’ve made clear, it won’t achieve anything useful in terms or increased reliability. But also it’s simply not the point of Arc. If you want less detail, you can use another app. I’m not interested in making that app. Building an optional, fundamentally different recording engine, designed to produce less detail and accuracy, simply isn’t what I’m here for. If that’s what you’re interested in, I recommend petitioning the developers of one of the competing app to add the export functionality you want.
It’s indicated in some device logs that mention scores when terminating apps, and has been discussed (in vague terms) in WWDC sessions in the past. The device logs are hard to find, and I forget exactly which ones they are, but think in terms of lists of running apps/processes, and indication of which ones were terminated, for what reason, and with vague scoring notes attached.
I also know it as a certainty due to 5+ years of testing, on a bag full of test devices. As an example, if a specific test device is used for heavy debugging during dev of a new feature, perhaps with high resource usage in foreground or background, the app on that device will be punished, sometimes for a period of days, while the exact same build installed on the other test devices will run reliably without termination for the same days. Or if for example one test device is running a new daily background task, that the other devices aren’t, and that task isn’t yet well optimised, the app will be punished on that device. Not necessarily at the time the task runs, but at other times during the day.
From my experience and experimentation there has in the past also been a factor of foreground vs background resource use time. For example a freshly installed app, that then gets almost no foreground time (ie the user installs it, opens it for a few seconds, then gets bored and moves on) will be punished more, with more frequent terminations, based on the same background resource use as the app on another phone that has had more foreground time. Perhaps some sort of “user interest” metric, that permits the app more tolerance in background resource use.