Yikes! I have deleted and reinstalled on Saturday. Now it’s still restoring. I will wait then.

Yeah this iOS bug sucks in that it really genuinely makes it look like Arc has broken. So a lot of people have deleted and reinstalled, but ended up right back where they started, because a reinstall can’t fix it.

Restarting the phone will stop the iOS bug. But after that you still need to leave Arc in the foreground, viewing the messed up timeline days, until the processing engine has had enough time to clean up as much mess as possible.

Manually cleaning up mess yourself will help too. Any timeline items you see in recent days that are nonsense / can be fixed / corrected, if you go into them and edit them as best you can, that human hand will be a great help to the processing engine’s efforts in doing the same.

Can you not have Arc detect this nonsense data and suggest to turn the phone off and on (making clear that the underlying issue is with iOS)? I realise I suffered this issue in March for a week or two and didn’t think to turn it off although I’m sure I would have tried a hard reset…

Having Arc “not detect” this data would require being able to identify it automatically. Given that Apple have made no public statement or acknowledgement about the problem, and that it’s never happened on any of my test devices, there’s no way for me to build any ML (machine learning) for detecting it. It’s unknown what exactly it looks like.

There is however already a couple of ML systems built into Arc to deal with bad location data. And these systems can be used in this case too. But they require human intervention to get the ball rolling. You have to identify at least some of the bad data yourself, marking it as either “Bogus” or “stationary”. Arc’s ML / processing engine can then learn from that information to start automatically labelling other similar data in the same way.

The rule of thumb as to whether mark bad data as “bogus” or “stationary” is 100 metres. If the data is within about 100 metres of the real location, and you were stationary at the time, then mark it as “stationary”. If the bad data is more than about 100 metres from the real location, then mark it as “bogus”.

When you mark drifting location data as “stationary” (which might have automatically been classified as car, or some such, even though you weren’t moving at the time), that lets Arc know that location data at that place sometimes drifts around instead of staying still. That then gets fed into the “Trust Factor” for location data at that place. Which means that if the phone says “here’s some location data, which is accurate to within 20 metres!”, but Arc now knows that it can’t trust the reported accuracy there, it will fudge that “20 metres” based on how much it’s learnt to trust (or rather, distrust) what it’s told at that place. So essentially Arc will say “20 metres? sure buddy. I’ll just file this one as 50 metres accuracy, because you’ve lied to be in the past”.

The other system is the “bogus location data” system. Which is what is engaged when you label bad data as bogus. Do this when the data is more than 100 metres or so from the real location.

The “bogus” location data identification system is unfortunately not as effective as the drifting/stationary system, because when data is drifting more than about 100 metres from the real location, it very often looks like real human movements. So what can end up happening is Arc won’t be able to confidently distinguish between real data and this absurdly wrong drifting data, and will sometimes classify real data as bogus. There’s no easy wins in these cases.

But yeah, those two kinds of bad data classification do help a lot, even if they can’t entirely solve the problem. (And in this case, Apple themselves really have to fix this one. It’s on them this time).

Just noticed this.I haven’t installed iOS 13.7 and haven’t encountered any rubbish data recently. Would you advise users in my position to wait for iOS 14?!

Vaughan, as luck would have it, iOS 14 arrived today! 🎉

Though I can’t say with confidence yet whether the bug is fixed in iOS 14. But I certainly hope so.

Do we know what exactly causes this bug to rear its ugly head? I had been using iOS 13.6 for some time before Arc suddenly got flooded with bogus data. I upgraded to 13.7 just a few days ago and that didn’t seem to improve things. So in my case at least, it seems like the bug is not triggered by a particular iOS version. …any idea whether iOS 14 is similarly afflicted? By the way, other tracking apps (running, Move X etc.) are working fine.

Yes, I don’t understand why it’s Arc which is affected .,, but not Move X and other tracking apps.

Just seen this too and feeling a rather guilty as I have generally been blaming the programme. Fingers crossed iOS14 and the new version of Arc can work together.

Vaughan, it’s all iOS 13 versions, since perhaps 13.1 or 13.2.

The bug appears to not exist in iOS 14, so I highly recommend upgrading to that!

The cause of the bug is unknown, but my suspicion is that it’s related to the new “Precise Location” feature in iOS 14, which allows you to choose to give individual apps non-precise location data, for privacy reasons.

My suspicion is that the feature was actually introduced into iOS 13 releases, as an experimental under-the-hood thing, not visible in your Settings. If an app gets chosen to be given non-precise location data, then in Arc’s case it’s all over - the data is completely unusable, and only serves to make a gigantic mess.

If my hunch is right, then the bug won’t happen in iOS 14, because non-precise location data is an explicit per-app option in iOS 14, so it would be possible to immediately see whether Arc has mistakenly had “Precise Location” disabled in your phone’s Settings.

Ugh, that last reply was to Michael, not Vaughan! Oops.

Vaughan, all apps that use location data are affected by the bug. Gyroscope app, for example, also has a Known Issues article on this bug.

The difference is that it doesn’t happen to all apps at the same time. It will randomly affect one app, but not others. Then the bug might go away for that app after the phone is restarted, but it may then happen to a different app the next day.

The mistake most people have been making is that they’re checking other apps, to see if they are recording well or not, and when they see that another app is doing okay, they then think the problem is in Arc itself. It isn’t. The problem is in iOS. That other app could just as easily have been the bug’s victim, and may well be the victim next time the bug hits.

Robin, so far iOS 14 is looking great! I highly recommend upgrading to it. There’s no sign of this bug in iOS 14 so far.

Very helpful! Thanks Matt

The problem I have with the suggestion of cleaning up the mess is this: Once I navigate the days/weeks affected in Arc, the app becomes so slow and unresponsive that I can basically do nothing. Sometimes it’ll freeze for several minutes until it reacts to user input, and sometimes it just crashes completely. Knowing that the reordings from such days are a lost cause, I would like to have a “delete everything within a certain timeframe” feature, but that doesn’t exist. Matt, since you say you’ve never had the problem of the bogus occur on your devices: Is there a way for me to donate my data for your testing, so that you can reproduce the freeze and crash behaviour that I’m constantly seeing?