Natural Language Search (BIG-21): The Search tab is now fully functional with AI-powered query parsing. Search across visits (by place name or custom title), trips (by activity type), and notes (by body text).
Natural language date filtering understands expressions like “last week”, “December 2019”, “before March”, and “6 months ago”. Activity type queries are normalized automatically - “walks”, “runs”, “flights”, or “bike rides” match the correct activity types. Search queries can be entered in any language.
Improvements
Added last backup date to Settings status section when backups are enabled (BIG-208)
Added sleep cycle duration to leaving probability display in Settings (BIG-208)
Reorganized Debug Log view toolbar: export and delete buttons now visible in top bar, filter and font size moved to bottom bar
Bug Fixes
Fixed Total Visits list failing to load for places with many visits (3000+), previously showing spinner then crash or empty list (BIG-228)
Fixed Confirm List bottom toolbar blocking swipe-up gesture when sheet is minimised (BIG-250)
I’ve been testing my apps against the new ‘schema’ in the backup files of the beta version (33). I’m almost there with extracting what I need for my Koala tracking app. I will then apply the learning to the Diary Reader.
In testing, I discovered that notes added to ‘One Time Only’ locations don’t seem to get a timeLineId or a placeId; both are null. So do Visit.CustomTitle entries miss out on these? Please add to your post-xmas todo list. In the meantime, I’m about to try a time-based method to get around this one.
Merry Christmas
Gordon
"body": "This Koala is close to the path and unlike the others is fairly low to the ground. He looks somewhat worse for wear.",
"timelineItemId": null,
"placeId": null,
"file": "29189419-A28E-4515-8DFC-1A4C45FB7432/notes/2025-12.json",
"startDate": "2025-12-18T23:15:10Z",
"endDate": "2025-12-18T23:15:10Z"
For the notes in Arc Editor, I’ve taken a slightly different approach than in Arc Timeline app, to improve the situation a bit in edge cases, and also also for more flexibility in anticipation of future features that could flesh out the notes system to be … something more impressive.
The main difference is that the timelineItemId is now optional. A note added from the UI will always initially have a timelineItemId, because that’s how the current UI works - you add them from the Item Details view. But what if that item is deleted? Or split up? Should it stay attached to the item it was created from? Or should it care more about when it was written, and stick to that point in time?
At this point the distinction doesn’t really matter - there’s no functionality that really benefits from the difference (I think). But in future it may well matter. Oh and notes also now have startDate and endDate. That’s there so that things like adding a daily diary entry can make sense.
That daily diary entry wouldn’t make sense to be connected to any single timeline item, but it does make sense for it to know its start and end dates.
Anyway, that’s not quite what you’re asking about! For the case you’re seeing… I suspect it will be coincidence that it’s on a visit with a “one time only” / customTitle. I suspect it’s possibly more likely it lots its timelineItemId due to merges or deletes. Or possibly it’s a note that came across in the import from Arc Timeline / old LocoKit. And during the importer the importer realised the timelineItemId on it didn’t make sense (the item was deleted, or some other inconsistency), so it cleared it out.
Anyway yeah, best to build into your system both pathways: a note could be connected directly to a timelineItem, or it could be unattached and instead captured by its startDate/endDate.
I finally decided to migrate to Arc Editor but… I didn’t see an option to import data from Arc Timeline… tried uninstalling and reinstall and it is the same. Do you have any idea? Found it under Debug settings.
I also would like to confirm - if I mark a location sample as another type or even bogus in Timeline, will this be imported to Editor?
And will existing lifetime purchase work for Editor after GA releases
Yep. That “Old LocoKit importer” imports everything in Arc Timeline app’s database. It all comes across.
But it is a one time thing. So anything new in Arc Timeline app can’t be imported across after you’ve started using Arc Editor. From that point onwards you’ll want to be having Arc Editor running, recording its own data.
I might later make it possible to import specific portions from Arc Timeline app to Arc Editor. But at this point it should be treated as a one time import, to get Arc Editor started with all the data you had in Arc Timeline at that point.
Ah this one might be a case of the processing engine insisting those two paths can’t logically be treated as one due to distance gap, impossible speed over the gap, that sort of thing. Can be common with underground train trips unfortunately!
You can sometimes trick it into doing it by splitting the edges off the two items, and seeing if it’ll merge those split edges. At which point it might be then happy to merge across three items instead of two.
Over time I want to improve that logic, so that the processing engine can make better sense of it and realise that merging might be the more sensible answer than what it’s doing now.
Speaking of that, do you know if the import includes the activity classifier? I still find that Arc Editor is worse at identifying train trips (underground or not) than Arc Timeline. I recall there is a machine learning model in Arc Timeline that takes into account location, speed, direction, time of day and many factors to predict the activity type; are all of these learned features imported?
The activity type models aren’t imported cross, no. But they are rebuilt within the first 24-48 hours after import. And at that point they’re as good as or better than the ones in old Arc Timeline app.
I suspect what you’ll be seeing there is not a weakness in the activity type classification but in the actual recorded data. LocoKit2 / Arc Editor overall record much higher quality data than the old system, but that is potentially uneven. Like, it could be that when underground in trains LocoKit2 is doing a worse job of capturing the detail.
So yeah, I think the work item there for me is the one of “spend more time testing underground train trip recording, and tweak the parameters until it’s doing as good as or better than the old system”.
That’s actually been on my todos for a bunch of years Even before LocoKit2 / Arc Editor. It used to be much better in the earlier years of Arc Timeline app. But somewhere along the line some “wisdom” in the system got lost. I suspect while making it better for the more common cases I accidentally made it worse for underground train trips.
But yeah, that can be fixed! I just need to set aside that time and do that testing and tweaking. And unfortunately that’s not something I can delegate to one of the robots. That still requires human effort! But I’ll get to it eventually.
I have a somewhat related request. Is there a way you know of for users to find out whether a sample shown in the old Arc app is recorded by Arc Timeline or Arc Recorder?
I do have a suspicion that the apparently low quality data I occasionally get in Arc Editor is caused by iOS not waking up the app often enough. And I suspect having Arc Recorder helps. I’m curious to know which data in Arc Timeline is recorded by the Recorder app.
Happy new year by the way! Right before the countdown I was looking at the yearly view in Arc Timeline and Arc Editor and I think Arc Editor displays the journeys much more faithfully!
For old Arc Timeline app, I won’t be doing any improvements or additions to that app. That one is firmly in maintenance mode now. If something breaks, I’ll fix it, but otherwise that app gets no new work done.
All new work goes into Arc Editor now. But Arc Editor will eventually have Arc Recorder as its recording buddy. So this feature request can make sense for the new app! I’ll have a think on how it might work…
Even before LocoKit2 / Arc Editor. It used to be much better in the earlier years of Arc Timeline app. But somewhere along the line some “wisdom” in the system got lost. I suspect while making it better for the more common cases I accidentally made it worse for underground train trips.