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.