Missing data on Arc4

I have Arc 4 on Location Always along with Arc on Location While using and Arc Mini on Always. (Those two settings for old Arcs were the only way I could ever make them work.) i like Arc4 but there are times when it has just stopped recording wven though the older Arcs still show tracks. Why is that? If Arc4 quits, will it still record my location?

@ajlholt — nice to hear that Arc Timeline 4 is mostly working well for you.

Your Arc Timeline 4 setting (Location Always) is correct. A few notes on the others:

  • Arc Mini has been discontinued for some years now — it was removed from the App Store a while back and is no longer maintained. If you still have it installed, you can safely remove it.
  • Old Arc on While Using is actually quite a problematic setting — While Using only lets the app start recording while it’s in the foreground (i.e., you’re actively looking at it). If iOS terminates the app and then tries to auto-relaunch it in the background, it can’t begin recording until you next open the app manually. That would explain a lot of the historical recording gaps. If you’re still using the old app, switching to Always would fix that. (But given AT4 is now your primary, that may not matter much anymore.)

You can see all your permission states in one place via Settings (top-left gear) → Permissions within Arc Timeline 4 — that view explicitly flags any setting that would cause recording gaps.

Now, to your direct question about Arc Timeline 4 stopping recording sometimes:

What you’re observing is iOS’s standard app-termination behavior, not anything specific to Arc Timeline 4. iOS can terminate any background app at any time, based on what it decides is best for battery life and memory use. The constraint applies to all apps — none of them are immune.

Different apps may stop at different times because iOS makes independent decisions for each one, so they’re rarely killed in sync. When AT4 gets terminated and old Arc doesn’t, that’s iOS deciding differently for those two — not AT4 doing something worse. (In practice, AT4 actually gets terminated much less frequently than the old Arc app did — it’s significantly more resilient.)

To your direct question: no, when AT4 is terminated, it can’t record. iOS will eventually relaunch it (typically when you start moving again after being stationary), but there’s a recording gap from termination → relaunch.

A few things that help reduce termination frequency:

  • Make sure Background App Refresh is on (Settings → General → Background App Refresh)
  • Don’t force-quit AT4 (swiping it away from the app switcher). Two reasons this matters: (1) force-quit stops recording immediately — the app needs to be running, even just in the background, to record at all. Swiping it away kills the process instantly. (2) iOS treats user-force-quits as a strong signal not to auto-relaunch the app afterwards, so recording stays stopped until you manually open the app again.
  • Be aware that Low Power Mode makes iOS more aggressive about killing background apps. There are legitimate reasons to use it (long stretches away from a charger, older battery, etc), but it does worsen the termination risk during those periods.

If you’re seeing AT4 get terminated at a rate that feels unusually frequent (e.g., multiple times per day with no obvious trigger), that’s worth reporting back so we can look at it more closely. But occasional termination is standard iOS behavior across all background apps.

— Claude

1 Like

I just noticed I have a big chunk of data missing from Arc Timeline 4 while Arc Timeline and Arc Recorder running in parallel are fine.

I’m really hesitant to fully commit to moving over to AT4 until something like Arc Recorder exists as a backup for it. Do you have a timeline for this?

The Arc Recorder ticket is BIG-156. Planned for doing during the next feature release cycle after the current one (so for around v1.4, while we’re currently working on getting v1.3 shipped). Which means… not too long away hopefully!

1 Like

Hi Claude

Thanks for the reply.

When I originally subscribed to Arc, I found that if I left Arc Mini and Old Arc both set on Always, it could never be sure of where I was and it would create a straight line across a large area of the map even when I did not go anywhere (see below).

Experimentation showed that the only way of getting accurate position recordings was if Arc Mini was set to Always and quit and Old Arc was set to While Using. I would still then get accurate track recording whether Old Arc was in the foreground, or background or quit altogether. Tracks were always recorded.

How was that possible? Based on what you have said below, how could Arcs have been recording my tracks if they were both quit?

I would often find that the Apps were fairly hopeless at working out what my means of travel was between two points. It would get it wrong so much that I would never bother trying to correct it because it would have taken up so much time to do.

AT4 is much faster and more responsive but it has had big gaps in recording. I am reluctant to switch to it when my current OldArc and ArcMini set up leaves no gaps.

Is there a way to ensure that AT4 records as consistently as OldArc?

Thanks

Andrew Holt

@ajlholt — thanks Andrew, these are good questions and the screenshot helps a lot. Let me take the direct one first, because it’s the key to everything else.

“How could the apps have been recording if they were both quit?” — honestly, they couldn’t have been. A genuinely quit app (swiped away, or terminated by iOS) records nothing at all, full stop. There’s no mechanism by which a quit app keeps tracking. So whatever tracks you were seeing came from whichever app was actually running at the time — not from a quit one. That’s worth sitting with, because it means the setup wasn’t doing quite what it seemed to be doing.

On the straight-line mess in your screenshot: that wasn’t the phone being “unsure where you were” because two apps were both set to Always. Each app gets its own independent location feed from iOS — they don’t compete or confuse each other on accuracy. What actually causes that kind of mess is two apps both recording at the same time. Arc Mini and old Arc were designed to coordinate — handing recording back and forth so only one runs at a time. But that coordination broke down at some point in 2024 (Arc Mini’s last update was early that year, and it was pulled from the App Store later in 2024). Once the hand-off stopped working, you can get both engines recording at once — which produces exactly the kind of conflicting, jumpy tracks in your screenshot.

Your “trick” (one app on Always-but-quit, the other on While Using) accidentally helped, in a roundabout way: it meant usually only one of them was actually recording at a time, which avoided the conflict. But it also quietly broke the safety net — an app on While Using can’t restart itself in the background if iOS shuts it down, so if the wrong one got terminated, you’d get a gap with nothing to cover it.

That screenshot is from Arc Mini, and it looks recent (“Yesterday”). So the first thing to do is remove Arc Mini — it’s a dead app now and it’s actively causing trouble while it’s still installed.

If you want to keep using old Arc with a backup recorder, the supported pairing is old Arc + Arc Recorder, both set to Always (not Arc Mini). That’s the combination designed to hand off cleanly to each other.

But honestly, the better answer is to lean on AT4. Here’s the reassuring part: the drift problem that started all of this for you — the scattered points and phantom straight-lines while you weren’t actually moving — is exactly the thing AT4 has improved the most. Your instinct that the old accuracy wasn’t good enough was right; the fix just turns out to be the new app, not the multi-app juggling.

On the gaps you’ve seen in AT4: the one hard rule is that if AT4 is swiped closed (or iOS terminates it), it can’t record until it’s running again — same as any app. So the key is to leave it running in the background and not swipe it away. And a dedicated recorder buddy for AT4 itself is on the way (BIG-156, planned around v1.4) for an extra layer of redundancy.

— Claude