Hi
iOS keeps stopping arc running in the background I have a iPhone 16 with the latest iOS running , can someone help
Hi @Fatdad!
The first things to check are that Arc has all the necessary permissions it needs:
- In the iOS Settings app, check Privacy & Security → Location Services → Arc Timeline, and make sure it’s set to “Always” and Precise Location is turned on.
- Again in the Settings app, check in General → Background App Refresh, and make sure that’s turned on both at the top and then specifically for Arc Timeline down in the list.
If those two were already correct, then I’ll give you a bit of general background on the problem before moving on to the next step.
Basically the problem is that iOS apps don’t have control over whether they stay alive in the background or not. They can ask to stay alive, but it’s up to iOS to decide whether it will grant that request and for how long. At any point in time iOS can decide it wants to kill off some background apps, to free up memory, to reduce energy use, etc. So there’s no absolute way of ensuring that Arc will definitely stay alive and running all the time.
In typical use you can expect Arc to stay alive for about a day at a time before it gets killed off by iOS. And then if all goes well it will be auto restarted by iOS before you notice the “Arc has been terminated” notification, and which point Arc will delete that notification so it isn’t there to tell you out of date info - it’s already running again.
But that leads us to the next step to take. Because iOS will eventually kill off Arc, and then also might not automatically restart it soon enough, there is always some risk of data gaps in your timeline. Which is why Arc has a companion app, Arc Timeline Recorder: ‎Arc Timeline Recorder on the App Store
The purpose of that companion app is to sit quietly in the background, always alive, always consuming almost no energy or battery, ready to take over recording if Arc Timeline app is terminated. The two apps communicate, and decide which of them is going to be the active recorder at any point in time. Then if one of them disappears the other one sees that happen very soon after, and knows to take over the job, to prevent data gaps appearing in your timeline.
Though even then there’s still a risk of iOS killing off both apps! But in practice that’s rare enough that it doesn’t matter. And Arc Recorder is small and meek enough that iOS tends to ignore it and forget it’s there most of the time. So Arc Recorder getting killed off is super rare - it’s basically always there, quietly in standby, ready to jump in and save the day when needed.
Hi @matt,
I have this problem. But it’s because for six days I didn’t notice Arc Timelines stopped recording and the Timelines Recorder continued to record behind the scenes. when I finally noticed, ARC Timelines appears to have received the data from the Timelines recorder and been absolutely screaming since then with all the appearance of trying to crunch the six days of missed data.
For a while it was flashing “processing 4891…” or “ 5120 uncertain items” but it’s gradually curbed that down to thinking I was in a car for five days. It’s fine, I don’t really care because it appears as if all the data is there behind the scenes somewhere. It’s stopped trying to crunch all the data now, I think and given up.
But because the app has been trying to crunch all that data it’s at 38% battery usage by app in the Settings → Battery (>25> more than any other app) and now IOS is just killing the app because, my guess is, it’s the first on the list of things to kill because of the memory/battery use.
I’ll probably delete it and restore it which hopefully will take the target off it’s back, but I don’t want to risk losing the database by doing it. So I thought I’d ask you first.
Hmm. The first half of that is expected - Arc Recorder doesn’t do any timeline processing - but the second half isn’t! It shouldn’t be ending up thinking you were in a car for 5 days. So some processing weirdness happened there somehow…
Yeah that sounds about right. iOS will kill first the apps it’s most offended by, and high CPU use or high memory use will offend it most.
Oh no, please don’t do that! That won’t fix anything, it’ll just make the problem 1000 times worse 
The app will then have to spend multiple days or even weeks reprocessing the restored data.
Instead the best thing to do is to go into the data that Arc is trying to process and help the cleanup process along by doing any cleanups you can spot yourself.
The first I’d try, given that it sees 5 days of car, is to go into that mega car item and go to “Extract brief visits” from the more/ellipsis menu. From there you can extract out a few obviously correct visits. That will reduce the size of that mega car timeline item, making it cause less problems.
Any manual cleanup you can do will help the automatic processing/cleanup get through its workload faster and more accurately. And also many manual cleanups you do will trigger a new targeted auto cleanup process in response, which will allow it to do a better job of it, better understanding what the data is supposed to look like.
I have the same problem. I have a lifetime license and have been enjoying Arc for several years. This used to happen a lot less frequently but now, Arc is stopped several times a day. I am a bit hesitant installing a second app to make sure the actual app gets all the data.
Don’t get me wrong - I really like what Arc does (although why it thinks I ride a bike intermittently when I’m on a long hike, is still a mystery to me…). However, I also run other apps that track my position and keep a timeline of sorts (such as Find Penguins, Wayward OsmAND and others) and none of them require that I run a second app to keep the actual app happy. None of them get shut down either. I know, it may be comparing apples to oranges but still…
Is there a reason Arc is different? THANKS!
Yep! And you already identified it: comparing apples to oranges.
Those other apps aren’t recording real-time continuous location data. They mostly rely on what’s called the “significant location change” service. That service starts up the app every time your position has changed some “significant” distance, which could be hundreds of metres or even kilometres. Then the app goes back to being suspended.
That results in something that is potentially useful for recording visits, but not for recording the trips between them. Arc is an app that’s designed for continuous all day timelines, including full detail on trips between places. Sometimes the distinction between these two kinds of apps sounds subtle, but on a technical level it makes them completely different things.
Any app that can continue to function correctly if it’s swiped closed or terminated by iOS is of the other kind, not the same kind of app as Arc. And if those apps tried to do what Arc does - recording trips between visits in full detail - they’d also have to be left running in the background, never swiped closed.
Those apps are likely spending 99% of their time “suspended” in the background. iOS wakes the app up for each “significant location change”, the app records that, then the app is suspended again. The end result is path lines that have points hundreds of metres apart. And in principle that means they’re basically already shut down almost all the time.
Anyway, I strongly recommend jumping on the Arc Editor beta: Arc Editor public beta 15
The new Arc Editor app is a ground up rewrite, using all the latest technologies and techniques. While old Arc Timeline app is a decade of code, built for a decade of changing technologies and systems.
That means that Arc Editor is faster, more reliable, records better data. It’s also less likely to be terminated by iOS, as a result of those improvements. It can run for days or weeks at a time without being terminated. That means that the Arc Recorder companion app is less necessary.
I’ll still eventually be changing Arc Recorder to act as a backup for the new app. But for now it’s not a high priority, because iOS is much kinder to the new app.
Hi @matt , thanks for the detailed explanation!
I don’t think this is the case for all of them, at least not Wayward. While Wayward does not offer the polished UX of Arc, it does seem to be recording very granularly. Points are very tightly spaced, hugging the route as I would expect. I know because I use it to record my position to feed it into travemap.org’s timeline. I also tried using a Garmin InReach_2 device, which works much like you described - much too broad to be useful. It only samples waypoints every 10 minutes.
The combination of Wayward and travemap.org gives me the same timeline functionality of Arc, but makes it available on a website so I can share it with friends and family in real time (for a longer trip I am currently undertaking). Obviously, it is not a replacement for the other functions that Arc offers but for this case, that’s all I am interested in. I will continue to use Arc for my personal timeline.
1 Like
I just had a look at it, and yeah that one’s doing a proper job of it. It’s recording live, receiving the (presumably) full location data stream while it’s active. Nice.
The distinction there then would be more along the lines of whether it’s a 24/7 app or one that you turn on to record for a specific period of time then stop once you’re done.
Both of those kinds of apps have the same requirements in terms of having to stay alive: if it’s swiped closed or terminated by iOS it’s game over, recording stops and that data can’t be retrieved later. But they do get treated differently by iOS in a more subtle way.
That subtle way is in how iOS ranks or grades or “manages” the app. iOS is paying attention to how long apps are running in the background, how much the user is interacting with them (or not interacting), how much energy the app has used over 24 hours, 7 days, a month. We don’t know the exact score cards iOS keeps - those are largely Apple secrets. But we do know that iOS is keeping track of the apps, and deciding which ones are its favourites and which ones it hates. It’s trying to manage energy/resource use so that the battery lasts as long as possible, and battery isn’t wasted on badly behaved apps that the user doesn’t care about.
An app that’s running in the background for a few hours or half a day or some such then is stopped, that’s going to get away with it as long as it doesn’t do anything grossly badly behaved during that time. iOS will be fine with it. No nasty marks on the score card.
An app that’s running 24/7 in the background, over weeks or months, it’s a different story. iOS doesn’t want any app to do that - it’s the worst kind of offender in iOS’s mind. And this is where Arc has to live, in this high danger zone, permanently at risk of iOS getting angry and blacklisting the app.
So that’s where Arc Recorder comes in. If Arc does something iOS doesn’t completely love, and maybe does that enough times that iOS gets in a mood over it, it’ll start getting terminated. Background play time revoked. Then Arc Recorder can step in and take over. Arc Recorder basically has only that one single job: sit there quietly doing nothing, all day every day, until that one moment when it’s needed, because the main app made iOS angry and got in trouble. Arc Recorder then steps in, takes over recording, and the data gap is averted, the timeline recording continues unbroken.
The new Arc Editor app is still low profile enough (and modern and efficient enough) that I’m essentially never seeing it make iOS angry. They’re still good friends. So for now Arc Recorder as a fallback for Arc Editor isn’t a high priority. But eventually it might be, as Arc Editor gets more complex, does more things. We’ll see!
1 Like
Oh definitely have a look at @zzGordon’s Arc Reader! It’s absolutely fantastic, and web based.
Here’s an example of some of my Arc Editor data viewed in Arc Reader:
Oh he’s also built in some quite advanced AI functionality to it too. So you can ask AI to analyse your data, chart it, all sorts I think. I haven’t had a chance to play around with those bits yet, but it’s very cool stuff.
Hi @matt thanks for all of the explanations and thorough analysis of the problem. Arc Diary Reader looks like just the ticket. Now if it could also display photos and would allow adding comments, it would be a serious contestant to travelmap.net. In fact it would be my preferred solution as it would eliminate the need for yet another app. I’ll have a play though!
1 Like
Good news on the photos front! Looks like Gordon’s already on it: Possibly disabled samples/items are being included? · Issue #7 · gordon-williams/arc-timeline-reader · GitHub