I mean, I’ve been at one place all the time, how exactly is the app tracking my location as displayed on the screenshot? The listed places are close by …but, all the different transportation choices are also controversial …to say the least. I understand that the GPS isn’t always accurate while in a building etc. But isn’t there a way to improve this? It’s a paid “self learning” service. Using it since many years, apparently it doesn’t have learned much…
Also the restoration from backup, when my iPhone 12 died, right after warranty has expired, …how convenient …wasn’t exactly a pleasant experience. I believe it’s still pretty messed up, and I still can’t access the older dates/entries, the app crashes, the overview is piled up… and the mess goes on… even though I was following the restore steps to the letter. I don’t have the time nor resources to retry over and over again…
Furthermore, the app is slow, keeps freezing, unable even to edit a note, froze every 5 sec, and is extremely draining battery. I lost 8% within 13 minutes. SSs attached
It has created again multiple brief stops within moments.
I have no idea what it is doing, once I force close it, or open the app just once in a while, I am able to do stuff, correct the silly tracking etc. While using it for a while, it keeps freezing and becomes inoperative. Apparently only stopping it from recording helps here.
I have to admit, it seems this has began since the restore, as if it still wouldn’t be completely processed…?! … which was like back in July ‘23…
For a monthly paid service, this is unacceptable.
Could (any)one of the SDEs go through my data and clean it up?
GPS isn’t just not always accurate, it is almost never accurate. When stationary, location data constantly drifts over tens or hundreds of metres while indoors. That’s just how it is with current hardware and technology.
Here are some examples of what the raw data looks like, from LocoKit’s Github page (LocoKit is Arc’s core recording engine):
The red is what typical raw location data looks like, both while moving and while stationary. The blue line shows end resulting filtered and smoothed data while moving. The orange circles show LocoKit’s detection of a stationary period, and the centre and radius of that stationary period.
The orange lines in this one show the resulting filtered and smoothed samples that were also determined to be within a stationary period. As you can see, they’re not actually stationary - LocoKit has to interpret constantly moving data, even when you and the device are stationary for extended periods of time.
As you can see from those screenshots, Arc (or rather LocoKit, the recording engine) is dramatically improving on the raw data. It could be smoothed even further, but at a certain point the smoothing becomes so aggressive that you lose significant details of your movements, so there’s a tradeoff to be made. Although Arc/LocoKit does constantly dynamically adjust its smoothing, to match current conditions (moving speed, current location data accuracy level, etc).
But to give you an actionable answer to your question: Yes, that mess of different activity types while you were stationary can be improved. But it requires you telling what Arc actually happened, so that it can learn from that.
On the Details view or Edit view or Individual Segments view, tap the ellipsis button to get the More menu, and select “Clean up segments”. When this is done for a Visit item, it will convert all the samples to stationary type. This then teaches the activity types model/classifier that at that location that drifting data is more likely to be of stationary type than anything else. The classifier will then on subsequent visits be much more likely to auto detect it as stationary.
The service you’re paying for is my development time The actual learning is done by the app itself, not me. And that learning only happens based on what you teach it. If nothing is confirmed or corrected, it learns nothing and never improves. In this specific case the feedback it needs is to know that at that location you’re more likely to be stationary than anything else.
The “Clean up segments” gives you a quick and easy way to teach it that. And you’ll see improved classifier results within a day. Typically after using the Clean Up button on 2-3 visits the model will have learnt well enough to know to auto classify almost all samples as stationary at that location. It doesn’t take long.
I can give detailed help working through this situation! Which part of it is of the most concern right now?
Heh. Arc App is one person. Me. I am the developer, and the support person.
I can however help you work through the problem. Let me know which parts are bothering you most, and we’ll tackle them one at a time.
Yeah I’m noticing this too. It’s got worse over perhaps the past year, so I’m doing various updates to the app to get rid of pain points that cause freezes. Newer parts of the app don’t have the freezing problem, as I rebuild those bits of UI in modern SwiftUI. But it’s an ongoing process, rebuilding each existing view as I come to it. I’m loosely aiming to rebuild one major existing view with each major Arc update, so about one a month. Hopefully within the next few months that’ll mean all the main pain points are fixed, and no more significant freezes.
This is a new problem that’s crept in I think some time since iOS 17, or possibly in late iOS 16 versions. I’m not sure of the exact cause yet, but I’m on the trail, and I think the next update should make significant improvements. I’m already seeing promising results in testing, with some of my latest experiments. The next update should be out within the next week or two.
There’s one thing you can do to reduce freezing in the meantime. Arc will do more work in the foreground when it’s plugged in to power. Which can increase the risk of processing tasks holding onto the database and making the UI wait (which then causes the UI to freeze). So if it’s freezing a lot and it’s plugged in to power, unplug it temporarily, to get done whatever it is you want, then plug it back in after.
Hopefully the rebuilds of the existing views in SwiftUI will eliminate the need for that temporary workaround, but in the meantime it can help sometimes.
I am doing that all the time Matt.
I’m obsessed with having everything accurate. I do confirm, correct accordingly, frequently, and I’ve been doing that since a long time now. Also using the “clean up segments” feature ever since introduced.
Despite all the efforts, the results are, unfortunately, as I have stated above.
It wasn’t plugged in, but was anyway unbearable. The app was unusable.
It’s everything before July 2023. It’s very hard to be specific…
How exactly? …are you perhaps able to login to my profile and have a look?
Right. Well, how many users do you have now? Perhaps to get some manpower would be useful to get/keep the code in shape and also improve and develop it further…
Thanks a lot for your feedback, also for taking the time to cover all the points.
However, until I get this back on track, I won’t be able to use the app … for now it’s off recording
Ye, hopefully. Looking forward to the upcoming updates.
If you have been using the Clean Up feature for visits to the place in your screenshots, and the classifier is still producing the shown results, then something is broken.
If you have Arc Mini installed, please open the more/ellipsis menu in Mini and go to “System Debug Info”. In there look for “ActivityType models pending update” and tap through to that. If all is working well, you should three or fewer rows in there.
If you see many rows in there, then the schedule model updates task isn’t getting a chance to complete each day, and there’s a backlog. Which would explain poor classifier results. If that’s the case, we should work on figuring out why that’s happening!
Although, you did say you’ve recently restored from backup. The backups don’t contain the classifier models, so those have to be rebuilt after restore, and that can take some time to catch up. If that’s the case, it’ll be worth giving it a few more days to at least catch up on updating the models for your home neighbourhood, then see what the state of things is once that’s done.
Arc doesn’t store any data remotely, for privacy reasons. All of your data exists only on your phone and in your optional iCloud Drive backups.
To assist, we’d need to look at specific cases where you’re seeing problems, either with screenshots or descriptions, and I can walk you through how to deal with them.
Arc is one of the most successful apps on the App Store, in the sense that it is likely within the top 5% earners. But that doesn’t mean it’s earning enough to pay for more full time staff. Almost all apps on the App Store fail to break even, so being in the top bunch merely means that it’s earning enough to pay its bills (including my salary).
Tangent: Something I think most people don’t realise is that app development is not a lucrative business. Almost all apps fail, and almost all of the revenue that goes through the App Store goes to a small selection of the top 1% earners. It’s a mess. Although the move to subscription models has been gradually improving the market.
Anyway, back on topic: Do let me know what the current pain points are, and I’ll be happy to walk you through dealing with them until it’s all back under control and working well!
Arc Mini is/was an open source side project I worked on, building a minimal Arc App clone in SwiftUI, as a way to learn SwiftUI when it first came out in 2019.
Then I realised it could also double as a fallback recording engine, given that it could share Arc App’s database / app container. So that’s ended up being its main purpose now. Leave both of them running, and they negotiate between them which one should stay in standby (using effectively no energy) while the other one records. Then if the active recorder gets killed, the other one will notice and will take over the active recorder role, avoiding data gaps in your timeline.
So with both of them running you don’t get any extra energy drain (although it sometimes looks like it in iOS Settings → Battery, but that’s a whole other rant), but you do get effective data gap prevention.
Plus it also gave me a place to put Arc’s debug views for public consumption, rather than exposing them in the main app and potentially confusing casual users.
Hm. Then you definitely shouldn’t seeing the kind of mess you’re seeing in your home visits, especially if you’re using the Clean Up button on those home visits occasionally. Something fishy going on there. Definitely worth having a look at the System Debug Info view in Arc Mini and checking to see if there’s a backlog of ActivityType models pending update.
I think that check on model updates backlog is a good place to start. If those models are way behind in being updated then it could easily create a mess all over the place.
Massive tangent, but I’d been wondering how accurate my “top 1%” claim was for App Store revenue, so went hunting. This article from 2016 makes it sound even worse than I remembered:
Basically something like 95% of developers aren’t even earning back their Apple Developer membership fee each year, let alone running a sustainable business. I doubt that part of the statistics has improved at all since 2016.
The App Store has been an incredible success for Apple, but for developers it effectively destroyed the software market, largely due to the massive emphasis on free apps and $1 apps in the early years.
When I started out programming in the 1980s, software products were priced around $100 (sold in boxes on shelves). Then time travel to the 2010s and I was getting furious 1 star reviews for charging $1 for my first app on Apple’s App Store. Quite a thing!
Anyway, with subscription models now, and Lifetime Purchase options that can sometimes be set at actual sustainable prices, the situation is improving. But it’s still got a long way to go before it could be considered a healthy market again. For most developers, the App Store is still where dreams go to die. Grim stuff!
…wasn’t exactly a pleasant experience. I believe it’s still pretty messed up, and I still can’t access the older dates/entries, the app crashes, the overview is piled up… and the mess goes on… even though I was following the restore steps to the letter. I don’t have the time nor resources to retry over and over again…
The actual learning is done by the app itself, not me. And that learning only happens based on what you teach it. If nothing is confirmed or corrected, it learns nothing and never improves. In this specific case the feedback it needs is to know that at that location you’re more likely to be stationary than anything else.
… for now it’s off recording
