Concerning a more condensed view such as showing non-visit data (walking, car, etc.) on one line as I thought such might be good, found this example from the app Roadtrippers:
How they display stuff in general I’m not sure what I think of it yet just the example of travel time and method being more condensed (though it could look better), maybe that could help with showing more data in less space more similar to calendar apps. I like it. 
A tiny bug: the date in the timeline cleanup page is always the same: 22 March 2023. regardless of the day and year in the timeline.
I installed ARC Editor yesterday morning and I’m really excited to see something fresh on the horizon. The new app feels noticeably more responsive and accurate. I like it!
Installation was a breeze—just one click. Importing the ARC Timeline database, with 9 years of movement data, took about 40 minutes on my iPhone 13. Right after the import, I checked a few past days via the calendar and initially saw no timeline content. However, as I clicking through the days, the data gradually appeared. It seems that all entries are now visible and retain the same confirmation status as they had in ARC Timeline. (I’ve always tried to keep my timeline clean and confirmed, but even then, ARC Timeline often asked for extra-extra-extra confirmation. Hopefully, that’s a thing of the past)
I especially like the debug tools, please keep them acessible! Since installing and doing some initial exploration, I’ve experienced three app crashes. In all three cases, the last log entry was: “places UPDATING: Zuhause” (my home location). I also noticed that after 24h of running the app, there are still 1,677 items pending in the task queue—the same number as right after installation.
Extracting brief visits from a segment is much improved. I can add additional points and they stay on screen to pick from. No more speed selecting! In this process however I encountered a map UI bug. The additional stop points I had it create remain on the map as I move through different days. This first screenshot shows the day I was extracting brief visits, but on every other day notice points 1, 2 and 3 remain on the map.
After a day I still don’t like the map being dark, even though I do like the timeline view being dark. Here’s a missing feature that’s probably already on your mind: make the map style configurable. The Arc Timeline app allows a selection of map styles and I like Outdoors style the most. I really hope to retain that, even though the map is light and the rest of the interface is dark. Actually I might also prefer a setting to make the whole interface light or dark independent of the device setting.
Yeah looks good! I think it’ll make sense to use a more condensed style like this for the weekly timeline view. And maybe something even more condensed for a continuous scrolling style view.
It’ll be fun to feel it all out once I get to building the weekly/monthly/yearly timeline views. And that should nicely inform the hopefully eventually arriving continuous scrolling view too!
Hah! Wtf. I never noticed that! I wonder if it’s literally just placeholder text I forgot to fill in with real data 
Thanks for the feedback @Helge! Yeah, just after import there appears to sometimes be a slowdown, with the timeline data getting delayed in loading. I think there’s still more database query efficiency work I need to do.
The initial testing and building of the app was done with only newly recorded data, so everything got tested to be efficient with just a few months of data. But now that the old Arc Timeline database can be imported it’s showing a few weaknesses and inefficiencies. Needs a bit more tuning.
Certainly all of the weird mysteries of the old system are gone. There were a lot of cases where it’d do something odd, and the only conclusion I could get to (without hours or days of debugging, that might never bear fruit) was “huh, why’d it do that?” The new system is extremely clean and elegant, with none of the decade of cruft of the old system. So things act how they’re supposed to, with no mysteries or surprises. A huge relief for maintaining it all!
Yep. This time I’m going to keep all the debug views accessible, even in the App Store builds. People tend to find them useful. Plus sometimes they’re just fun - interesting to see under the hood.
Ok thanks for the heads up. Hopefully the crash reports have ended up in Sentry properly. I’ve got Sentry crash reporting integrated, which works much better than Apple’s built in crash reporting system (that tends to miss a lot of crashes and a lot of details of the crashes). So far it’s surfacing everything well, and I’ve got I think two known kinds of crash to fix today.
This unfortunately comes down to iOS’s whims. The background task to do all that processing work has been scheduled (it’s scheduled as soon as the app goes into the background for the first time), but it’s up to iOS to decide when to run it, and for how long it’ll let it run for.
In some test runs I’ve seen it run almost immediately, and clear through hundreds of tasks before stopping. Other times I’ve seen it get ignored by iOS for over a day. But it always gets there eventually.
For Place and ActivityType models that need to be used immediately, the system is meant to run those updates right in the moment. Which is happening in some cases, but it looks like in some cases I’ve missed the trigger. So I’ll be fixing that too. But in general they all still get done, once iOS feels in the mood for it.
Yeah I’m seeing this sometimes too. It appears to be the map updates system falling behind, either showing outdated data or sometimes no data at all. I haven’t had a chance to dig in to it yet, but it feels very much like just getting caught in a backlog, falling behind the current state of the data. So hopefully will come right with just a bit of database efficiency work.
Sometimes you can spot the backlog by looking in the Settings tab in the Active Operations section. Everything in there should finish within a few seconds (and most in only milliseconds). But sometimes something gets hung up, and holds up the queue. Which I suspect then flows on to holding up the map updates.
Ah yes, I like that feature too. Dark maps are often harder to read, in all apps. It’s useful if you don’t want a bright screen glaring at you in a dark car while driving at night, but at other times it can be just annoying.
K, I’ll add that to the todos!
Unfortunately this one is less likely to happen. Doing that would require every view in the app having a manual override based on a setting, so extra code added to every view. But I do want to make the current Dark Mode design … less dark. It’s currently using the default iOS Dark Mode colours in almost all cases, but my preference is for something less extreme.
Today I had just one visit to a store. It looked good so I confirmed all yet in the meantime seemed it rearranged it somehow such that confirm all made it something else. I forgot but maybe it was something like home, one driving session, then home. The visit was removed from confirm all.
Perhaps in extract brief visits there might be someway to filter all approriate ones such as by name such as by long hold and select all and then extract all of those? Not sure of ideal way yet often in such cases there are multiple entries of the same name and using all of them might be nice.
If you allow me to offer a piece of advice, I think it might be that if the current location accuracy is really low, such as underground, just trust user edits more. I have become somewhat adept at tricks like splitting stationary segments into stationary + metro and then doing the same for the destination so at least Arc Timeline draws a straight line between the origin station and the destination station.
Oh user edits are already trusted 100%! They’re treated as 100% confidence assignments.
Though the catch is that the processing engine, or at least the part that does item merging and edge corrections, doesn’t have any knowledge of user edits (nor can it). So if you split out a segment, then the processing engine looks at the sequence of timeline items, it might merge it back in again, because it doesn’t meet the requirements for being its own timeline item. And there’s no available information for the processing engine to know that you split that out manually, so it can’t know whether it’s working on automatic data or manually edited data.
The requirements for a Trip item to be a “keeper”, in the sense that it’s allowed to stand alone as its own timeline item, are quite minimal. I think it’s… let me check… ok here we go:
public static let minimumValidDuration: TimeInterval = 10
public static let minimumValidDistance: Double = 10
public static let minimumValidSamples = 2
public static let minimumKeeperDuration: TimeInterval = 60
public static let minimumKeeperDistance: Double = 20
So first of all it has to pass the “valid” test, ie 10 seconds, 10 metres, and 2 samples (enough for a start and an end). Easy.
Then it needs to pass the “keeper” test, ie 60 seconds and 20 metres. Also pretty easy. (Though I’m inclined to reduce that 60 seconds to something shorter. There’s plenty of times there’s a short walk between two places, maybe 30 seconds, and it feels like it should be its own timeline item).
The catch with underground train trips is that it can often be that no data is recorded at all. No new location data is coming in, so no new samples are recorded. Then there’s no samples to work with, so it all falls down.
And that’s something I can tweak and fix! I can make sure that it keeps predicting new location coordinates, and keeps recording samples with at least pedometer and accelerometer data, perhaps every 10 seconds or so. (I think it already does that now, but at 60 second spacing maybe).
I also did some work to improve underground train trip recording many years ago (like 6+ years ago) that worked quite well, with special case tweaks to the underlying location data filtering system (the Kalman filter). That work actually got lost somehow, and disappeared from Arc Timeline app. No idea how - I just realised one day that it wasn’t there anymore, and could only vaguely remember what it was.
Anyway, that work I can redo. I know this stuff inside and out (through years of painful experience I’m probably one of the main experts on this stuff now). So I can just recreate that testing and tweaking work, to get the low level location data recording working better in those special case conditions.
I just need to spend a day going back and forth on underground trains, collecting data and observations. I’ll look like a freak to the staff, but it’ll be worth it
Extract brief visits: perhaps such could be one list instead of paginated? To get a visit with somewhat accurate times it takes selecting multiple from such. Maybe some multiple select also could be useful.
From extract brief visits, it seems sometimes there are samples that are somewhat off such as previously visited locations that could be a mile or kilometer away or more.
The pending tasks didn’t do anything for over a night.
The battery usage is 17% for first day. (iOS26) but not did any task?
Unfortunately that’s not something we can control. That’s iOS’s choice, as to when it decides it wants to start the tasks, and how long it wants to allow them to run for. But don’t worry, it’ll allow them to get done eventually! It shouldn’t be much longer.
What’s the screen time looking like? The amount of screen time is what matters for battery use. When it’s in the background it consumes almost no battery, but when in the foreground (ie on screen) it consumes many times more battery.
Which is true of all apps. But apps with map views (and especially frequently updated maps) it’s more significant. Maps are expensive in battery terms!
Oh, @o1x, in the Settings tab tap View Logs at the top right, open one of the log files (maybe most recent or maybe on that was for an overnight period), then tap the filter button (circle with lines in it), then select “tasks”.
That will show you the background task start and end times. If there’s a line saying “expired” that means iOS stopped the task before Arc Editor managed to finish it. If it says “unfinished” then it means Arc itself stopped the task before it finished, for some reason. “Running” is when iOS starts the task.
@o1x Each time the app restarts a new session log file is created. Is that from a single log file that covers 2 whole days?
No. Every log file in past 2 days is the same result. two tadk registed and nothing else
