Arc Editor public beta 13

Announcements
1

1.0 (build 36), 2026-02-17 13:35 (Bangkok)

New Features

Foreground Data Processing (BIG-280): When background tasks haven’t completed (e.g., after import or extended inactivity), the app now processes overdue tasks while in the foreground, with an inline status banner showing progress. Processing pauses automatically when the device reaches a high thermal state.

Bug Fixes

  • Fixed rare repeated crashes on launch (BIG-296)
  • Fixed migration from Arc Timeline leaving all imported data invisible if interrupted during sample import. Also added persistent import state tracking — interrupted migrations are now detected on next launch and can be resumed (BIG-295)
  • Fixed arrival time, leaving time, and duration histograms in Place Details showing incorrect distributions (BIG-281)
  • Fixed weekday labels being shifted in Place Details occupancy chart (BIG-277)
  • Fixed calendar popover dismissing when browsing between months or years (BIG-283)
  • Fixed timeline paging allowing infinite backward navigation past earliest data. Also fixed inability to navigate to the earliest time period when it contained a partial period (BIG-270)
  • Fixed debug log viewer corrupting multi-byte characters (e.g., non-Latin scripts) due to incorrect UTF-8 line splitting (BIG-131)
  • Fixed missing special characters in German localization text (BIG-276)
  • Fixed Fibonacci timing markers in debug logs not progressing beyond --1--, needed for diagnosing potential overnight app suspension (BIG-287)
2 Likes
2

G’day, Matt. I’ve been an on/off user since, I dunno, 2019? Big fan.

Small issue: when I open the Places view (both in this version and beta 12), it appears to get stuck in a loop trying to evaluate the same place over and over:

[12:24:45.918] [LIFECYCLE] ArcTimelineEditorApp.becameActive()
[12:24:47.881] [PLACES] Reverse geocode missing locality for place: Atlantic Aviation PLS
[12:24:47.980] [PLACES] Reverse geocode missing locality for place: Atlantic Aviation PLS
[12:24:48.076] [PLACES] Reverse geocode missing locality for place: Atlantic Aviation PLS
[12:24:48.242] [PLACES] Reverse geocode missing locality for place: Atlantic Aviation PLS
[12:24:48.393] [PLACES] Reverse geocode missing locality for place: Atlantic Aviation PLS
[12:24:48.543] [PLACES] Reverse geocode missing locality for place: Atlantic Aviation PLS

ad infinitum. I didn’t see an obvious way to increase the log level, so that’s all I have.

This is a real place that I selected, so I’m not sure why it’s struggling with it in particular: Google Maps

Hope that helps!

1 Like
3

Ah yep, I’ve seen this problem too. It’s on my radar, for hopefully fixing in the next update!

Though the first fix will unfortunately just be “give up”. Apple’s reverse geocode service drops out in some areas, and sometimes even in areas where it’s not that hard to get it right. (Weirdly a common one is around major airports).

The proper fix will come later, which will be to have the system fall back to checking with Google Places is the Apple service fails to give an answer. The catch there is Apple’s service is free while Google’s is absurdly expensive. Otherwise I’d just have it always use Google’s service. But yeah, if it’s just a fallback in these edge cases then it shouldn’t become a financial problem (unlike the Google Places search results already in the app, which eat up almost a quarter of the app’s revenue each month :grimacing:)

4

Yeah, I saw that comment somewhere else about Google’s service. I’m glad you’ve been able to move away from it!

Although if I may… what is reverse geocoding used for in this context?

I can understand needing it when searching for the names of nearby things to associate with a lat/long. But I already chose this place to associate with this lat/long, on the day.

So doesn’t Arc already have a name, and a coordinate, and what more does it need?

5

Reverse geocode is the process of giving the service a lat,lon coordinate and having it return a street address for that coordinate. Well, street address, city, country. The last two being used for the Places tab, to know how to group the places in the reports there.

If a Visit has been assigned a Place that came from the Google Places service, then yeah there’s a possibility that the street address, city, country details were already available from that Google Places result. In that case reverse geocoding wouldn’t be needed.

But unfortunately databases like Google Places are largely (or often entirely) human curated, with unreliable data, inconsistent styles (LA / L.A. / Los Angeles, los angeles, etc). Missing data, wrong data, all sorts.

