For a long time Arc is being terminated by IOS randomly. Initially this happened occasionally but the frequency has increased in later versions of Arc. The latest update to 3.4.4. has dramatically increased the number and frequency of terminations, up to a point where Arc is practically unusable. Arc is terminated several times per hour and you never know if Arc is running or not and, if it is, if it will recognise movement and record it. There have been occasions where I checked Arc was running before leaving home, only to see nothing had been recorded since.
I am running the latest IOS version 14.4 on an iPhone 7 Plus.
1 Like
I too have noticed a significant amount of terminations since the last upgrade. iPhone 12 pro max : 14.4
I find that iOS is much more likely to terminate Arc if the phone is plugged in and charging, so I leave it disconnected when travelling to almost eliminate the problem of lost tracking information. I have an iPhone 11 Pro, so the battery life is good enough to get way with this. I charge when stopped for a while
This is a big problem of course, if you have an Apple CarPlay system that requires a USB connection.
I had the same issue with this version so I opened TestFlight and downgraded to the previous build. All has been well since then.
1 Like
The first thing to try is restarting your phone.
iOS can get into a state where it starts terminating apps aggressively. Perhaps some system service is using a lot of memory, and is ejecting other apps to make room at an aggressive rate. Or perhaps something else strange is going on with iOS. Either way, restarting the phone will fix it.
That can also happen on an individual app basis - where iOS aggressively terminates one specific app until the phone is restarted. I’ve seen instances of both: where many apps are aggressively repeatedly terminated, and when only a single app is. But yeah, either way, restart the phone to fix it.
Beyond that, there’s no known issues with the latest release. The automated crash reports show it as actually slightly more stable than the previous, with fewer crashes and longer durations between crashes. So it’s worth restarting your phones first, to make sure that isn’t the problem.
Yeah, there’s a known issue with CarPlay specifically. Although having the phone plugged in while travelling does appear to worsen things overall, but CarPlay specifically worsens things even more.
The most likely cause (or at least my greatest suspicion) is that it’s due to the phone’s thermal temperature - ie it’s just getting too hot, and iOS is responding to that by killing off apps.
Arc does respond to all thermal state reports immediately, aggressively reducing its sampling rate and disabling all non-essential activities when thermal state isn’t optimal. But it can only go so far. At a certain point iOS is just going to start killing all apps except for the foreground app regardless of how much those background apps are contributing to the thermal state issue.
Unfortunately there’s not much we can do about that. If Arc slimming itself back to absolute minimum isn’t enough to satisfy iOS, then that’s the end of the line. iPhones rely on passive cooling (ie there’s no fans in an iPhone). If the temperature gets too high it’s just plain going to have to shut itself down, app by app and service by service.
To give a bit more context: while travelling Arc is already doing nothing other than the tasks that are absolutely necessary for recording. All other tasks are held back until the recording engine goes into Sleep Mode.
So while actively recording Arc is already in a “chopper” mode, with very singular focus on only what’s needed.
The changes Arc makes when thermal state gets bad are changes that reduce the detail and accuracy of the recording - less frequent sampling, lower requested location accuracy, etc. Aside: These are the same sorts of changes that Arc makes when you switch the phone into Low Power Mode, or when the phone’s battery level falls under 20% (which Arc treats as being the same as Low Power Mode, regardless of whether you manually turned on Low Power Mode or not).
So there’s not really any more room to move in terms of avoiding iOS’s glaring eye, when it’s looking for background apps to terminate under bad thermal conditions. Arc could just plain turn off some data streams, such as accelerometer / Core Motion data. But it’s debatable whether that would really help at all. Once it gets to the point where iOS is killing off background apps, it’s often the case that the decision is already made, regardless of how small a target Arc makes itself appear.
I’ve been using Arc since 2017. I’ve had this problem for the past 2 years.
I spend a lot of time at home so I can see why iOS might kill the app in the background but all day long I get a notification from Arc that iOS has stopped the app. I tap the notification and then go into the app. And then an hour later it happens again, I get a notification that Arc has been stopped. This happens every hour all day long. I have to make sure to open the app prior to leaving the house as well, it’s that bad.
Restarting iPhone, force closing all apps in app switcher, etc, nothing helps.
And the other week after driving, I came home to find that the app didn’t record anything at all that day. Never had this happen before. So I would say it has gotten worse over the years but definitely worse within the last month.
iPhone 12 Pro Max using iOS 14.5 Beta 2 at the moment
Not blaming Arc at all, but Google Maps Timeline and WHIB (Where Have I Been) have not had this problem in my testing. Google Maps sometimes doesn’t record if I haven’t opened it in a while but I find WHIB to almost always record even without me opening it. Even if I don’t have other location tracking apps turned on, iOS seems to keep closing Arc in the background. Arc is the way better app by the way, just gets frustrating with the constant background app closing by iOS.
1 Like
This is my experience as well. My impression is Arc gets terminated more frequently when the phone is more or less stationary. There seems to be no clear rule for this, as far as I can see. Some days it happens more frequently than other and Arc is the only app suffering from this. Anyway, it’s a nuisance.
1 Like
Unfortunately it’s very specific to each of us. Over the years some people have had perfect stability, some worsening stability, some improving stability.
From automated crash reporting, and in more recent iOS generations / Xcode versions also automated reporting of iOS resource use terminations, I can be aware of shifts averaged over all of us, so I can know whether one version is better or worse than another. But on an individual basis any one of us could be getting fantastic / better results while another will be getting worse / intolerable results 
The crash rate over all of us (ie from automated crash reporting) is 98.3% crash free sessions with Arc 3.4.4, and 98.0% for Arc 3.4.3, so the newest release is more stable compared to the previous, but that’s not going to necessarily reflect what any specific one of us experiences.
There’s also mystery factors in terms of how different iOS versions are managing system resources and how aggressively they are terminating background apps. In the past there have been big fluctuations in that - some to the point where I’ve had to escalate it and make a fuss out of it, because it got to the point where it was near on impossible for Arc to function normally for many people.
With more recent iOS versions (all of iOS 14, and most of iOS 13) there haven’t been major problems with iOS being overly aggressive in terminating background apps. It’s mostly smoothed out and settled on fairly sensible patterns. (As indicated by automated termination reporting, and patterns in common issues raised by users).
Although those apps seem superficially quite similar in what they’re doing, they’re actually a fundamentally different class of app. I could build an app similar to Google Timeline in … well, frankly, a weekend, and have it running with 99.99% stability and reliability, because it’s just that much easier of a task.
Arc instead aims for the highest detail in its recordings, which means cutting almost no corners in terms of data streams (location data, accelerometer, pedometer, etc). In contrast, apps with lower detail goals can use things like iOS’s “significant location change” service, or “delayed location updates” (scheduled to trigger after the location has changed X metres or after Y seconds).
Those low resolution, low detail system services aren’t an option for Arc, given Arc’s goal of highest possible detail and accuracy. Arc instead has to live in a grey zone that Apple don’t really want apps to be in - running 24/7, requesting location data 24/7, and for active portions of that time also requesting [near to] highest possible location data accuracy effectively direct from the firehose, ie sampling frequency of 1 location update per second, or even faster in some cases (though Arc does discard location updates that come in faster than 1 per second, because at that point there’s really nothing extra to gain from it.
To be able to use that highest level of data stream sampling frequency and detail, Arc has to be constantly dynamically adjusting a bunch of things based on current conditions, to be able to keep energy/resource use as efficient as possible without sacrificing detail.
Aside: the one concession I made right at the start, and that continues still, is that Arc goes into Sleep Mode while stationary, meaning that for most indoor settings Arc doesn’t record your movements inside the building. Smartphone battery life has come a long way over the years, but it’s still not to the point where true 24/7 recording is possible. And even if it were, location data accuracy inside buildings isn’t really good enough under most normal conditions for it to be worth bothering.
Anyway, after all that rambling, I’ll post another reply after this one with some tips on how to hopefully reduce background terminations a bit better.
1 Like
Ok, so, tips and technical info:
Watch out for apps that use a lot of memory: the Camera app, Photos app, games, video apps, anything that seems like it would probably require a lot of memory. Many of these apps will result in almost all background apps being ejected (ie terminated) immediately, even on some newer model iPhones.
In some previous generations of iOS and iPhone models you could trigger the termination of almost all background apps with almost 100% consistency just by opening the Camera app. This is still the case now on some phones and iOS version combos, although it has got better in recent years.
Apple have stated that if you don’t want your app to be terminated for memory reasons in the background, you need to target getting the app’s resident memory size to under 50 MB (if I’m remembering right - might be worth double checking that number).
When Arc is running in headless mode (ie the UI has been fully discarded in the background, and only the recording engine is resident in memory), Arc uses roughly 50 MB, but it can fluctuate a bit up and down, depending on what kind of and amount of data has been recently recorded. Even at 50 MB Arc is still a target for background termination, but I keep an eye on that memory use while headless in the background anyway, to do my best not to anger the iOS gods.
Arc goes “headless” about 2-5 minutes after going into the background. (Actually, I’ll check the exact number in the code in a sec and come back and edit this). The UI is kept for those minutes so that if you are switching between apps, back and forth between Arc and something else, you don’t have to watch the UI reload every time you come back. But after those minutes Arc will go fully headless, into a slim efficient recording machine, doing its best to stealth under iOS’s evil gaze, and hopefully avoiding terminations. But before it’s gone headless, it’s a much bigger target for iOS’s anger.
So the most practical application of that knowledge is: if you’re switching between Arc and for example the Camera app or Photos app, Arc won’t yet be headless, and will be much more likely to get killed off by iOS. Aside: there’s also no technical way around that! Going headless actually briefly requires more memory, due to the way operating systems handle compressed / paged out memory. So even if Arc immediately went headless the second it went into the background, it’d still be a prime target for iOS’s termination hammer when switching to a memory hungry app. There’s no winning there 
Anyway, the tl;dr is: if you’ve just used an app that uses lots of memory (Camera, Photos, a game, etc), you might want to check to see if Arc is still alive.
1 Like
Thanks for taking the trouble to explain all this. If the level of detail and accuracy is contributing to Arc’s vulnerability to be killed by IOS, then maybe a bit less accurate and demanding could be of help. I’d rather have an app that is a bit less accurate but running than a very accurate app that is not running…
Again today I went out without first checking if Arc was running. There was no message saying it was stopped, so I assumed it was on. But later today I discovered that it apparently wasn’t. But I found it had restarted itself because a later trip was recorded. So, again, in my experience Arc is being killed more frequently when it has been stationary for a long time and not so much when “in action”
There’s now quite a lot of apps out there that provide lower detail timeline recording. I have to try to be as narrow as possible with my focus for Arc, given that there’s only one of me building it 
The other issue with being more dynamic in Arc’s accuracy / detail levels is that to get to low enough detail to avoid angering iOS would require making the recording engine of almost a completely different class of recording (eg deferred location updates), which wouldn’t work with the existing subsystems (stationary/moving detection, and possibly some others). So it would require quite considerable architectural work. The current low level recording subsystems are designed to be flexible and dynamic within a certain range (for getting the best energy efficiency in various different conditions), but they’re not flexible enough to accommodate things like deferred location updates. In short, it wouldn’t be a quick fix, it’d be an entire project in its own right. Sadly not something I can justify at the moment.
I think we’d be better served walking through problem finding steps to figure out why each of you is seeing more frequent terminations. With the last few releases, you should really be seeing Arc uptimes measured in days, not hours.
Though it’s difficult to know where to start on that fault finding…
The basics are making sure all your system settings are correct (Background App Refresh is turned on, Airplane Mode is being avoided when possible, location permission is set to “Always”, notifications are enabled).
The next is apps that have very large memory requirements (Camera app, etc), as I covered above.
But beyond that… we’d have to go into Sherlock mode, and start looking for contextual clues. Things like looking for patterns in the times of day when terminations happen, or places that you’re at when it happens more frequently. Whether the phone is plugged in or running on battery when the suspected terminations happen. What other apps might be being used at the time. Basically anything that can be used to put together a detective style scene of the crime.
Oh, another kind of clue is whether you’re leaving home at similar times, or common times, or whether Covid lockdowns have got you travelling less frequently and at irregular times. Patterns around that kind of thing can give hints to what’s going on too.
To give some idea of why that matters: both Arc and iOS “learn” your regular daily patterns, and adjust the way that they do things and the times at which they do things based on that knowledge. When those daily routines are disrupted, both Arc and iOS’s learnings can become quite wrong, and things won’t run as well as usual.
Arc will relearn to an extent, but at a certain point it just becomes impossible to predict with any reasonable accuracy what’s going to happen, when our routines are disrupted, especially during extended lockdowns.
Likewise iOS will be relearning, though the internals of that are a mystery to us due to Apple’s secrecy. So I can only make rough assumptions about what’s going on with iOS’s own ML (Machine Learning) and how that affects what iOS does and when.
But yeah, that kind of stuff can also give useful clues, so it’s worth seeing if you can spot any patterns along those lines (or the absence of previous steady patterns).
My feeling is staying at the same place for a day or longer is affecting the number of Arc stops, but is not consistent.
Yeah, that’s unfortunately somewhat expected. It shouldn’t happen, but since the start of Covid lockdowns it’s what’s been consistently seen. iPhones seem to get confused about what apps they should prioritise, and Arc comes out worse off.
Aside: Arc actually has a “Deep Sleep Mode” which self terminates, or rather gives iOS permission to fully terminate the app.
Deep Sleep is designed to drop Arc’s energy use to absolute zero (by allowing iOS to terminate the app) when Arc has high confidence that you’re definitely not going to go anywhere for more than ~6 hours. The most common case being when you’re asleep at home, and Arc knows with high confidence what times you leave home in the morning.
Deep Sleep is only used when the phone isn’t plugged in to power. So if for example you get home and plug your phone in, and it stays plugged in until the next morning, deep sleep will never be used. In practice that means that if you plug your phone in at night while sleeping, deep sleep won’t be used. (Before bedtime the probability of you leaving the house for some errand or some such is high enough that the confidence threshold for deep sleep won’t be reached, and it won’t engage).
When Arc goes into Deep Sleep it requests a “wakeup call” in the form of a silent push notification, scheduled to be sent at a bit before your earliest likely leaving time (ie when the probability of leaving falls outside the deep sleep threshold).
But in these lockdown times, deep sleep isn’t really a thing. The Place model confidence for knowing whether you’re going to stay or leave isn’t good enough beyond one day at home, so if you’ve been at home for longer than your usual daily routine, deep sleep won’t happen (Arc simply can’t be confident that it knows it’s safe to do).
So that reveals one case where Arc could temporarily be thrown off, if for example you change jobs or workplaces and start leaving the house an hour earlier in the morning. Until the Place models update to understand that new different likely leaving time, if deep sleep has engaged, the wakeup call will be arriving too late, and Arc won’t be getting restarted early enough in the morning. In practice that kind of thing only causes trouble for a few days at most, because the deep sleep confidence threshold is set very high, so even just a few days of a different earlier leaving time will solve that particular problem.
Funny; I would expect the opposite. You are less likely to leave home when it IS connected to power, in combination with a likely bedtime
Deep Sleep is designed to extend the battery life. It allows the phone to go completely into “standby”. If the phone is plugged in to power, there’s no point in trying to save battery, so no point in engaging deep sleep. And given that Deep Sleep has higher risk, due to not being able to trust that iOS will definitely deliver the wakeup call silent push notification at the requested time, and restart the app, it’s best for Arc to avoid using deep sleep if it can.
Aside: standby isn’t talked about as much these days with smartphones, because phones are pretty much always doing something these days. Standby essentially means that the phone shuts down all non-essential functions, going into its lowest power mode, and just sits there waiting for a trigger to wake it up again (such as receiving a phone call, or you unlocking it to open an app or some such).
So even though Arc’s Deep Sleep mode stops Arc from blocking the phone from going into standby, there’s probably 10-20 other apps or services on your phone also blocking the possibility of standby. So for most people Arc’s deep sleep mode doesn’t necessarily achieve much of use. Though possibly if the phone is unplugged overnight, that’s a time when the phone is most likely to be definitely doing nothing (after iOS has finished doing all its own daily cleanup/housekeeping tasks too), so there is some chance of it going into standby, and deep sleep can achieve something for those people who don’t charge their phones overnight. (ie they’ll have more battery left in the morning).
Hi Matt,
Good to know about the CarPlay issue, although I don’t have a car that supports it yet. I use a phone mount that goes in a cupholder. It’s out of the sun that way. In one car that puts it right in front of an aircon vent. Queensland is way too hot to mount a phone on the windscreen.
1 Like
Bangkok too! Though I usually cycle, and have my phone mounted on my handlebar. And the building shade in the city keeps the phone out of the worst direct sun. But when cycle touring the phone doesn’t like it so much.
Though even just having your phone plugged in to power while in the car can be enough to upset the phone in terms of heat. Not all iPhone models, mind you, and even with the problem models it’s not consistent between individuals.
But as a rule of thumb, any phone that’s plugged in to power will be running hotter than a phone that’s not. It just depends whether that extra heat is enough to upset the phone’s hardware to the point where it starts to throttle the CPU/GPU to protect them, and potentially start killing off apps.
In my testing over the years, the most troublesome iPhone models in terms of heat have been the iPhone X and XS. The XS was better than the X, but only marginally. But since then it’s got a lot better. And the models before the X were also a lot better. Something in that form factor change resulted in more heat risk!