Not much to report so far. One thing about the Show in Maps (and directions). Not sure how much of a use it is to have both. Using it, maybe someday there could be a preference to set default maps app? If only Apple Maps is installed, maybe it is cleaner to just open in maps rather than prompt with a menu?
No bugs discovered so far. The week, month and year display doesn’t work properly (slowness, loss of display on the map, processor freaking out) but I suppose these functions are still being fine-tuned.
Good work, Thank you!
All my pending updates have been processed so far. I‘m currently on 0/0. And happy .
Haven‘t checked the new features yet.
But here‘s a minor bug in the map view. I already noticed it in the previous beta:
Long distance tracks are not displayed, and the the map view focuses on North Sea (in my cases, traveling France)
Hi Matt,
I’m a heavy user of arc since the Moves down.
It’s so glad to see a revolutionary update in the recent. However after a preliminary trial I have some opinions about the new app.
Firstly, the new app name ‘arc editor’, I thought it should have higher editing permissions than arc timeline, such as edit the specific location coordinates at a certain moment, or draw a historical airline trail that miss recorded, but now I can’t find somewhere to ‘edit’ more than arc timeline.
Secondly, I have complained before that the blue positioning arrow on the Smart Island in Arc Recorder seriously affects daily operations, causing accidental touches and interfering with notifications from other apps. I understand that this is Apple’s problem, but this is the sole reason why I have resolutely deleted Arc Recorder: Arc is expected to run quietly in the background, rather than constantly prompting me. Is it possible to use the original positioning technology to avoid the blue arrow? Or just keep arc timeline running, after all it doesn’t annoying at all.
Thank you for all your efforts, I want to express my love for this extremely excellent app again.
As a long time Arc user, I must say that the new App is amazing. Quick, pretty accurate already and full of potential. Can wait to see what other ‘goodies’ you have to surprise us with.
Do you have both installed? It should only show the available ones in the menu. Oh but it looks like it is always showing the menu, instead of just going to Apple Maps if that’s the only one installed. Oops. K, I’ll fix that. That’s a pointless step then in that case!
The new app is a joy to work in on my side. Much, much cleaner code, so I can build much faster, and without the risk of all sorts of weird mysteries, like what would happen in the old app. The older apps get, the worse they are to work on, and Arc Timeline is almost 10 years old now!
I’m looking forward to fleshing out the new Places tab soon. I think there’s some really fun stuff to be done in there. Though for now I’m going to keep working on filling in all the missing bits from the basics, like finishing up timeline view, item details views, Activity tab, etc.
There’s still a lot of groundwork to be done. But at least with the new app it’s much easier and faster to add new stuff! Fun times ahead.
Yeah the week/month/year views on timeline tab, and well, all the tabs, are very basic/broken at the moment. I basically added the menu options to change the date ranges, hooked them up to the underlying data structures, then left it. The UI is dealing with that change and being very “wtf just happened?” about it And there’s no custom designs for different ranges yet either.
At the very least I’ll get the UI properly understanding the change soon - probably in the next build. Then the next step will be to have the UI potentially change styling, depending on range type. A month or year view doesn’t work great when using the styling built for day views, for example.
Unfortunately this is in both beta builds, and is a frustratingly known bug. It’s to do with the new map projection that the newer Mapbox SDK is using.
Arc Timeline app uses an older Mapbox SDK, which uses the Mercator projection. That’s a simple rectangle, so the map can zoom in to any part of it (except the extreme edges) and align to the correct view area.
But in the new Mapbox SDK that Arc Editor uses Mapbox is using a globe projection. So as it zooms out … it doesn’t fit anymore, and the SDK’s zoom feature breaks. If you swipe down the timeline sheet you can see underneath that it’s still zooming to the correct area, in full screen. But when the timeline sheet is in normal position it’s supposed to be taking into account that offset/inset, and the SDK’s zoom breaks that functionality when zoomed out far enough.
So it’s kind of a Mapbox SDK bug. But one that I’m going to have to work around myself (Mapbox simply ignore support requests or bug reports unless you’re paying expensive monthly support contract fees).
Anyway, yeah, known, and annoying! You’ll basically always see the bug when there’s an airplane flight in the day, or a longer train trip.
It’s called Editor because the initial intention was to build out only the timeline tab and the timeline editing functionality. Though since I named it it’s evolved to be covering more of the breadth of Arc Timeline’s functionality from the start.
The goal is not to change the app’s core functionality. It’s explicitly a ground up rebuild of the same app, to get rid of the decade of accumulated code cruft that makes maintenance hard and slows down the adding of new features. So during the beta period you will largely see Arc Editor flesh out to have the same features as Arc Timeline, albeit without the bugs and mysterious behaviours.
Goals of either changing the app’s features or extending them are separate to this project. Yes Arc Editor makes it much easier to add new things or change existing ones, but the goal isn’t “throw out all the UX and app design work done for Arc Timeline app”, it’s “rebuild Arc Timeline app to get rid of the decade of cruft that weighs the project down”.
For historical flights, or importing flights that Arc failed to record, there’s a feature request for that on the Changemap site, and it’s a high priority feature to add next. I was actually about to start building it just before I switched to doing this ground up rebuild. (The process of adding that feature started to make it clear that the rebuild really had to happen, and I couldn’t keep putting it off).
Or editing the coordinates of recorded data… I’m not sure if there’s a feature request for that on the Changemap site, but worth having a look.
Possible, yes. Going to happen? No.
Doing so results in worse battery life, and increased risk of data gaps. Apple have made it clear that they don’t want that old system used, and will make it increasingly difficult and problematic to do so.
I hate it as much as you do, but Apple have made their wishes fairly clear, and in a battle between Apple and me they will always win. I’m very much the little guy in that fight.
When editing a visit and choosing place, some places don’t show distance?
Seems that choosing place as well as the app itself figuring out what place it is, it can suggest places over a kilometer or mile away which seems was not the case or was less frequent with 3.x
If it doesn’t show a distance then it means it overlaps with the Visit, so there’s technically zero distance between them. Those Places will be grouped separately at the top - overlappers first.
Yeah the Place scoring / ranking maths doesn’t seem to be as well tuned as in old Arc Timeline. I improved it a bit in beta 2, but I’m also not seeing good enough results a lot of the time. I’ll keep chipping away at it!
Yes it is the overlapping places at the top that don’t show a distance. Yet how overlaps are calculated perhaps that could be improved? Looking at some visits today; it shows other overlapping places that are several kilometers/miles away. Not sure if such is from old mis-identified visits
I love the beta 1 and beta 2.
There is one thing I would like to see improved. Due to the nature of my work I often go to multiple new places on one day. That generates a lot of stops and movements, and it needs cleanup. That is ok. But when I edit a place or activity on the bottom of the list and click < to go back to the list, it goes to the top of the list and I have to scroll down again. How about returning to where I was?
To repeat myself, I LOVE the betas.
Right now I am cleaning up Timeline and Editor every day. I’d like to stop cleaning up Timeline. Would that be a good or bad idea?
I don’t know if this is because I have Arc Recorder installed and it is helping Arc Timeline. But I haven’t experienced any data gaps in the Arc Timeline app for many months. The same cannot be said for Arc Editor. Today I went to a shop, spent five minutes buying things and then walked back home. And yet the Arc Editor app didn’t have the walk back shown on the main timeline. When I went into individual segments view and tried to split the stationary item, the walk journey showed up, but it was more than 10+ minutes late as compared to the Arc Timeline. That is to say, Arc Timeline said I walked back home starting from 12:42, but the Arc Editor app said the walk started from 12:55.
I’m unsure how these two apps can disagree. My hypothesis was that Arc Timeline and Arc Editor were both suspended by iOS and Arc Recorder actually recorded the journey for Arc Timeline. And Arc Editor perhaps synthesized it later based on the jump?
Yep. That’ll be what it is. The radius of the Place has expanded out too far, due to some incorrectly assigned Visits.
Though unfortunately Arc Editor doesn’t yet have the useful map view that helps to find those incorrect assignments. When you scroll down the list of assigned Visits it doesn’t update the map to show the currently visible ones. Which makes finding them next to impossible. I’ll have to get onto building that feature! It’s already high on my list, so hopefully in the next TestFlight build…
Oh I hadn’t noticed that! Hmm… testing now, I’m not seeing it happen. Though maybe a certain kind of edit is required. I can imagine the timeline list view updating, and then losing its scroll position state and resetting to the top.
Yeah I still can’t trigger the wrong behaviour here. I’ll keep trying. It does sound like the kind of thing SwiftUI would do under some conditions…
Depends how reliably correct it’s getting things!
For myself I can’t stop myself - I’m going to clean things up, because I don’t like to leave any detail unresolved. But there’s no reason why anyone should have to do that. If the processing engine and classifiers are getting everything right, then why bother with the extra effort?
I would say though that it’s important to do the necessary cleanup and confirmation on those new places you go to during the work day. New places and new routes are new information that the classifiers and Place models won’t be certain about until you’ve confirmed or corrected them. So there’s risk of over time the system making worse decisions in those geographic regions, due to lack of confirmed data to guide it to more sensible choices.
But really, if it’s getting things right, we shouldn’t be required to do any extra work ourselves. I do however I think still need to fine tune the confidence thresholds a bit more. Like, sometimes it’s labelling things “uncertain” when they really shouldn’t be - the system should have high enough confidence in those assignments already.
Oh I guess that’s the other point: the things labelled “uncertain” are high priority for cleanup. The things labelled merely “unconfirmed” are just there for housekeeping. If you confirm them then you lock them in, so that the system won’t change them later. But the classifiers / models aren’t saying “I need help here”, it’s just giving you a heads up on what hasn’t been explicitly confirmed yet.
The debug log files can tell you for sure whether Arc Editor had been terminated or not. You can tell by the time of the last log line of one log file, and the start time of the next. But it’s still possible for iOS to suspend the apps sometimes (even though it really shouldn’t, by its own rules). Which means technically the app session is still going - it hasn’t been terminated.
So in that suspension case the debug log files won’t show the end of one session and the start of another. Instead they might show a time gap between log lines that looks unrealistic, or matches the gap in the recording.
For myself, I’m finding Arc Editor much more reliable than Arc Timeline in uptime. It just doesn’t get terminated on my phone. My most recent app session was over 5 days! It only ended because I had to restart my phone (I’m on the iOS 26 betas, and the betas are occasionally getting themselves in a mess and requiring reboot).
But if Arc Editor is terminated, then yeah there’s no fallback. There’s no Arc Recorder yet to buddy up with Arc Editor. And if Arc Editor gets suspended, likewise no Arc Recorder to notice that either.
I want to eventually do an Arc Recorder build that’s switched over to buddying up with Arc Editor. But I haven’t yet figured out how to do that gracefully. We can’t easily have two Arc Recorder apps installed. So things start to get a bit messy. Though I’ll figure something out.
I am a new user just discovered the app, and read through the forum. As I understand, this is the newer app built ground up, which looks exciting btw. Is the recommendation wait till the new version becomes available? Sorry if this was already answered!
.
And there’s no custom designs for different ranges yet either.