The reverse geocode services work from the properly curated and managed location databases managed by formal agencies. And are (or should) be properly consistent in style, accuracy, etc.

So for example a Google Places database entry might have:

streetAddress: “123 brown st, st sndrews, upper southton, MONGOLIAN”
city:
country:

While the reverse geocode service result will be:

streetAddress: “123 Brown Street, St Andrews”
city: “Upper Southtown”
country: “Mongolia”

So you can see the first choice has to be the reserve geocode service.

Google Places database has the best coverage of places data, businesses, etc. So it’s the right choice for place search results when we want to find Starbucks etc. But for clean and consistent street addresses reverse geocode is best.

Anyway, that was a long winded answer! Heh. Sorry about that. I ramble.

6

I see, that makes sense. I appreciate the answer, thank you! :grinning_face:

7

Today the app crashed consistently on opening. Do you get crash reports through TestFlight? There’s virtually nothing in the logs.

I was starting a walk at the time, and it had been dead for ~6 hours when I opened it the first time, if the log gap is any indication.

After the sixth crash I shrugged, gave up, put my phone away. But somehow it recorded the rest of the walk from that point? And now it doesn’t crash any more.

Anyway, this is probably not very helpful. :laughing:

8

Actually kinda helpful! Though unfortunately on the question of whether crash reports come through, the answer in this case might be “no” :disappointed_face: Sometimes yes, sometimes no - it’s unreliable.

The most recent build (you’re on build 36 yeah?) was supposed to fix exactly what you describe: a repeated crash on launch. So either what I thought I fixed wasn’t the thing causing that crash, or there’s more than one of them.

Yeah this is the most telling clue for me. And was also the case with the other crash that I thought I’d fixed. It appears to be something in the UI triggering the crash. So if the app restarts in the background, no UI loaded, then it stops crashing. But when it’s brought into the foreground and the UI loads, if whatever is causing the crashes is still present at that time, bam, it crashes again, and again every subsequent time you try to open it.

Anyway it sounds like most likely what’s happened is I fixed something else, and not the repeated crash on launch. Damn. I’ll have to go back to hunting for that one!

9

Though unfortunately on the question of whether crash reports come through, the answer in this case might be “no” :disappointed_face: Sometimes yes, sometimes no - it’s unreliable.

Wow, that’s really bad for such fundamental infrastructure. I’m disappointed!

I did use Sentry with some success in the past, but it’s been a number of years, and it was a desktop app.

In that case, just in case it’s somehow useful, this is all I got before the crash:

[16:55:58.644] [LIFECYCLE] ArcTimelineEditorApp.init()
[16:55:58.659] [TASKS] registered: placeStatsUpdates
[16:55:58.660] [TASKS] registered: activityTypeModelUpdates
[16:55:58.661] [TASKS] registered: workoutImportCleanup
[16:55:58.831] [LIFECYCLE] ArcTimelineEditorApp.becameActive()
[16:55:58.835] [TASKS] registered: incrementalBackup

On the next launch – where it restarted in the background, I left it alone, and it carried on – the next line of the log was this:

[16:58:00.480] [ERROR] [HEALTHKIT] Error Domain=com.apple.healthkit Code=6 "Protected health data is inaccessible" UserInfo={NSLocalizedDescription=Protected health data is inaccessible}

…which is interesting, because that did not appear in any previous log that I’ve seen. I have no idea whether it’s relevant to the crash, but it’s an anomaly. Notably Arc does have permission, and this hasn’t changed recently. The Permissions debug page has :white_check_mark: for heart rate and health stats, and “Incomplete” for workout import / HR zones (presumably because I don’t really use apple health for anything).

The most recent build (you’re on build 36 yeah?)

I am, yeah. Although it should possibly print this in the log on startup, just to be 1000% sure! :sweat_smile:

10

I find that recently Arc Editor has a tendency to hide a journey inside a visit unless I manually go into the individual segments view to confirm it’s a journey. For example I travel from A to B, involving ~20 minutes on a train plus a few minutes of walking. Arc Editor would show a visit at A, a few minutes of walking, and then B. However if I click into the visit at A, the journey now appears on the map. When I get into the individual segments view, it then shows the segments alright. I need to click each segment to confirm it’s a train ride, and then it shows up on the main timeline.

I hope you get the idea. If not I can try to capture a screen recording

