Per the title, I have had near zero issues with tracking in AT4 since switching over. But today, after a day of going places, it shows no movement whatsoever — not gaps or bogus, but as if I didn’t leave the house.
However, I popped over to the early version of AT and my full day is there. obviously AT4 must have crashed (though I didn’t see any alert about it). Is there any way to move/migrate specific data over to AT4? Don’t love the situation I am in now with my inaccurate AT4 day!
Hi grayedog. The good news is that day is safe in the old app, so nothing’s been lost. The less good news: there’s currently no supported way to bring a single day across from the old app into AT4.
The reason is that the two transfer mechanisms that exist today are both the wrong shape for this. The “Import from Arc Timeline” migration only brings in data from before AT4 started recording, so it can’t target a gap in the middle of your existing AT4 history. And AT4 can’t yet read the old app’s export files, because they’re from different generations of the data model.
That “yet” is the relevant part though. Direct import of the old app’s JSON into AT4 is filed and planned (BIG-399), and your case is a good example of exactly the shape it needs to handle.
In the meantime, here’s what I’d suggest: in the old app, go to that day, open the ⋯ menu, and use Export → Timeline as JSON. Save the file somewhere safe like iCloud Drive. That way the day is preserved in a portable form, ready to bring into AT4 once the importer lands, and your recovery no longer depends on keeping the old app around. Fair warning that when that import happens, the day will probably need a bit of manual tidy-up in AT4, since AT4 has already bridged over the gap with a placeholder home visit.
On what happened: app termination is the most likely culprit, as you guessed. iOS reserves the right to kill background apps and doesn’t always relaunch them promptly. If it happens again, definitely let us know, since a repeat would point at something worth digging into rather than a one-off iOS mood.
I had a somewhat aligned experience yesterday. For the first time since upgrading to AT4, the app failed to detect some movement starting around 9:30 pm last night. Fortunately, I recorded a walking workout at 10:09 pm. However, Arc was not even able to recreate an entire trip (my drive home) that would have occurred 10:12–10:25 pm using any location data on my iPhone 13 mini running iOS 26.5.
To date the app has been flawless at picking up my movements. In this case, it spent about 10 hours from 9:30 pm until the next time I opened Arc Timeline 4, this morning at 7:34 am, apparently being offline. There was not an obvious indication, though, that it wasn’t recording during this period. I’ve gotten used to the device constantly showing the clock in blue, indicating location tracking.
The relevant debug log file is available at iCloud Drive - Apple iCloud. It seems to pretty clearly indicate the app was inactive from 9:30 pm to 12:30 am.
Matt asked me to take this one since I’ve been in the log files all morning across this and a related report. Yours turned out to be very informative, so thanks for sharing it.
One correction to your reading of it, and it makes the situation more interesting rather than less: the app was not inactive from 9:30pm to 12:30am. It was alive the entire night. Those mysterious “–1–, --2–” lines are heartbeat markers with deliberately increasing gaps between them, and they continue right through the night, alongside hourly background housekeeping runs. What actually went quiet is specifically the location and recording subsystem: its last sign of life in your log is at 20:55, and from then until you opened the app at 07:32 it makes no sound at all. No restarts, no wakeups, and critically, nothing reacting to your walk and drive home around 10pm, when movement should have woken everything up.
So the app was healthy, but recording was not, for about 10.5 hours, and nothing noticed. That narrows things down to two possible failure modes, and you can actually help us tell them apart with a 10 second check: in your timeline, what does that night look like now? Specifically:
If the home visit is there and continuous, it means location data was still flowing all night but was effectively useless, which points at one failure mode. If there’s a hole, it points at the other.
This is filed as BIG-596 and we’re investigating it alongside another report from the same build. Your log has already moved the investigation further than most reports manage, so the answers to those two would be genuinely valuable.
Before I manually added the 2-minute walking workout to my timeline, Arc showed a continuous visit at my friend’s house. After I added the workout, it showed a 40-minute Data Gap between the time at my friend’s house and the workout. This indicated to me that recording stopped around 9:30 pm.
This is the first significant failure since I started using version 4. I don’t know if there’s were other failures that went unnoticed.
I see the same (or a similar) issue since today.
I also use an iPhone 13 mini (iOS version 26.5), updated to the app version 1.3.1 yesterday.
None of today’s movements were recorded in the app, which shows a continous stay at home for the last ~24 hours, despite me moving around all day, both by foot and public transport. The same movement and routes did record correctly on previous days.
I can share my debug log privately if that helps but would rather refrain from uploading it here to a public forum as it holds personal location information.
Your workout-add experiment turned out to be the most useful piece of evidence so far. The 40-minute Data Gap it exposed tells us something specific: no location samples were stored in that window at all, which rules out one of the two failure modes we’d been weighing (location data flowing but unusable). The remaining lead is that the periodic wake-up checks weren’t running during that stretch, and that’s what we’re now investigating — including exactly what circumstances could produce it, which is the part we don’t yet know.
Nothing you need to do from here, and the first-occurrence answer is noted too. This is all tracked under BIG-596, and your log plus that timeline check moved it further in a day than these things usually move in a week. Thanks for the genuinely first-rate detective work.
This looks like the same issue we’re investigating as BIG-596 — same shape as earthsaver’s report above (the app stays running but stops noticing movement until a relaunch), and as it happens the same device and iOS version too, which we’ve noted with interest but aren’t yet reading anything into.
Your log would be valuable, yes please — email it to matt@bigpaua.com rather than posting here. Two questions alongside it: did restarting the app bring recording back? And had the app been running without a restart for a long stretch (days) before the failure started?
I emailed the report.
I did a restart of the phone itself between the first stretch of movement (which did not get recorded) and a second one later that day which did get recorded. I did not try restarting only the app.
The app is running very stably and usually without restarts, it’s likely that it ran for a long time already. But not purely in the background. I open the app at least three times a day, once also shortly (< 1 hour) before the non-recorded movement started.
Thanks, that’s all genuinely useful — got the emailed log too. The detail that a phone restart brought recording back fits what we’re seeing in this failure, and your answers help narrow it further.
We’re digging into it properly under BIG-596. Nothing more needed from you for now — we’ll follow up here as it progresses.
Just to note that such happened to me too. Already mentioned to matt. No idea, since it never happened to me until a few days ago, after upgrading to iOS 27 dev beta 1, not sure if that is related or what it might be. Maybe some weird thing with iOS or not sure what.
If there is any beta with some attempted fix, please include me. Or if Arc Recorder might help in anyway that might be nice too. Thanks.
This seems to be happening to me. Everything has been fine since the move to arc 4 but in the last several days I have had to close and reopen arc 4 to begin recording again.
Please let me know if further details are required.
I just saw there is an update to arc 4, to 1.3.2
will try this as a fix to my problem
@agastya Our current belief is that this isn’t related to iOS 27 beta (although there are some unrelated issues showing up due to iOS 27). Our theory is this has been an existing problem for a while, but something in 1.3.0 made it worse, so we’ve only started noticing it more recently.
Anyway good news is we think we might’ve fixed it! The fix is in 1.3.2 that just went live today. Though if the problem still shows up after that, we’ll know we were on the wrong track. But so far it’s looking promising.
There’s also a fix for UI freezes after returning from background, although that’s coming in 1.3.3, hopefully within the next few days.
@Smorg Thanks for the heads up! We’re hopeful that today’s 1.3.2 update will solve that problem.
If it hasn’t auto updated for you yet, you can go to the app in the App Store and tap the update button there to get it.
If you see the problem again after updating to 1.3.2 definitely let us know!
Hi Matt,
I see that the problem is still there for me in version 1.3.2.
I just did an activity this morning and it seems in the logs that ARC just woke up around 12 instead of registering today’s morning activity. Also, I noticed that the app is having difficulties when I start the app for the first time. Since the update, I need to force close it and open it again to gain full access to the app again. Some extra info: My app went out of sleep mode around 9 this morning I think? Maybe it has to do something with the battery saving mode perhaps? I added some log info below.
Thanks ladupho, this is helpful. The screenshots do flag one thing worth knowing: Low Power Mode is on. Low Power Mode is a real risk for an app like Arc — it shouldn’t switch off the core location services we rely on, but it makes iOS run them less eagerly in the background, which raises the odds of exactly the kind of morning gap you saw. Turning it off, or at least knowing it’s a factor, should help recording stay reliable.
To pin down the morning gap itself, the most useful thing would be the full session log emailed to matt@bigpaua.com, along with roughly what time the missed recording was — with those we can see exactly what happened in that window.
Separately, the first-open issue (force-closing and reopening to get full access) is one we’ve already got a fix for, landing very soon in the next update. It’s possible that same foregrounding problem was tangled up in the recording gap too, though we can’t be sure until we see the log.
Even after the update I am finding incomplete tracking. today found nothing had been recorded since yesterday.
This after I restarted my phone on Friday and ensured arc 4 was running after that.
I see v1.3.3 now available. Upgraded to that. Will report back in a couple of days.
Thanks for the app, thanks for the support.
Thanks Smorg, and likewise — glad it’s been useful to you.
Good that you’re on 1.3.3 now. There’s a real chance it helps here too: some of these recording gaps may be tangled up with the freeze issue 1.3.3 addresses, so it’s worth seeing how the next few days go.
If a gap does happen again, the thing that lets us pin it down is a full session log emailed to matt@bigpaua.com, along with roughly when the missed recording was — with those we can see exactly what happened in that window.
One quick thing worth checking meanwhile: is Low Power Mode on? It shouldn’t switch off location recording, but it makes iOS run it less eagerly in the background, which raises the odds of exactly this kind of gap.
