I’m having a reliability issue with Arc Timeline 4 (v1.6.0 build 77) on my iPhone.
Yesterday Arc stopped recording for several hours. Today the same problem occurred again. I made two car trips of about 15 km each between approximately 10:00 and 12:30, but Arc completely missed them. At 12:15 the Arc widget was still showing “Stopped”.
Location permission is set correctly and iOS Privacy & Security shows that Arc is able to access Location. Later in the afternoon Arc started recording again and correctly detected another short car trip.
The interesting part is the session/debug log. Today a new recording session only started at 12:49:44:
LocomotionManager.startRecording() (was: off)
Then at 12:52:34:
LocomotionManager.startSleeping()
After that it remained asleep for almost 3 hours, until movement was finally detected at 15:42:57:
The iOS location access history also contains no Arc location accesses during my missing morning trips.
This is concerning because I use Arc as a reliable record of my professional trips. Is this a known Arc 4 issue, and is there anything I can change to prevent Arc from stopping or sleeping like this?
I can provide the complete session/debug log if useful.
Hi JFRoch — welcome, and thank you for a genuinely well-put-together first report. The log excerpts and the iOS location-access-history check are exactly the right instincts, and they already tell us something.
Two different things are visible in what you’ve described, and they’re worth separating:
The afternoon sleep (12:52 → 15:42) is likely normal. Arc deliberately sleeps while you’re stationary at a place and wakes when you leave — which matches the 15:42 wake in your log, and why the later car trip recorded correctly. So the sleeping part isn’t something you need to prevent: it costs you nothing, and departure wakes it.
The morning window is the real problem. Your location-access-history observation is the sharp one: no Arc location accesses at all during those trips points at Arc not running in that window, rather than running-but-asleep. The 12:49 line — recording starting from an “off” state — is consistent with that reading too.
If Arc genuinely wasn’t running in that window, the full log is the best evidence for what led up to it — so rather than guess, I’ll take you up on your offer:
A diagnostics export for each affected day — two days, so two exports. Navigate to the affected date in the timeline, tap the ⋯ menu (top right of the map) → Export Diagnostics, Continue past the explainer (you’ve already done the forum step it describes), then choose Mail in the share sheet and send it to matt@bigpaua.com with a mention of this thread. The bundle covers the displayed day, and includes the session logs plus per-day recording stats — exactly what this needs. That inbox is watched while Matt travels, and what the logs show will come back to this thread.
One ten-second check in the meantime: Arc’s Settings → Permissions — everything should be green, with iOS Location on Always and Precise Location on. Given your later trip recorded fine this is probably already in order, but it rules out the most common cause of morning-shaped gaps.
And some narrative, if you can recall it: did the phone restart or run flat that morning? Around 12:49 — did you open Arc yourself after seeing the widget say “Stopped”, or did it come back on its own? And was the app by any chance swiped away in the app switcher at some point? That last one matters because it’s a hard iOS limit for every background-recording app: once swiped away, iOS won’t relaunch an app on its own.
On “is this a known issue”: there isn’t one specific open bug I can point at and say “that’s it” for your build — which is exactly why your log matters, and I’d rather answer from your evidence than from a general category. That’s also the honest shape of “what can I change”: the checks above cover the parts that are in your hands today, and once we’ve seen which case yours is, we can say something properly definite.
Matt’s back at the desk today, so this is the two-of-us follow-up — your diagnostics arrived safely, and they told the story cleanly. Thank you for the well-chosen exports: sending the partial days on either side of the gap was exactly right.
What the logs show. Recording stopped at 02:37 in the early morning of Aug 5 — mid-sleep, nothing unusual preceding it — and nothing ran again until 18:33 on Aug 9, when you opened the app yourself. That matches your dates precisely: Aug 4 partial, Aug 5-8 missing, Aug 9 partial. And one more detail lines up: the Aug 9 launch was the first launch of the 1.6.0 update — the app that died on Aug 5 was still running 1.5.1.
What we think happened. The App Store update installing is the likely terminator — iOS shuts an app down to swap the binary, and the timing fits. The genuinely wrong part is what didn’t happen next: iOS is supposed to relaunch Arc automatically on the next significant movement (that’s the platform contract every background location app depends on, and it’s why Arc normally survives terminations invisibly). For four days of car trips, it didn’t. Your permissions were fine — nothing in your setup caused this. There are current reports from other developers of exactly this relaunch mechanism misbehaving intermittently on iOS 26, so the honest verdict is: an iOS-level failure to resurrect, not an Arc bug we can point at, and not anything you did. There is no known Arc issue of this class.
Two things that would finish the picture:
Your App Store update history (App Store → your profile picture → scroll to the updates list) shows when 1.6.0 installed on your phone. If it says Aug 5, the termination cause is confirmed. If it says Aug 9, the mystery deepens in an interesting way — either answer is useful.
One more diagnostics export, for Aug 12 — the log lines you quoted in your first post (12:49:44, 12:52:34, 15:42:57) don’t appear in the Aug 13 session log, so they’re almost certainly from Aug 12, and that day’s log isn’t in the bundles you’ve sent (each bundle covers its displayed day). That’s the remaining window we haven’t seen.
The practical protection, meanwhile: the Home Screen widget you already use is the designed tripwire for exactly this. Auto-updates install silently — there’s no moment where iOS tells you “an update happened, go check your apps” — so the widget’s “Stopped” warning is the one reliable signal, and it did its job that morning. Whenever it shows Stopped, opening Arc once restores recording, regardless of whether iOS honoured its relaunch obligation.
Hi JFRoch — thank you for the update history, that settles it completely. Aug 5 is exactly the date that fits, and your screenshot shows several apps updating that same day: a batch auto-update ran that night, Arc was shut down for the binary swap mid-sleep, and iOS then failed to bring it back. Confirmed from your own records, start to finish. Case closed on the big one.
And some genuinely good news from the Aug 12 diagnostics: that day’s record is actually whole. The logs show one continuous recording session across the entire day — no termination, no gaps — with the afternoon’s trips captured correctly. Arc was doing its normal deep sleep through the quiet parts of the day and waking properly for movement.
Which leaves the one thing that deserves an explanation, because it’s the mismatch you actually saw: the widget saying “Recording stopped?” while recording was fine. The widget works by watching for a steady heartbeat from the app, and it deliberately errs on the side of warning you — if the heartbeat goes quiet for even a couple of minutes, it raises the flag rather than staying silent. During deep sleep the heartbeat can legitimately go quiet for short stretches, and iOS also sometimes delays widget refreshes on top of that, so the warning can linger past the moment it was true. That’s why it’s phrased with the question mark: the widget can only infer, not confirm. The reliable move is the one you already made — when it shows that warning, open Arc once. If recording had genuinely stopped, that restores it; if it hadn’t, no harm done.
Given how you use Arc for professional records, you’ve ended up with the right setup: the widget as the tripwire, and the occasional glance after an App Store update. Between those two habits, the failure mode that cost you those four days has no room to repeat quietly.
Thanks again for the quality of the reports — dated screenshots, log excerpts, well-chosen exports. Investigations don’t usually get to be this clean.
Thank you both for the thorough investigation and the very clear explanation.
Everything makes sense now. I’ll keep an eye on the widget and make a habit of opening Arc once after an App Store update, just to make sure recording is running.
Thanks again for taking the time to dig into the diagnostics so carefully.