This also used to happen early in the beta but now it’s very often. Any ideas how this might come to be?

11

The places count is quite large, any chance for a toggle (I don’t really like counts in general but I get that it mirrors swarm functionality)

IMG_9897
IMG_98971206×2622 226 KB

12

Arc Editor actually has Sentry too. Though last time I went to use it to find clues on something it was over the free limit, with old Arc Timeline builds flooding it (Sentry is in some of those builds too), causing it to drop reports from Arc Editor. sigh

I need to reassess Sentry’s utility and possibly/probably go back onto a paid tier with it. It’s certainly better and more reliable than Apple’s built in crash report collection (which is dismal).

Anyway, on the issue of the repeated crash on launch, I think we finally got it fixed yesterday! The “fix” in build 36 turned out to be a red herring, but yesterday it happened while the app was connected to Xcode/debugger and we caught it in the act. So next build should have the proper fix! :tada:

The cause was something in timeline processing, same as we thought last time, but this time we found the correct lines instead of the red herring ones. Processing will fire up on fresh launch either triggered by new data or by timeline UI things. So that’s why you see a bit of log activity, then bam, crash. The processing isn’t immediate on launch, but is soon after.

That HealthKit error is a weird one, but also luckily a harmless one. The HealthKit database gets locked when the app is in background / phone is locked. Which is what that error means. All of Arc Editor / LocoKit2’s HealthKit access attempts are gated by checks that the app is in the foreground, but HealthKit can be slow to respond. So sometimes by the time it responds the app is already in the background / phone locked.

Harmless, but it would be nice to be able to work around that. I think though probably I’ll just concede defeat and catch those specific errors and drop them before they hit the log files.

Oh yeah that makes a lot of sense! Great idea. I’ll log that to do that today :tada:

I think I’ll try to get a new build out too in the next few days. That crash-soon-after-launch fix would be good to get out properly this time, given the last “we totally fixed it, honest!” one was a fail.

13

@trackerminerfs yep, I definitely get what you’re saying. I see the same thing.

The problem I think is that the … when LocoKit2 is waking from sleep, checking to see if you’ve moved, it’s overly conservative about detecting movement. It goes back to sleep. But it still records samples on each wakeup, so it still builds up that data of the movement, but it puts them inside the Visit instead of correctly splitting them out into a new Trip item.

Then eventually it does realise you’re moving, it creates a new Trip item, and starts putting new samples into that. But it’s already shoved a bunch of samples into the previous Visit that should’ve gone in the Trip.

Anyway I think the way to fix that is … well, maths stuff. Heh. I’ll get to tweaking the various thresholds on Stationary State Detection, that sort of thing.

14

Heh. Those were even larger by default! But yeah, they could go smaller still. I’ll try nudging them down in size and see how it goes :+1:t3:

15

For what it’s worth, I too was hoping for a way to switch off the counts, and just have dots.

16

Yeah, we ended up using Sentry in only a few places where other tools did a bad job, and we remained well inside the free tier.

yesterday it happened while the app was connected to Xcode/debugger and we caught it in the act. So next build should have the proper fix! :tada:

Delicious! Thank you!

1 Like
17

I think the problem here is those counts have important meaning. They mean that there’s X places clustered in that region, and zooming in will show you them.

If the counts are gone completely that information is lost, and you’ve got … what? An overlapping mess of dots? I don’t think it works. Or at least, from my perspective a single dot with a count is better UX.

Though certainly I can shrink the dots down! I’m going to try that today. See how small I can get them without the text overflowing the edges.

18

Hmm, so this is a new one.

The update says 2 days 6 hours. Despite this, my Timeline and Activity views for today are completely empty. (It just shows “timelineItems.isEmpty”)

My visit to home from last night does appear to have been recorded correctly. That visit is said to end at 09:04 today (despite not appearing on today’s timeline!), and then none of my subsequent comings or goings are recorded.

I’m tempted to restart the app to see if it magically comes good – if the data was recorded, but is perhaps not being displayed – but I will leave it alone for now in case there’s something you want me to try first.

19

Yeah that would be my first instinct. That the UI is jammed up, something’s backlogging or deadlocking and the UI can’t get the data from the db that it needs.

Or at least, I hope that’s what it is! If not… :grimacing:

20

Oh either way I think is fine. If it doesn’t come right on its own, give it a fresh launch.