Arc Editor public beta 8

[matt]

1.0 (build 31), 2025-11-28 09:44 (Tokyo)

Improvements

• Added version and build number to Debug Info view title (BIG-223)
• Toolbars now fully adopt iOS 26 Liquid Glass style: content scrolls underneath with blur gradient (BIG-224)
• Moved Confirm All button to bottom toolbar in Confirm List view (BIG-225)
• Improved performance of place statistics updates for places with many visits (BIG-228)
• Activity tab now updates reliably and removed incomplete summary section at top; cross-day trip distances now calculated precisely at sample level (BIG-185)

Bug Fixes

• Fixed trip speed and altitude charts showing raw units (m/s, meters) instead of locale-aware formatting (km/h or mph, m or ft) on y-axis (BIG-203)
• Fixed Confirm List view not hiding the tab bar when opened (BIG-226)

[matt]

Oh I keep forgetting to include the test group join link: Join the Arc Timeline Editor beta - TestFlight - Apple

[trackerminerfs]

UI bug this release:

Basically I was visiting a completely new place. So I needed to use the search feature to search for the place. However while I was typing the name into the search bar, the main navigation bar (“timeline”, “places” etc) appeared and obscured the search bar.

[matt]

Yeah I’ve noticed the same one! Also, the top result of the search results can’t be tapped. Oops. I’ll get those fixed today hopefully. I’m probably sending out a new build this afternoon.

[Hutima]

Is there a better way to convert this stationary location to an activity? It’s relatively easy to do activity to stationary but there doesn’t seem to be a one step way to do the opposite

[matt]

The problem there is “what should it do with it?” Like, you could delete the visit, but what should the timeline do with that information? Should it try to merge the visit into a nearby visit? If it’s between two trip items should it merge the three together so it’s one long trip item?

The processing engine will apply its rules and heuristics to evaluate either of those possibilities, and some others, then pick the highest scoring one. But that might not be the action you intended or wanted.

If your intent is specifically “I want this to be turned into a trip item instead of visit”, then yeah there’s no UI for that. That can happen if you delete the visit, but not necessarily. I’ve never actually considered such a feature before. I’ll have to think on it.

It might be something that people want to do frequently. Though I’m not sure. Personally, because the feature has never come to mind, I’m suspecting it’s not something I’ve run up against often. Though maybe it is and I just haven’t been consciously paying attention to it…

[Hutima]

This happens a lot in traffic, it’ll detect a stop for like five minutes and make a location so I’ll want to change it from stationary (a place) to driving

so like delete + activity type change

I feel like it should be relatively analogous to the activity type where you can change it to like the activity type selector menu because you can already go in and change each segment one by one until the activity disappears

The above example is an airport where I’ve used multiple terminals so it has a really wide classification radius, in that example even though I haven’t sat down at a gate it’s classified it as a visit and I want to change it all to walking but similar idea, I stop for a few minutes and it classifies it as a visit

[matt]

@Hutima

This happens a lot in traffic, it’ll detect a stop for like five minutes and make a location so I’ll want to change it from stationary (a place) to driving

so like delete + activity type change

Ah, for stop-start traffic the quickest pattern is this:

1. Tap the clean up button
2. Delete the visit

That’ll convert all the samples in the brief visit to stationary (clean up button), then when you delete it it’ll get merged into the trip/car items on either side of it. And it’ll end up as a nice tidy stationary segment in the segments of that combined trip/car item.

@Hutima

I feel like it should be relatively analogous to the activity type where you can change it to like the activity type selector menu because you can already go in and change each segment one by one until the activity disappears

Would you be wanting to change all segments/samples inside the visit to a single activity type? Like change them all to walking or something? Is that the intent in that case?

[Hutima]

Yeah just like convert a visit to all of one activity type. It’s just making the process symmetrical I think especially since if you convert an activity to stationary it becomes a visit but you can’t easily make an visit an activity

Also it would be nice to have an indicator on the calendar about unconfirmed items like in the current version of arc on the App Store

[matt]

@Hutima

Yeah just like convert a visit to all of one activity type. It’s just making the process symmetrical

Fair. I’ll add a task for it, and have a think over what the implications would be. Often for these things there’s a reason why something falls into the “bad idea” zone, but I can’t remember what it is. There’s been so many years building these apps that I keep learning things then forgetting again then having to learn them again!

It might be that there’s nothing dangerous or problematic about it. I certainly can’t think of anything off the top of my head now. If so, I’ll add it!

