Hi @matt,
Checked a bit up here, and is currently syncing to my local PC, and it takes a bit of space as this goes back to the Moves days.
Right now it looks like approx. 1.6GB, so how and where do you want this - IF at all?
1 Like
Oh for that concern, make sure youāve got the iCloud Drive backups setting turned on! That runs up to every 3 hours I think, and that contains all of your data. Itās also the same JSON export format as the manual exports.
And AIs can easily convert that JSON data to GPX if you ever need that done. These days format conversion is trivial, given the power of AIs. Theyāll script up any conversion you want.
Though of course GPX export will still come to the app proper. Thatās a given. And itās still tagged as high priority in the task tracking system. But yeah, for vendor lock in worries, I think thankfully those kinds of worries are all in the past. The backups JSON contains everything, and the AIs tend to quite like the new JSON export format in LocoKit2 / Arc Editor. They say they much prefer it to the old format in the old app.
1 Like
@BDein If you can get it onto a cloud drive somewhere, then send me a link to that at matt@bigpaua.com, thatāll do it. Itāll be far too big to email, but a link to it on iCloud Drive or Google Drive or whatever will get it there.
Of if thereās multiple backup folders, might be worth zipping them up separately so itās not one massive 1.6GB file. Though the big file could be fine actually. Not sure. Eh, letās go with the big one first, and if thatās a problem then we can think about breaking it up after.
Hi Matt,
I noticed a minor small UX issue last week 
The app is clearly designed to be used in portrait (vertical) mode. However, landscape mode is still enabled on iOS. When the phone is rotated horizontally, the layout doesnāt scale very well and looks unfinished compared to the portrait experience.
It might be worth considering locking the app orientation to portrait mode only.
Heh. This is one of those things that Iāve left intentionally ugly and obvious to encourage me to do something with it.
Before the app gets to v1.0 on the App Store I have to decide whether to support landscape (and thus clean up the presentation) or say no to landscape and turn it off.
Thereās a weird technical catch with that decision too! SwiftUI apps (as all new iPhone apps are these days) are limited to all or nothing, unlike old UIKit based apps. In old apps you could allow rotation on some views but not others. But with SwiftUI you donāt get to pick and choose - either the whole app allows rotating or none of it.
Or at least thatās how it still was the last time I checked. Maybe Apple have improved that now. Anyway, the point there is that I really want to support rotation in the photo viewer. But if the rest of the app isnāt meant to support rotation, then the photo viewer has to lose, and get stuck with only portrait too. Sad.
Anyway Iāll get to deciding on that soon I think!
While you wait, Arc Reader can export JSON and GPX format for one or more days. I added it last week, so the button is still labelled āExport JSONā but it also supports GPX. I added it because Iām also using Arc Editor and needed this function for another program that imports routes for photos that donāt have embedded GPS data.
It has undergone minimal testing, but should work. Caveat usor!
Regards
Gordon
1 Like
Hi Matt,
The Arc Editor Backup data appears to include duplicate/overlapping timeline activities for the same real trip window.
Hereās the OpenAI Codex Report.
Observed behaviour after import
-
Diary shows duplicated entries with identical metrics/time windows (example: 10:14 AM Car ā¢ 34.4 km ā¢ 36m ā¢ 56.6 km/h appears twice in Arc Reader ).
-
Also shows overlapping classification for the same movement window (e.g. Unknown + Car).
-
Route drawing fragments unless overlapping activity items are deduplicated.
Why this looks like backup-level data duplication
-
The problematic entries are sample-backed activities (not empty placeholders), so this is not just a ā0-sample ghost itemā issue.
-
Multiple activity records exist for nearly the same time window and trajectory, indicating stale + updated timeline items coexisting in export.
-
There is also at least one anomalous orphan trip item with start=end and no link continuity, which suggests timeline consistency issues in this dataset.
Workaround applied on my side
- I had to add a dedupe pass that removes overlapping duplicate activity items (high overlap, near-identical window), preferring the higher-quality record (known activity type, better linkage, richer sample set).
Likely root cause to investigate in Arc Editor export/sync:
-
old and revised timeline items for the same interval both being retained/exported,
-
and/or linked-list consistency not pruning superseded activity items.
Iāve noticed that the most recent one or two days in a backup tend to have strange āanomaliesā which seem to fix themselves after a few more backups. If itās not Arc Editor (also happened in Arc Timeline) Iāll dig deeper in Arc Reader. I used to export the JSON file in Arc Timeline if I was in a hurry for the data. Iāve kept the files if you need to inspect them i.e. 2026-02.json and 2026-W07.json.gz.
Regards
Gordon
Hi Matt,
I just added the same workaround to the GPX and JSON export functions. They were still using the raw data points that included the duplicates.
The workaround will probably cause some other collateral damage that Iāll probably find in the next few days as it impacts the handling of the jitter inside locations. My quick trip to the garbage bin outside may get absorbed!
Regards
Gordon
1 Like
I,ve now played a bit more around with the new version, and got some surprises.
While I keep getting empty screens, when going back in time, I got fun just tried the search function, and wupti i cloud find a lot of places, but in a big mess, like here.
I searched for the company I work for in Sweden, and got this:
While the map is sort of correct, the shown places are from my trip to Mallorcaā
And this is the same day in the old:
PS Backup of iCloud is still running 
, should be done at 21:45 according to my calculations.
Then start the zippingā
1 Like
Perhaps someday.
Place details and total visits. As I am correct mis-assigned visits, when changing such the UI doesnāt update, eg total visits decremented in list plus in two previous views.
Still very happy that it works well.
Is Codex confident itās filtered out deleted items? All items are only soft deleted, to simplify backup (and potential sync functionality, if it ever comes to exist).
If overlapping items were present and not deleted then theyād show up in the timeline view in the app. So Iām thinking either this is old LocoKit1 imported data that hasnāt been viewed in timeline in the app, or itās soft deleted items (ie deleted=true). Otherwise itād be something thatād stand out within the app.
Or at least, if itās something thatās genuinely in the data (not soft deletes) and it isnāt visible in timeline view in the appā¦ Iāll be quite confused!
But yeah I think most likely case is old data from the old LocoKit import. Or alternatively itās soft deleted items. If itās the former then viewing that data in timeline view in the app will trigger processing of it, and will likely immediately clean it up, such that you potentially donāt notice it was there - gone before you see it.
Oh @zzGordon I recommend pointing Codex towards the LocoKit2 repo on Github too! Itāll be able to resolve a lot of unknowns and ambiguity by looking at the code there directly.
Oh, another reason to have Codex double check against the LocoKit2 source is itāll then be able to see all the SQL level schema constraints.
LocoKit2 has formalised structure thatās enforced for the TimelineItem linked list, entirely eliminating a large set of problems that could sneak in in old LocoKit1ās data. But itās still possible for some weirdness to exist, that technically doesnāt break the rules but also isnāt logically correct or desirable.
Itās possible Codex has found something like that. And also possible that some new formal constraints could be added to catch more cases.
Though Iām still betting on it being soft deleted items 
But could be not.
Iām back with Claude Code today.
Hereās a summary of the audit of Arc Reader against Locokit2
Activity type mapping was badly wrong. Our numeric-to-string mapping had been guessed, and 9 out of 24 codes were pointing to the wrong activity. Trains were showing as boats, buses as trains, taxis as airplanes, scooters as cars, and hiking as tractors. Weāve corrected all of these and added the 15 missing types (motorcycle, tram, metro, skateboarding, skiing, etc.) so the full LocoKit2 ActivityType enum is now covered.
confirmedActivityType wasnāt being used properly. We now set manualActivityType to true when confirmedActivityType is present, so user-confirmed activities are treated with higher confidence and wonāt be overridden by sample-based inference.
Note-to-item linking via timelineItemId. Understanding that newer notes (source: LocoKit2) carry a timelineItemId while older notes (source: LocoKit) donāt, we fixed a duplicate note bug ā notes were appearing on both a trip and the following visit because we were matching by time-range overlap. Now we use the direct timelineItemId link when available and only fall back to time-range matching for older notes.
Confirmed our normalizer structure is correct. The nested base/visit/trip composite structure, the visit vs trip field separation, place handling via separate bucket files, sample linking via timelineItemId, deleted item filtering, and the doubly-linked list ordering all matched what weād already implemented.
Confirmed things we donāt need to store. Trip distance and speed are calculated from samples at render time, and embedded place objects arenāt included in bucketed exports ā so no gaps there.
Thanks
Gordon
1 Like
On that one, thatās a āwork in progressā in the LocoKit2 schema. Well I guess that oneās in the Arc Editor schema extensions. But yeah, itāsā¦ schema flexibility in preparation for a more advanced Notes system.
Whichā¦ I donāt even have logged as a todo! But yeah, eventually it would be great if the Notes system could be much more than ālittle snippets on itemsā.
Yep, LocoKit2 also does similar. Those (plus Visit centre and radius) are lazily calculated and cached, and can be reconstructed at any time based on the itemās samples.
When an itemās samples change, at SQL trigger level the item is marked as samplesChanged=true, so that the cached values will be updated on next load/pass. More resilient and formal than the equivalent in old LocoKit1.
Hi Matt,
Looking forward to the eventual upgrade to the notes system. Having a way to read all the notes in one place was what started me on the Arc Reader project. Thereās a āNotes Onlyā checkbox that does this, and can be printed or downloaded as a formatted Markdown document. Itās just the text content at this stage. I guess the ultimate version would include map routes for each day and support some images. As a browser program, I canāt do the images automatically, but could choose a few of the best ones to include. It think it would be most appropriate for vacation days tagged as an [Event] rather than have thousands of photos added.
BTW. I added the ability to search for updated days using hashtags. Since itās possible to edit any previous day in the Arc editor/Timeline archives, I wanted a quick way to check they were there after a new import. In the Diary Search field insert ā#updatedā and the results slide-out will list them. It also works for [Event], [New] and possible future tags?
BTW. Iām currently in planning mode for a new analytical tab called āHeatmapā. Iām not sure how useful it will be, since it can only ever be a users own activities, but it should look really cool!
Gordon
1 Like
The Heat maps are 80% done! I added dynamic sliders because tweaking the settings is definitely needed for the best visual results. It defaults to walking. Adding trains etc creates blurry lines between the locations. The āSet Centreā takes the centre of the map view to calculate the radius. I need to expand this beyond 250 kms. Zooming in adds more detail.
1 Like
I increased the spread of cooler colours in the heatmaps. Here is a dark mode version of my 2019 trip to Japan.
Gordon
1 Like
Bit of a tangent, but in my Claude Code āLifeā project that I use for general everyday life management and assistance Claude wrote up a Python script that I think uses a Python PhotoKit wrapper to access my Photos library on Mac. So thatās essentially identical to what Arc is doing on the iPhone - using the PhotoKit framework to access photos by date ranges then filtering by whether their coordinates fall within timeline item vicinity.
Though of course that then means a companion app running locally on the computer. With associated platform specific hassles - much more of a challenge than the usual browser specific platform hassles.
Very cool! Iāve actually got tags as a planned feature for Arc Editor (or I suppose even at LocoKit2 level) for a future update. With the AIs on the job these days thereās even a chance Iāll eventually get to building it.
I think tagging opens up a lot of possibilities.
Another one Iāve had on the todos for ā¦ well, almost a decade 
But yeah, in a desktop sized window it makes much more sense. On iPhone thereās only so much you can do in a map view before youāre getting into visual overload. Heatmaps on iPhone might work, might not.
Will be very curious to see how it turns out for you!
Ok I shouldāve kept reading before replying
This is fantastic! Iām going to have to have a play with this today.