**Important**: This build requires iOS 26 or later.
### Bug Fixes
- Fixed visits list view with 600+ visits taking several seconds to appear with sluggish scrolling (BIG-177)
- Fixed visits list view map showing all fetched visits as greyed-out markers instead of only currently visible visits (BIG-191)
- Fixed map auto-zooming every few seconds during active recording when sheet was minimized, making manual map inspection impossible (BIG-187)
- Fixed Activity Classifiers section in DebugView appearing empty after iOS 26 migration (BIG-189)
- Added confirmation alert before deleting visits to prevent accidental deletions (BIG-192)
### Improvements
- Improved predicted leaving times for Home-style places to search into next day, now finding most probable leaving times in breakfast hours instead of only same-day predictions with very low probabilities (BIG-188)
- Predicted leaving times now displays only top 3 highest probability predictions instead of showing all predictions (BIG-188)
- Added visual indicators showing currently assigned Place and ActivityType in Item Edit view (triangle markers at leading edge) (BIG-190)
- Moved Confirm button from content area to bottom toolbar in Item Edit view for better iOS 26 Liquid Glass integration (BIG-190)
- Improved place ranking to prioritize recently-visited places using recency scoring with 30-day half-life (BIG-186)
### Work in Progress
- Added partial workout import UI (workout buttons on timeline days, workout list view) - this feature is incomplete and non-functional, best ignored for now (BIG-70)
After installing, maybe it does some silent db migration? I also restored from a Mac to a new phone a few weeks ago but I don’t think that is related.
As I was fixing visits, I looked at some older dates and they showed empty timeline. It seemed to eventually fix itself perhaps after waiting a while or possibly closing and restarting app (perhaps unnecessary), then the data appeared. Perhaps some improved message later if such or something else is occurring.
Trying to fix visits such as by selecting view in timeline at times didn’t work (I’ll try gain later), not sure if because of such.
Unfortunately I updated to beta 5 and I’m not at all able to launch the app. I launch the app, I see a plain white screen with nothing on it, and then a few seconds later the app crashes. iOS even tells me it crashes.
Yeah it does. It’s a migration that should take only a fraction of a second, so I didn’t put it in the “deferred migrations” section, I just put it in the normal section that’s done immediately on launch. But then mysteriously it’s taking multiple seconds! On my phone it felt like maybe 10 seconds. But for some testers it’s been long enough that iOS has terminated the app
So I’ll be sending out a quick new build today, moving that migration to the deferred/delayed list, so that it can take its time, doing its thing after app launch has finished.
For this one, this is probably the weird “timeline subsystem gets jammed up” bug that’s mentioned here. I explain the background on it there, and yeah unfortunately it’s still present in this new build. Hopefully I’ll pin down the naughty code and get that one fixed soon.
If you see it happen, you can confirm it’s that problem by doing into the debug view and seeing the active operations list grow, with some tasks ending up sitting there incomplete for up to minutes. Backgrounding the app for a couple of minutes should resolve it (though I’m not sure why - this one’s being sneaky, with the real cause hiding from me!)
Yeah that very “debug” looking “timelineItems.isEmpty” or whatever is… not great UX I need to change that to actually explain what’s going on, at the very least. Either “there’s no data” or “I’m busy processing, brb” or “something else is going on”.
As I was fixing mis-assigned visits from the visits list, I find that using the map can be easier since I may not know which one is incorrect from a list.
Perhaps map locations can be selected with long hold and that also providing a context menu with view in timeline?
Btw for one visit, I am in North America yet one incorrect visit had a gps location somewhere in the ocean off the coast of West Africa. Maybe some iOS bug.
Visits and Trips on the map can be tapped to open a little info tooltip. If you then tap on that again it’ll take you to the item details view for that item.
Yeah that sounds like possibly “null island”. Essentially 0,0 coordinates. It’s possible the LocoKit2 recording engine somehow accidentally created that (though I’ve never seen it happen), but also possible iOS returned that nonsense coordinate by mistake too. Can just find that specific sample in the item segments view, and split it out as bogus to clean up the mess. And hope that it doesn’t happen again!
Not sure if mentioned. Not to add to much yet perhaps to think about for later.
At times app may do stuff like have numerous successive visits such as a minute long or something of the sort and then figure out it’s just the same visit. That or other times where it can in a sense appear messy, maybe some alternative way of progress shown as thinking and then show final results. Maybe that’d appear more elegant, clear, polished, etc. yet maybe wouldn’t work in all cases yet perhaps some.
This is probably something you know, but I noticed that Arc Editor (LocoKit2) has a tendency of spreading out certain journeys in time when GPS accuracy is low. For example I arrived home today at 7pm. But when I check my timeline on Arc Editor it says I arrived home at 7:20pm. Attempting to split the segment at exactly 7:00pm (using the scissor button) results in large parts of the previous journey reassigned to stationary. GPS accuracy is low so Arc Editor just draws a straight line between the previous visit and the new visit. But it’s surprising to me that it would extend this journey in time.
It already does this to some degree. If you see “Thinking” in the timeline that’s often hiding more than one item. Like, behind that “Thinking” there could be many small items, but instead of showing all of those it just shows that thinking line to hide them until they’re cleaned up.
But yeah, if there’s a “keeper” item between each non-keeper, then it will end up looking messy, and the UI display logic doesn’t have a good way of presenting that more tidily yet.
@trackerminerfs Hmm. That to me sounds like it got a data gap - no location data for a period of time. Which could mean Arc Editor got suspended by iOS or even terminated.
Though hard to be sure what it was exactly. I haven’t seen similar patterns in my own data, so it’s not something I’m aware of. But yeah, I’m leaning towards guessing it was some situation where either it was provided no location new location data or was actually suspended/terminated for that period of time.
The actual recording logic in LocoKit2 in Arc Editor isn’t significantly different from old LocoKit in old Arc Timeline. So mostly it should have similar recognisable recording patterns and behaviours. It’s just “better” code, maths, algorithms than old LocoKit, so when old LocoKit started to fail LocoKit2 will generally cope better.
I see. Okay a data gap seems like a reasonable explanation. And there’s no Arc Recorder acting as a backup for Arc Editor.
I’ll provide another example. Today I got off the train at 7:07am (I took a picture of the train station and looked at the timestamp on the photo) and then started walking. The old Arc Timeline captured this perfectly. The Arc Editor shows that I’m still hundreds of meters away from the train station at 7:07am, and that I somehow walked along the train tracks to the train station. I manually changed that portion of the segment to train, and now Arc Editor shows that I started walking at 7:10am. It’s just three minutes so no big deal in this case, but I’ve seen worse delays of more than 10 minutes between actually arriving somewhere and Arc Editor reporting of arriving at that place.
@trackerminerfs Hm, yeah that sounds like a repeating problem then. Data gap still feels like the most fitting explanation, but if it’s happening that frequently I’m feeling less confident in that.
Either way, it would be great to have Arc Recorder there to take up the slack in these cases. It does that job really well for Arc Timeline, but Arc Editor has no backup buddy yet. Feels like the time is close for changing that!
This is the current trip details screen. There are a few different buttons used for both actions and navigation here. The “cleanup” button in the bottom left will consolidate all the trip’s segments into one Cycling item (which in this case, was the correct mode of travel) but it won’t actually confirm the item! The user has no indication on this screen that additional confirmation is needed and there are no hints of why they should go to the edit tab (where the confirmation button actually is).
My current thinking here is that the confirm button and cleanup button’s function should be merged and “confirm” action fully moved to the first details screen instead of being hidden in the trip mode screen. Ostensibly, if you wish to confirm the trip mode, all the segments are correct. If you want to change the trip mode, that would act as confirmation as well (and currently does) making the “confirm” action redundant on this screen. If the segment isn’t properly representing a trip that took place with multiple modes, you would edit that with the segment editor which is nicely grouped beside the trip mode editor.
Good point. Yeah, there should be some indication that the assigned type still isn’t locked in / confirmed.
This comes up periodically, and I’m usually in the camp of not liking the idea. Or at least, I think there’s high risk of user confusion, and actions happening that they didn’t intend.
But it’s a grey area. I don’t think it would be the worst outcome for the Confirm button to also do the same as the Cleanup button. (Though not the Cleanup button do the same as Confirm). Actually, currently I think it might even do that? Like, confirming a Trip might already be setting all samples to that chosen type (except for stationary samples that have a high enough classifier confidence in being stationary).
The way I see it, these buttons can be combined and any errors as a result of that process should be dealt with by splitting the trip into the desired segments with the segment editor. This creates a clearer user flow of unverified data → confirmed data → split segments if needed → success, OR (if a user has chosen to clean up their timeline at the segment level) unverified data → correct segments (which I assume are also marked as confirmed) → success. Perhaps the cleanup function in the segment editor could be improved to accomidate the second user flow!
Currently there’s a cleanup button step somewhere in there, and it’s not clear where the user should accomplish that. Should they clean up before or after verifying segments? Does that change the outcome? Does the cleanup button also confirm the path now that they are all the same type?
For the first few months of using Arc I would always clean up paths but didn’t bother to confirm them because I assumed this was the success state, the timeline looked correct! After finding out that this wasn’t the case, I had to go back and manually confirm months of data. All that to say, I would challenge your assumption that the current method is confusion free
Yeah there’s a lot of implicitness about these actions and steps. I agree that’s not great, and something more intentional needs to come out of this.
Though to a certain degree I think some variance is acceptable and good, in that different people will find different preferred workflows. Some people will want to start by setting everything to the same type, regardless of what segments the classifier settled the data into, then do their own splitting up manually after that. Other people might want to work with the segments the classifiers created, coming from that direction first.
Personally I do a mixture of both, depending on how good a job the classifiers did. For a lot of my common routes the classifiers actually nail it first time. There’s walking → stationary → train, correctly indicating walking into the train station, waiting 30 seconds for the train, then off on the train ride. In that case using the Cleanup button would create more work, not less. I’m better off tapping on the stationary segment, assigning it to the train station Place, and then… job done, the rest is already correct.
But other times the classifiers haven’t managed to make clean sense of it, so I’m better off tapping Cleanup, then getting busy with segment splitting.
And I think that flexibility is partly what I’m trying to preserve, by not having the Confirm button also do a full Cleanup (although I still suspect at this point if effectively is doing the equivalent of a Cleanup at the same time).
There’s also the mixing of concepts. Confirm is the intentional communication of “Yes, this assigned type is the correct one. Lock it in”. While Cleanup is a less explicit communication of “The assigned type looks right to me; I just want the segments/samples to all be the same type”.
Ah, now I remember what distinguishes Confirm from Cleanup. Cleanup won’t touch any samples that already have a confirmed type. So if you’ve already done some segment splitting or segment type setting, those will have locked in confirmed types, and the Cleanup button will only touch the other samples that don’t have a confirmed type.
The Confirm button however will override any existing confirmed types on the samples. So if you did some splitting and tidied up some stationary segments within a Trip (little 30 second stops for example, that you don’t want split out as separate items), if you Confirm or change the type of the Trip on edit view, you’ll overwrite those confirmed assignments, forcing all the samples to the new/Confirmed type.
Hmm. Cleanup should in most cases achieve almost the same. Though … actually I’d better check the code. I wonder if it only changes/confirms the types of samples that were classified as a different type, leaving alone the samples that were classified as the target/majority type…
Ah yep:
var filteredSamples: [LocomotionSample] = []
for sample in samples {
if sample.confirmedActivityType != nil { continue } // don't mess with already confirmed
if sample.activityType == tripActivityType { continue } // don't mess with already matching
// let confident stationary samples survive
if sample.hasUsableCoordinate, sample.activityType == .stationary {
if let typeScore = await sample.classifierResults?[.stationary]?.score, typeScore > 0.5 {
continue
}
}
filteredSamples.append(sample)
}
So it will only change/confirm samples that aren’t already the target type. And also leave alone ones that are confidently stationary.
So that would mean that items that already have mostly the “correct” type on the samples won’t end up “confirmed” / locked in.
I think what I’m saying there is I still don’t have a good answer to your argument! I’m still thinking it through. Trying to decide where I stand on this one. It’s been a long running thing, and I think my own intuitions, expectations, wants, don’t line up with what a lot of other people want. So I’m trying to flesh out in more detail my understanding.
I need to change that to actually explain what’s going on, at the very least. Either “there’s no data” or “I’m busy processing, brb” or “something else is going on”.