@Hutima

Also it would be nice to have an indicator on the calendar about unconfirmed items like in the current version of arc on the App Store

Yeah I want this too. Unfortunately SwiftUI’s calendar widget doesn’t have any functionality for that. You can’t add any annotations or styling to the days in the calendar. It’s super basic, only usable for browsing to dates and selecting them.

There is though an older UIKit calendar widget, that’s built for more full screen display, like the old one in Arc Timeline. And with that one you can do more. So I’m thinking at some point … there could be a proper full size calendar view, separate from the one that’s there now for navigation. And this new one would be for finding these kinds of extra details. So there’s be the current one for just getting around to different dates, then this larger one for seeing actual extra information about the dates.

[Hutima]

if you end up making it reversible, maybe also make the delete visit more generic so you can more easily mergr segments into a visit

Bug report: I’m sure you’re still working on it given the limited functionality but the math isn’t mathing (see pictures)

Pretty sure I haven’t walked for six months

Second suggestion: Also just bumping a request for gpx export of some sort

Third suggestion: Also ice skating activity type addition would be appreciated, I’ve used inline skating to approximate but it should be ice skating (or maybe just make skating generic, or a generic winter sport instead of skiing?)

Suggestion: there’s no indicator of when a segment only has bogus location, I will make it stationary and then try to make it a place but it’ll fail because there’s no location on the points, this used to be clearly indicated in the old app

The failure to assign a location happens without a warning this is most often an issue with subway stations and usually I fix by adding one point as stationary from the nearest activity that has location data

Photos:

[matt]

@Hutima

if you end up making it reversible, maybe also make the delete visit more generic so you can more easily mergr segments into a visit

I’m not sure what you mean on that one. Could you give an example?

@Hutima

Bug report: I’m sure you’re still working on it given the limited functionality but the math isn’t mathing (see pictures)

Pretty sure I haven’t walked for six months

That’ll be a timeline item somewhere that’s wrong, rather than the Activity tab adding up wrong. Try going through timeline view by months … hmm, actually that’ll still make it hard to find. Go through Activity view by months, then weeks, then days, to find the day that has the very large walking value. Then that’ll tell you which day to go to in timeline view to find and fix it.

@Hutima

Second suggestion: Also just bumping a request for gpx export of some sort

Cool! I’ll bump the issue in the task tracker.

@Hutima

Suggestion: there’s no indicator of when a segment only has bogus location, I will make it stationary and then try to make it a place but it’ll fail because there’s no location on the points, this used to be clearly indicated in the old app

Hm. Curious. I’ll have a think on that one. Not 100% sure what’s going on there…

[Hutima]

It has something to do with how the database stores timestamps

One of the points has a bad time because I had to clear the phone caches and moved time forward by a year so one year of data doesn’t add up for me because the time is being measured incorrectly because of bad data

The old app reassigned that data point to the future date so it didn’t impact anything but here it looks like that’s now how the database does math

My app is actually kind of broke for one year because that one hole visit now spans one year and there’s an entry for every day of the year, it’s also completely bugged because I can’t edit it since it’s like a fake time on each day

The visit spans the full year as the first entry every day and can’t be edited

Edit: it’s kind of more ridiculous the longer I keep the app open

The classifier is now merging the full year into the visit and I can’t stop it

I’m doing to delete and reimport the old data from my database, the app is sending my phone into a death spiral, lol it’s draining the battery on charger trying to process the year

Another edit: Jokes it’s not letting me delete the old imported data so i guess I’m going to reinstall the beta, unfortunate I just got classifications to a good spot

Edit: the bad data point gets counted as locokit 2 so it also breaks the database it looks like and the ability to delete the previously Imported data; I’ve deleted and reimported the beta, I’m hoping not looking at the data will allow it to not be broken

[matt]

Hmm. A difficult situation!

And yeah, doing a fresh install and fresh “old LocoKit” import is probably the way I’d go too. Though that’s assuming you’ve got the data in a sane state in Arc Timeline, otherwise it’ll just be importing back in the same problem again…

If that doesn’t fix it, it might be necessary to edit the database directly. That’s a kind of situation the UI isn’t built to cope with, for either viewing or editing, and the processing engine isn’t built to understand either. So yeah, hand editing the database might be the only way, if the fresh install and fresh import doesn’t resolve it.

