Oh make sure to turn on the backups in Arc Editor’s settings too. The automatic incremental backups are much faster and more reliable than in old Arc Timeline app. When plugged in to power they get updated in seconds, every 3 hours I think. And you can trigger a manual backup from the Backup Settings view, to get latest JSON immediately.
Though you’d still want to work on a copy of the JSON from the backups. Well… I guess as long as the app using the JSON is read-only there’s no need for a copy. I just get nervous around the original copies of backups.
Oh you can also do a full export quite quickly from the Debug Info view, down the bottom in the Database section. That’s the exact same JSON schema as the backups, it’s just done in one go instead of incrementally. (The first time the backups system runs it’ll do it in chunks, so that if iOS tells it to stop at any point, it can pick up again later where it left off).
Thanks for the info. I’ll give it a try later when my Claude time returns. I have a more interactive version of the map view in the diary now. I have three map styles and can filter the activities using the colour definitions you gave me earlier.
I had a bear of a time getting the save as jpeg working properly! Getting the vector layer to render in the right place on a resizable map was really hard and it blew through my Claude time. I took the code over to Gemini 2.5 and things got worse. Finally I threw the mess at ChatGPT 5.2 and it fixed the problem fairly quickly especially when I gave it a comparison screen grab, which I did for the other AIs too.
When ChatGPT first arrived, it was a disaster. It was even making simple syntax errors. Although today I was just doing code search and replace tasks rather than a complete code update the way Claude does it.
Here’s a screen grab. We walked almost 7 kms yesterday morning and I think the route looks a bit like a rat! The pin marks a very popular coffee shop on the route.
Heh. That’s one that sounds super simple in principle but can turn out to be quite a fuss in practice! In Arc Timeline app there’s still a bug with the saving of timeline views as images. If the timeline is too long or has too many photos in it, it’ll just silently fail. iOS saves out a blank file, but doesn’t tell Arc there was any problem
When it comes to building that feature in Arc Editor I’m going to do it a much more complex way, but that won’t be prone to that problem. Not looking forward to building that part!
They’ve come a long way in not much time! I started playing with original ChatGPT when it first came out and found it fascinating, but couldn’t give it much in the way of real work. I still did though, even though it probably lowered productivity rather than raising it most of the time. It was fascinating to feel out what might be possible as they got better. GPT-4 then made a lot of work things genuinely possible, though you had to know how to use it well to get there efficiently instead of just wasting more time.
These days Claude Opus 4.5 is my full time work collaborator, then if anything might benefit from a second opinion I rope in Gemini 3 Pro or GPT-5.2. Opus is the best all-rounder, and the most competent “collaborator” - it knows how to work best as part of a team, and read situations well. It’s got the best soft skills. Gemini and GPT can be exceptionally intelligent, but 99% of the time you don’t need someone who can win Maths Olympics, you just need someone who can work well with you. And Opus is already more competent than probably any human programmer I’ve worked with over the years.
But yeah, that “get a second opinion” flow is super helpful sometimes. Get a very different mind to look at the problem, and see if it spots something Claude didn’t.
Your app is looking super cool btw! I bet people would love it if you shared it on Github eventually. Getting to the first working version can be crazy fast these days - the AIs can build something complete in one go. But getting to a polished and feature rich app takes time and work regardless. AI or not, you have to put the time in, and it looks like you have!
Yeah, I like Claude but have to use Sonnet to get enough session time. I may have to cough up for the higher monthly subscription rate occasionally. I retired last week, so this is all a hobby now.
The Diary Reader is now up to what is probably the equivalent of a version 2 app. The diary and map are much more interactive. Click on a location and the map zooms in on it like Arc does, except I get to see it on a 4K display! Click on a map pin and it scrolls to the highlighted diary entry.
This screen grab is from our trip to Japan at the end of 2019, just before COVID arrived. On this particular day we went to see the ‘family castle’ of which only the foundations and walls survive. Our ancestor lost the battle against the attacking warlord, but it was good to see a replica of his armour on display at the information centre.
Heh. Yeah, $100/month for a work tool that gets hours of use every day is cheap, but $100 for a hobby is getting into the “should I really be spending this much on a hobby?” zone.
Sonnet 4.5’s still a champ though! I was using it on the job every day until Opus 4.5 arrived. Opus just has that extra something, where it feels like it really has a handle on things.
Fantastic! Yeah there’s only so much you can do on an iPhone. Which is why I’ve long wanted a desktop app or web app for this stuff. You’re basically building the pet project I’ve wanted to build for myself for many years now
Anthropic have given everyone 2x session time until the end of December, so I’ve been taking full advantage of the ‘Christmas present’. I’m up to 122 versions of the app today. Each one was in response to multiple change requests.
The single html/js file is now 270 KB.
I added activity tiles for the selected month or the current day within the month. Note that I consider distance the better KPI over time.
Changed the interface theme to be a bit like Apple’s Liquid Glass. Since it’s not automatic, I added a transparency slider with memory so that each map style has its own optimal setting.
Sorry, the time order is top-down. It makes more sense for a diary.
The diary window loads a whole month of activity. I don’t worry about weeks.
Arrow keys jump by day or by location within a day.
Exports the diary content in markdown format.
Still using the legacy Arc Timeline Daily json files. I did develop a fully-working prototype running off the new Arc Timeline Editor backup files, but wanted to get the Arc Diary Reader UI nailed down first.
I looked at adding photos, but on the Mac that would require a MacOS helper app with built-in https server. That would be beyond the scope of this project.
It’s super-responsive on my Mac Studio. I will test it on some slower PCs around my home office to see what happens! I haven’t tried yet to fit it on a tablet screen, and it’s definitely not for phones. People should just use Arc in that case.
There are a heap of little cosmetic things to fix, and some bigger ones, but I ran out of session time, even at 2x.
That’s is looking incredibly cool now! And nice to see Fushimi Inari Taisha I was there a couple of years back. In Tokyo now.
Sounds like it’s almost time for breaking it up into separate files?
I went back and forth on this in Arc back when I first added the activity tab. The problem I found was that some types compare best by distance, but other types throw it all out. Like you can’t really compare “active” types (walking, running, cycling, etc) with transport types (car, airplane, etc) by distance. So duration came out as the type agnostic metric for comparison and sorting.
Heh. My preference there is still newest first, because that way I only have to have one mental model for all lists in all things - newest is always at the top. But granted there’s nuance in that, and a diary that’s meant to be read from start of day to end makes more sense oldest first. In that sense the day is the unit, rather than the chronological entries within.
For my Claude Code “Life” project Claude wrote up a photos script in Python I think, that uses PhotoKit. So that doesn’t need anything compiled or fully app-like, but still gives it a script to extract photos as needed.
Bridging that kind of Python script approach into a web app could be more plausible, I think. Though I haven’t fully thought it through.
At that point you might be verging into the zone where it’s best to have the web app served by a mini local server too. For one of my local dashboard web apps that Claude’s built, it runs it from a Python script so that it’s loading from localhost:8888 or whatever, instead of directly from the HTML file. That lets it do some programmatic things in Python if it wants (though currently it doesn’t - it just did it to get around a security issue with loading JSON data files into the web app).
Anyway that’s looking super impressive! You thinking about publishing it on Github at all? Or just gonna keep it a personal project for now?
I asked Claude, and it said to stay with a single file for now. It said it was easier to debug with everything in one file.
I’m working on version 3 this afternoon. With hundreds of builds, I got sick of reloading hundreds of json files every time to test, so I’m using IndexedDB to store all the data in persistent storage locally. Testing all the permutations and combinations of user pathways between the diary and the map and the summary stats was a nightmare!
I’m about to run out of session time again! Here is a screen-grab from the latest version (Build 167). It uses IndexedDB to retain the entire dataset going back to 2013.
Using W3C standard IndexedDB for local offline storage of all the json daily file data.
Supported by browsers on multiple platforms
Exports in the same Arc Timeline json file format, so can be re-imported with the same importer.
Since it’s offline I have to re-import to test on other platforms, but it’s quick.
Added a year/month selector now that the data is persistent.
Only new or updated json files imported after the first build.
Loads a month at a time into browser memory to avoid crashes!
Added a favourites feature to search supporting up to 12 locations.
Added altitude to locations.
Defaults to the current month and displays the month route view.
Loads in a few seconds on a Mac Studio. I should have done this a hundred builds ago!
Back on that very wet day in December 2019 we booked a tour of Fujiyama. The weather turned bad and we only made it to the 4th Station before the mountain was closed. We never saw the mountain because the fog was so thick! It’s only now after loading this contour map that I can see where we were! Adding the altitude data, I now know we were 2037 metres above sea level (which is only about 200 metres below the height of Australia’s highest mountain). Later we were taken on a boat cruise on Lake Ashi, at Hakone-en, but the weather was so bad they had to turn around. We still couldn’t see where Fujiyama was during the cruise!
Oops I just noticed a bug. When jumping to a favourited location, the year/month selection doesn’t update. Darn! I probably should also add the year to the activity panel title.
I was there just this June! A beautiful place Got to see Fuji san from one of the gondolas. Though because of the month there was no snow on it, so it didn’t quite have the majestic iconic look.
The Arc Timeline Diary Reader is now online at GitHub. It only supports the older Arc Timeline export and backup files at present. I wanted to make it feature-complete before tackling the Arc Editor files. The Reader has come a long way in the last month and still has some bugs and features to sort out. Unfortunately, I discovered MapBox 3D too late to implement it, but I did add it to another program I use for location mapping Koalas.
The most recent feature added to the Reader is an interactive elevation graph. BTW, 05-JUL-2018 is the first date in Arc Timeline that I have elevation data for.
My favourite feature is the Locations Analysis. As an example, here is my sad Maccas history. Fortunately things turned around in 2024!
So very cool! Such a great example of putting the data to use. The app collects it, but it only provides a limited set of tools for putting the data to task. This goes much further
Looking forward to using it with Arc Editor! I’ve stopped housekeeping my old Arc Timeline data completely now I basically only keep it installed and running because it’s my job to make sure it keeps working until Arc Editor takes over officially (which is probably within the next 1-2 months).
I added a speed profile as well as some descriptive stats to the elevation panel today.
Right now I’m re-importing the AT Backup into the AE to start investigating the new format. I stopped using AE for a while after it went into some kind of thermal-runaway. According to the iPhone it was using 50%+ of the battery and the phone was seriously hot. That was a build from weeks ago, so I’ll start using it again. I deleted and re-installed the app to migrate a fresh copy of the AT data
The Arc Editor importer is done. I’m testing it now. I’m using OpenAI’s Codex app. It’s very similar to Claude Code and it didn’t take long to get the importer update written. It actually worked first time, which is very good. Adding the Arc Timeline Backup Importer took days to get working right. Maybe Codex is better at understanding what the code does?
Here’s the Codex assessment of your new format -
Arc Editor Data Report
Summary
Arc Editor delivers the same timeline coverage with significantly more efficient storage and very strong import reliability. The new structure is cleaner (batched, normalized, compressed) and performs well at full-history scale.
Observed Improvements
Efficient storage model
Data is grouped into monthly/weekly buckets (items, notes, samples) instead of many tiny files.
High-volume samples are compressed (.json.gz), reducing backup size.
High import integrity
Timeline records: 56,808/56,808 accepted.
Places: 2,406/2,406 accepted.
Notes: 6,416/6,421 accepted (only 5 rejected).
Strong full-import performance
Full Arc Editor backup imported successfully in under a minute.
6,397,089 GPS samples loaded from 633 week files.
4,448 days imported covering 2013-11-20 to 2026-02-04.
Better schema consistency for processing
Clear separation of base, trip, visit records.
Place and sample structures are easier to normalize consistently across browsers.
Assessment
Arc Editor is a substantive technical improvement over the legacy Arc Timeline backup format: smaller footprint, cleaner data organization, and excellent import stability at large scale. The migration path is now practical and production-ready in this tool.
I spoke too soon! There were some bugs associated with items contained within other items, and differences in the new format that caused locations in the animation player to go missing.
Arc Editor visit items often don’t have visit.latitude/longitude.
That left visits without usable center coordinates, so replay had no stops to show.
Fix applied (Build 815)
Added fallback to item.place.center when visit center is missing in:
extractNotesFromData(…)
extractEntriesAndNotesFromData(…)
extractPinsFromData(…)
Earlier importer-side center fix remains in place.
I will do more testing tomorrow and compare it with an instance that imports from Arc Timeline, as well as the iPhone app. Regardless, Build# 815 has been pushed to Github, so you should be able to point it at an Arc Editor backup. Please select a specific backup and not the backup folder. I will have to add an error check for that tomorrow.
Oh definitely let me know if the new build from yesterday causes any thermal or battery issues! I made a few energy use fixes in that build. Not sure if I caught the main cause of the problems, but the few I did deal with were nasty ones. So it should at least be better than before.
I’d actually credit Claude Opus with this one! The export format from LocoKit2 / Arc Editor is all Opus’s doing, while the old format from old LocoKit / Arc Timeline was all my doing. Opus did a better job than me So importing the newer format should be cleaner, faster.
Though I’m also impressed by Codex! While I’m purely a Claude shop myself, Codex is still top grade equipment I think. We’re spoilt for AI quality these days. It’s all quite amazing.
Hah! Ok now reading Codex’s assessment, yep, matches mine Old format: from me, and quite meh. New format: from Claude Opus, and much less shit.
Claude also nailed the reliability and integrity of the new format and exports, another massive improvement over the old system. Though I’ll credit myself with some of that. While building the new system I pushed hard for us to think of every possible edge case, not letting us call it done until we’d really hardened the design and implementation. The old system was a source of constant customer support nightmares, so I wanted to avoid that this second time around.
Ooh, this sounds like an old LocoKit importer issue. Someone else on the forum reported something today that sounds eerily similar. The coordinates will get filled in lazily, once the Visits are loaded in timeline view. But for some reason in some cases they aren’t being filled in during import from old LocoKit db.
I haven’t seen this at all with my own old LocoKit imports, so I’ve got no guesses yet as to why it might happen. But yeah… my guess is it’s some weirdness with the importer. Either the old db is missing lat/lon in some cases (though then that’d show up in the old data too), or the importer is somehow dropping those values in some cases.
Great! Looking forward to having a play with it Looks super cool!
I was there a couple of years back. In Tokyo now.
I basically only keep it installed and running because it’s my job to make sure it keeps working until Arc Editor takes over officially (which is probably within the next 1-2 months).
So importing the newer format should be cleaner, faster.
