• Import GPX files. Bring routes, workouts, and old exports into your timeline: open a GPX file from the Files app or a share sheet, or use the new Import GPX File option on the timeline view. You can adjust dates and timezones before importing, existing timeline data is safely set aside when an import overlaps it, and any import can be removed again later with everything restored exactly as it was. (BIG-204)
• Background recording without the persistent location indicator. Arc no longer keeps the location indicator lit while recording in the background. (BIG-617)
• Further improvements to recording on underground trains and metros, plus a fix for out-of-order location data that could distort recorded paths. (BIG-607)
• New Export Diagnostics option on the timeline view. If a day ever looks wrong, it packages everything we need to investigate into a single file you can send us. (BIG-626)
• Arc’s documents folder is now visible in the Files app (On My iPhone, Arc Timeline 4).
Yeah, super pleasing to have that finally resolved! No more location indicator overtaking the Dynamic Island!
There’s been a couple of new competitor apps arrive recently (one of them I kinda like!), both with no location indicator. The dev of one of them partially described how they did it, so that triggered a hunt to see if their approach actually worked. Spoiler: no it didn’t, and likely that dev is using the built in iOS systems that are too low accuracy for Arc’s needs, and would result in worse data quality.
But once we were in there experimenting, even after the first failed experiment, we figured why not stick at it. See if we can find another way. Which led to a series of partial successes over a week or two, culminating with eventually the right combination of tricks that got us to the final result!
The problem with the workaround old Arc Timeline 3 used is, well there’s three parts:
Reliability - the app has to be able to stay alive, otherwise it’s game over
Energy use - battery can’t drain faster than usual, otherwise again, game over
Data quality - the timelines and paths should be just as accurate as without the hack, otherwise… game over
We experimented with reworking the old app’s hack, and found that with the right combination of settings we could achieve 1 and 2 - reliable, and battery use same as usual. But data quality was the final sticking point - it just wasn’t as good as when the indicator was showing.
Apple force us into some undesirable location settings, if we turn off the location indicator. They make the data worse. But we kept experimenting, and finally settled on a combination of the old app’s hack and the new app’s better settings, working in parallel, and crucially: not stepping on either other’s toes. And then, all three conditions met!
Ah yeah good catch! Someone on the private beta team found that too. It should go away within minutes after the update, but sometimes nope, it sticks around. But as you say, rebooting the phone fixes it.
Sounds good. I have no idea but I suppose you do, that if it is indeed a so called hack if it is something dependent on non-official APIs that could perhaps change anytime thus break with some future iOS.
Related to a previous mention of mis-assigned locations and so forth, as I use other features such as search, Place Details, Total visits, and so forth, I thought I’d mention again for visits, the full address including city sure would be nice to be shown everywhere or nearly everywhere even if only as optional setting : day view, list views such as search or future lists, visit details, place details, etc. Don’t many of us move around in multiple cities – even in one day --, thus such really helps ?
I think you are aware and perhaps have already thought about it and experimented; perhaps there are ways to change information density, layout, etc. to make such possible while also taking up the same amount or less space (maybe) while being clear. One example from Fantastical :
I understand perhaps many want specific features from 3.x. yet me maybe I just use the main features, using such like a calendar or diary, and am more concerned with UX, experience, and so forth.
On the fragility worry: there are no non-official APIs involved. Everything the new approach uses is standard, public CoreLocation API — and the core technique actually came to us from Apple themselves, via their Developer Technical Support, some years back. What held it back all these years was never its officialness: it was that using it cost too much in reliability and data quality. That’s what this round of experimenting finally solved — the same sanctioned technique, in a new arrangement that keeps recording quality at full strength. Apple can always change how things behave in a future iOS (true for every app on the platform), but this isn’t an undocumented trick that breaks without warning, and we’re already testing against the iOS 27 betas as they arrive.
On addresses: the honest sequencing is that street addresses first have to exist on visits before they can be shown anywhere. Right now they only exist on places, and on older visits imported from Arc Timeline 3 — new visits in Arc Timeline 4 don’t get their own street address yet. That groundwork is already filed and high on the list (BIG-455), and your voice is now counted on it.
Once that lands, where to show addresses becomes a screen-by-screen question. Search results is the clearest case — an address line there helps distinguish similar results, and it’s the most likely first home (BIG-502). Beyond that we’ll look at it view by view, weighing the value in each spot against information density. The multi-city framing is a fair one.
Oooh, I’ve been wanting this for a long time! GPX partial import!
I have a bunch of flights that didn’t record properly.
I have a Flight Radar 24 subscription, so can download KML and CSV files there for individual flights.
I just played around a bit, and got it working. I spoke with Gemini, and as expected, it fucked it up majorly. It was determined to try some online converters of KML or CSV, but the results were horrible.
Claude got the solution: suggesting it could write a python script to convert direct to GPS. That worked just fine. It also offered to, and did, just run the conversion itself. That was helpful with one case where Arc commenced tracking after I turned airplane mode “off”, but the initial location data was wrong and put me back out in the middle of the airfield. Claude just extended the stop time for the track from FlightRadar, to overwrite the erroneous Arc track. I just told it what time Arc gained a correct location lock, and Claude ended the GPX time there.
@elucubrator That’s a clever rescue of the airfield mis-lock, and a nice recipe for anyone else wanting to backfill flights from Flight Radar 24 exports.
Worth mentioning: direct FR24 import is on the list as a planned feature (BIG-454). No promises yet on which release it lands in, but posts like yours help it along. In the meantime your KML to GPX conversion workflow is a solid interim path.
I used CSV to GPX, not KML, as CSV has all the timestamps for each location ping. (Apparently, FlightRadar returns a location result between ~2 seconds during taxi, to ~15 seconds during cruise!) FlightRadar’s KML export omits those timestamps — it’s just a line on a map with no timing data — so Arc can’t interpret it as a timeline entry, and I ended up with thousands of individual data points!
I’ve been at a mercy of auto export not running for the last 25 hours
(and yes, my phone was plugged in last night although it may have been tracking my sleep which is probably why the phone didn’t clear Arc for background auto export)
@k4869 Good news: manual “Run now” buttons for the auto exports are already ticketed (BIG-568) and committed for the next update. It’s a small piece of UI on top of machinery that already exists, and your voice has been added to the ticket.
As for why last night’s window got skipped: probably not sleep tracking. The exports run as an iOS background task, and iOS grants those windows on its own opaque criteria. Charging and idle are the big ones, but they’re necessary rather than sufficient, and occasionally iOS just declines a night for no visible reason, then catches up the next. Frustrating, and it’s exactly why the Run Now buttons are coming: no more waiting on iOS to feel like it.
The Home Screen widget is showing “Recording stopped?” after rebooting to get rid of the indicator in the Dynamic Island. Could the new background location tracking technique have broken the widget somehow?
Update: after launching Arc 4 from the Home Screen and letting it run in the foreground for a few seconds, the Home Screen widget is now showing my current location again. Something not quite right about that being a necessary step after device restart, though.
Hi! Great News with GPX Import! I have tried to fill some of my old data gaps and it seems to work. However it’s only a line I will probably have to cut out manually the places and routes?
I have one more specific question however. I tried to integrate a fox route, which went over a longer distance and days. It partly overlaps with the Arc record. Is it possible to not only replace the arc-recorded routes, but only import the parts that don’t overlap? Here is a preview of such a gpx, one with the preview of the new gpx (line) and one of the old arc recording. It would be fabulous if I could only import the gaps.
In any case, this is a fantastic new feature and this brings me to my oldest GPS recordings, which were saved in CSV only if I use a gpx converter, it doesn‘t seem to work.
Can anybody recommend me a tool how to convert a CSV ( with lat, lon, alt, date) into a gpx? I would be grateful!
I asked it how I could convert CSV to GPX, and it said it could do it (which it did).
Or it could write me a python script that does the conversion. It also did that, and I set up a Hazel rule which takes a CSV file that matches the FlightRadar naming convention (Airline code - flight number) and then runs the script which converts to GPX and moves the CSV to trash.
What I found helpful was to explain what the data was, and what I was trying to do with it.
Once Claude knew the data’s provenance, and that it purpose was a GPX import to Arc 4 (it even went and read the support pages for Arc to get across it) it identified things like needing to know if timestamps required conversion to/from UTC, whether records are imperial or metric. Once it knew those things, it wrote the script for me.
I can share my script if you want, but it seems to me that everyone would need a different one, because the source data might differ. (Is a ‘fox route’ a particular brand of GPS tracker? Or are you actually tracking a fox? ? I guess you might have height data which may or may not be relevant to a track?)
But literally, the easiest way to get Claude to figure out what you require is to chat with it and discuss: let it do the heavy lifting and it will give you the conversion you need.
@sentience First up, no need to worry! It probably was already doing what you were hoping for. It’s just a matter of it being on iOS’s timelines, a case of “yeah yeah I’ll get to that when I feel like it”.
Because Arc uses the “significant location changes” service as a safety fallback, it gets automatically restarted after automatic app updates in the background, and also after phone reboots. iOS will send it a fresh location update after those events, which gets it going again. But as to when iOS delivers those? In my experience, actually quite timely! Often I’ll go to open the app after rebooting and find it already alive. Though not always. I’d put it at … minutes, not hours.
And for the widget, that’s again in the iOS zone of “oh you want me to update that? sure sure, I’ve left myself a note. I’m on it - promise”. And then the actual widget update arriving minutes to hours later, depending on what kind of mood iOS is in on the day
From what you describe, it sounds to me like you’d got Arc back up and running, but iOS hadn’t got to the widget update yet. Then foregrounding the app gave iOS an extra kick, to which it went to “fine fine, I’ll update your widget now. what’s the fuss?”
Oh, so that does mean actually that sometimes the widget might say “recording stopped?” but Arc is fine. Though if that is the case, then it might mean that Arc was stopped at some point prior. So yeah, still always worth tapping through to check, if the widget ever says that. It’s still a useful warning signal, even if we can’t trust that iOS is updating things as timely as we’d like.
Thanks @dagguet — great to see the import doing its job on real gaps, and the screenshots made the ask clear.
Taking your three questions in order:
Places and routes: your file looks to be a single track, and a track only carries the path itself — no information about where you stopped — so it imports as one long trip. But there’s a purpose-built tool for exactly this situation: open the imported trip’s details and tap the map pin button in the bottom toolbar (icon only — a little , just left of the ⋯ menu). That opens “Kurzbesuche extrahieren”, which scans the trip for visit-shaped clusters and lets you extract them as visits — it should get a multi-day track back into sensible shape without tedious manual splitting.
Importing only the gaps: when a file contains multiple separate tracks, you can already get this at import by deselecting the rows with the red “overlaps” badge. Your Iberica tour is a single continuous track though, and partial import of one track isn’t currently supported. It’s a good ask — filed (BIG-636). In the meantime there’s a workable path: split the GPX into pieces outside Arc (per-day chunks work well), then import and select only the pieces that fill your gaps.
CSV→GPX: elucubrator’s answer is exactly the approach I’d recommend (admittedly I may be biased). Describing your data and your goal to an AI assistant and letting it write a converter script gets you something matched to your specific CSV format. Two tips for best results: point the assistant at Arc’s recording engine on GitHub (GitHub - sobri909/LocoKit2: A ground up rebuild of LocoKit · GitHub) so it can see exactly what Arc expects from imported data, and make sure the conversion gets timestamps right — every point needs one, in UTC (ISO-8601 format), with points in time order. That’s the difference between a clean import and a messy one. And conveniently, the same script can also handle the track-splitting from the previous paragraph.
Thank you, I will have a look at Claude for the CSV → GPX and will give it a try, to convert it with the AI assistant. I have never done this so we will see if it turns out well
For my longer GPX tracks I have imported, unfortunately back in the days I sometimes had huge data gaps of several days within my Arc. I used a second app called Pado, also to record my data. So this second app gives me CSV, KML and GPX tracks. However, one of them is e.g. 8 days long and was taken during a trip, so I can’t even do the thing with “Kurzbefehle extrahieren”, because I have never been in this area and also when I do this, it never gives me ideas of nearby places (I have written about it on a different topic here in the forum, that I have to type in the name veeeeeeeery accurately because otherwise it wouldn’t find it. and it never really proposes me nearby places, only places very far away.).
I think I will continue adding missing data to my Arc the day you have implemented BIG-636 and maybe some auto-correct or auto-extract or auto-recontruct-proposed-locations of these imported GPX files. Or maybe by the GPS in my photos? That would be fabulous!
Just fyi, this is how my longer recording of 8 days look like:
Thanks for the screenshots @dagguet — the second one deserves a proper explanation, because the tool isn’t misbehaving. It found nothing because there’s genuinely nothing of that shape in the file.
“Kurzbesuche extrahieren” works by scanning the trip for clusters — consecutive points sitting within a few metres of each other. When Arc records, it keeps a steady trickle of points flowing even while you’re stopped, so your stops show up as dense clusters the tool can find.
A tour recorder like Pado almost certainly does the opposite: it records only while you’re moving, and thins out points that sit close together, to keep files small. So in an 8-day track, your overnight stops exist as gaps in time between points, not as clusters of points. That’s why it showed “0 von 0” — the stops aren’t in the data, so there’s nothing to extract. And unfortunately the same limitation applies to any automatic reconstruction: it can’t recover stops the file doesn’t contain.
But there’s a nice trick available to you, since you’re already planning to have an AI assistant write your converter script: those time gaps are the stop information, and the script can use them. Describe the need to the assistant — something like “where there’s a long time gap between points, fill it with a small cluster of points at the stop location, spread across the gap” — and then “Kurzbesuche extrahieren” will find those stops and turn them into proper visits, with sensible start and end times. (The script could instead insert GPX waypoints, which Arc imports as visits automatically — but a waypoint is a single instant in time, so those visits arrive without any duration. The cluster approach gives better results for stops like your overnight stays.) And the same works for your existing GPX files too, with a small script that just adds the clusters to them.
The photos idea is a lovely one though — photos carry exactly the location-and-time information that’s missing from tracks like these. No promises, but there are some fun directions to think about there.
@k4869 That Run Now button just shipped — 1.5.1 is live on the App Store. Settings → Backup & Restore → Run Exports Now. No more being at the mercy of iOS’s overnight moods for your GPX.
? I guess you might have height data which may or may not be relevant to a track?)
, just left of the ⋯ menu). That opens “Kurzbesuche extrahieren”, which scans the trip for visit-shaped clusters and lets you extract them as visits — it should get a multi-day track back into sensible shape without tedious manual splitting.