Although… you could do a full export from the Debug view, or turn on the iCloud Drive backups and let those finish, then get an AI like Claude (in Claude Code or Cursor or some other tools enabled environment) to edit the JSON files to fix it there. Then could do a new fresh install of Arc Editor, and import from that JSON instead of old LocoKit. That’s actually probably how I’d do it myself now. Describe the problem to Claude, get to sift around in the JSON files until if finds the problem(s), and can then edit the data there, ready for a fresh import into a fresh install.

[Hutima]

The problem is this was something that happened last year before I got the beta, so it’ll always be an issue unless I edit the database

I feel like this isn’t a super edge case, it might happen any time the clock on the database is wrong

editing the database seems a bit involved, it’s just odd since it did seem ok in old locokit but can’t be handled in the new one

So as soon as they day is loaded by new the ark it changes it from locokit one to locokit two

The failover is messy because it immediately starts merging the full year of data

In the old locokit, it was reassigned to the correct day in the future (assigned as bogus, the 3PM data point in the second)

So I’ll have to edit the database (or maybe let it finish processing a full year maybe? But my phone crashes when it tries I think because its too mich data to classify in one go) which honestly I have no idea how to do

Maybe the failover for a point like this should be like locokit one where it just gets assigned to the date in the JSON?

Edit: turns out if you set the prior and later points to a different activity type the engine will extract the point and transfer it to the appropriate future date so I’ve been able to achieve the same result

[matt]

@Hutima

The problem is this was something that happened last year before I got the beta, so it’ll always be an issue unless I edit the database

Yep, I think it’s unavoidable. You’re going to have to do some manual editing outside of Arc.

@Hutima

I feel like this isn’t a super edge case, it might happen any time the clock on the database is wrong

iPhones have their clocks updated frequently from time servers, so their time is correct down to the milliseconds almost all of the time. The only common edge case might be changing timezones, and the phone not having cell signal, internet, or location data to notice the timezone change. Though that’s typically only a matter of minutes, unless it’s a phone that’s got everything turned off (cell network, wifi, location).

This specific case you’re in is actually exceptionally rare! I can only vaguely recall one other user being in this situation over the 9-10 years that Arc’s been around.

@Hutima

editing the database seems a bit involved, it’s just odd since it did seem ok in old locokit but can’t be handled in the new one

I think this will be more a case of old LocoKit not handling something. It was much less attentive and aware of the data in its database, so bad data could slip through unnoticed. LocoKit2 is super strict, enforcing rules, prohibiting various kinds of bad data.

So what will have happened was that the importer imported across the data as it was in old LocoKit, but under the new rules that will be noticed in LocoKit2, and processed. While old LocoKit didn’t notice and didn’t process.

@Hutima

Maybe the failover for a point like this should be like locokit one where it just gets assigned to the date in the JSON?

I would have to see what the actual broken data looks like to know what kind of workaround the importer might be able to do. The import isn’t changing any dates at all, it’s importing across exactly the sample and item data it’s given. So it won’t be a matter of the importer changing anything, it’ll be a matter of old LocoKit not noticing a broken situation, and LocoKit2 noticing.

@Hutima

Edit: turns out if you set the prior and later points to a different activity type the engine will extract the point and transfer it to the appropriate future date so I’ve been able to achieve the same result

Great to hear! How far have you got through cleaning it up?

Though I still do recommend doing the JSON export, getting an AI like Claude to help you fix the bad data, then doing a fresh install an reimport from the fixed JSON. If there’s broken dates in there they’re going to be there forever, potentially causing problems again later.

[Hutima]

It’s clean I guess, it did it automatically after I reassigned the points before and after to a different activity, and then I can merge the two activities back together

The bogus point is now registered in the appropriate time stamp a year later

I did try the ai thing with chat GPT but it ends up being too much text and it isn’t possible

I did try looking for it manually in the json but i couldn’t find the point in the export so ¯\_(ツ)_/¯. Ah well it’s fixed now

[matt]

@Hutima

I did try the ai thing with chat GPT but it ends up being too much text and it isn’t possible

Ah, you’ll want to use one of the “agent” systems, like Claude Code or Cursor. It’d need to be able to access the files on your computer, rather than you having to upload files into the chat. The files will definitely be too big to put into something like ChatGPT.

Anyway great to hear that it’s all sorted now! Phew

These kinds of problems can be really hard to resolve, even for me. (Hence why I recommend getting one of the AIs to help. They’ve got much more patience than us, and can sift through large JSON files much faster and more accurately than we can).