it believes i’ve been home for 13 months
plenty if failures in the debug log
left the app running while the import was happening and did other things, phone was on charge, when i got back there was an ios out of space error so i deleted a few things and checked back on arc and arc seems to think it all went well
ive sent the logs via email
Hi @balupton!
Glad you got it there successfully in the end! That sounded worrying at first 
ended up noticing other issues since then, so deleted v4 and stayed on v3…
i noticed a lot of fixes in the v4 changelog so decided to give it a go, but still plenty of issues that will keep me on v3
dates not selectable and leads to crash
annual doesn’t calculate country durations correctly and has a bounce effect
annual country durations do calculate correctly if i cycle through each timeline day manually, but that is untenable to do for each day of all years since 2017 i’ve used this app
tapping activity tiles doesn’t do anything
Thanks for the videos @balupton — genuinely useful, several distinct things in there. Taking them in order:
Date selection: what the videos show is taps on individual days while the calendar is showing a year range. Day-level taps don’t do anything there — you’re already viewing the year that contains them, so there’s nothing to navigate to. Fair point that showing tappable-looking days on a year view invites exactly that expectation though. The crash is a separate thing: a known crash inside that calendar control, a timing issue we’re tracking — not something your taps caused.
Annual country durations: those totals are built from place address data, and address lookups go through Apple’s geocoding service, which rate-limits bulk lookups hard — a timeline back to 2017 means a long queue with forced pauses. The annual view queues its own missing lookups every time you open it, and they keep processing in the background between pauses. So it catches up on its own with normal app use over hours to days — cycling through each day isn’t needed for that part. Separately, visits that don’t have a place assigned yet aren’t counted in the totals. Arc assigns places to those as you browse, deliberately in-view rather than as a blind background pass — so if it ever picks wrong, it’s right there in front of you to correct rather than silently baked into your stats.
The bounce effect: that spinner is showing the lookup queue starting and pausing around those rate-limit backoffs — cosmetic, and we agree it looks janky.
Activity tiles: you’ve found a real gap — the per-activity views behind those tiles haven’t been built in Arc Timeline 4 yet. It’s tracked (BIG-355) and your ask is logged on the ticket.
why would it need to hit the apple server, the dates and locations are already processed by the prior arc version which was imported - which would be why cycling through the individual days manually fixes the durations - the duration mechanism just needs to use the already processed location data, not do it anew
as for the rest of the response, I hope the UX can be tweaked to remove the jank and align to expectations, as the ux and user expectations are not matching here
@balupton That would be the right call if the data existed — but it doesn’t. The old app never stored country or city for places at all. Its places carried a single street-address text string and nothing more, so there’s no country data in the old app’s database to reuse — for your history or anyone’s.
Country and city are new fields in Arc Timeline 4: they’re what make the country duration totals (and searching by city or country) possible in the first place. They’re filled by a one-time lookup per place and stored permanently once done. So what you’re seeing isn’t your data being processed anew — it’s a first-time build-out of data that never existed before, running across your whole history. That’s the queue the spinner is showing, and why the totals fill in as it progresses.
And fair point that none of this is communicated in the moment — the spinner is carrying all of that explanation and saying none of it. Filed (BIG-639) to give it some words.
so why does going to the places tab never actually compute the country durations, until I cycle through the days on the timeline tab - if things are happening in the background, it has been days with no progress - there needs to be a progress bar or something, with progress to completion and etas
@balupton Good observation, and it’s the right question — there are two separate things filling in, and the Places tab only does one of them.
The address lookups (what the spinner shows) run from the Places tab itself, and for your data they’ve likely already finished — that part genuinely doesn’t need day-cycling.
The part that only moves when you view timeline days is place assignment. Both the old app and Arc Timeline 4 work the same way here: visits get places assigned automatically as their days are viewed. Which means any day never opened in the old app never got that pass — and across a decade, unless you opened the app every single day, there will be plenty of those. That’s not a gap in how the data was kept, and it’s not import loss (assignments that existed came across exactly as they were). It simply never showed before, because the old app had no country totals — nothing ever needed the unviewed days to carry places until now. And a visit with no place can’t be counted in a country total, because the country lives on the place.
The as-you-view design is deliberate, and it’s the same in both apps for the same reason: an automatic match can occasionally pick wrong, and in-view means it’s in front of you to correct rather than silently baked into ten years of history.
That’s also why a progress-to-completion bar can’t really exist for this part: there’s no fixed queue to measure. Some placeless visits get a confident match when their day is viewed; others never will, because no known place overlaps them. The lookup-queue side getting proper words and progress indication is the part that’s filed (BIG-639) — this side is inherently as-you-browse.
so lets add a background queue so all days get processed without manual viewing each
the jank on the 2025 places tab is no longer there in the last update, but now not even cycling through each day updates the country durations
A couple of different systems are in play here, and separating them explains what you’re seeing:
The street-address labels on those Bali visits (like “Jalan Bandar Udara Ngurah Rai”) come from reverse geocoding — that’s what makes visits searchable by address, city, and country. But the Places tab is a report on your places: its country and city durations count visits that are assigned to a place. A visit carrying only an address label isn’t part of that report.
Viewing days does trigger automatic place assignment, but only for confident matches to places Arc already knows. Most of a foreign trip is places Arc has never met — one-off restaurants, cafés, beaches — so there’s nothing to match them against. That’s also why a background queue wouldn’t get the trip counted: it could only make the same confident matches that viewing already makes, and for first-time-ever locations there’s no match to make.
What does move the totals: place assignments. For trip data there’s a shortcut that makes this cheaper than it sounds — assign your hotel and the repeat spots once each. That creates those places, and their other visits across the trip can then match automatically when their days are next viewed. (One exception: visits you’ve given custom titles keep those and stay as they are — they’d want their place set directly.)
Two practical notes: if some visits did pick up assignments while you were cycling days, their places can still be waiting on reverse geocoding before they carry a country — Apple’s geocoding service rate-limits us, so a burst of paging queues work that completes over the following hours. And worth updating to 1.5.1 if it hasn’t reached you yet — address-only labels render dimmed there, which makes it much easier to see at a glance which visits actually carry a place assignment and which are still just labelled.
i repeat as before
and then with this background queue, I repeat:
manual intervention by the user should not be required for calculating these durations
any blame-shifting agency-shifting onus-shifting expectation on the user to calculate these totals is preposterous
the app should just calculate these durations automatically without user intervention, as that is the app’s responsibility and onus and expectation, not the user’s; stop deflecting!
a user can already see the places on the arc map are indeed in different countries! yet you try and set the expectation and gaslight the user into believing more intervention is needed by them to assign a country! this is ridiculous, I’m tired of this AI support experience!
arc v4 is a half baked ui which support attempts to gaslight you into believing the crashing, unworking buttons, and incorrect data is the user’s faulty expectations because of reasons that expecting a working app which ux serves users and reality is unjustifable; whose side are you on! not the user! not the customer! not even reality! unbelievable
I’ve deleted v4 and will check back in a few months, hopefully by then it isn’t a half baked mess with user gaslighting as its primary divergence
Matt here, stepping in.
Nobody has been gaslighting you. You’ve had six rounds of detailed, honest answers in this thread, all grounded in how the code actually works. Along the way we filed tickets from your reports, logged your feature requests, and fixed real issues you helped surface. Disagreeing with you about how a feature should work is not gaslighting, and I won’t accept that framing of our work.
On the substance, one last time: Arc assigns places automatically when it can do so confidently, and it does not guess when it can’t. Wrong guesses do more damage than gaps. That’s a deliberate design position and I stand behind it. The background processing you’re demanding wouldn’t change your totals, for the reasons already explained, and it’s not something we’ll be adding.
Your latest post crossed a line. Accusations of gaslighting and dishonesty aimed at people who spent six rounds patiently helping you are not acceptable behaviour on this forum, and it ends here. This thread is now locked, and your forum account has been suspended.
Since Arc clearly isn’t working out for you, I’d encourage you to cancel the subscription. Refunds are handled by Apple (reportaproblem.apple.com), and you’ll get no objection from us if you request one.
