Over the last ten days, Arc Timeline Recorder was the app that used the most battery, using 20% of it.
I’m hoping if there’s a way to trim down the power consumption. This probably won’t stop me from using the app, but I may have to buy the Pro Max as the next phone to have the biggest battery I can get… 
(Currently I’m rocking an iPhone 14 Pro)
Hi @k4869! Sorry for the late reply. I’ve been away for a few days.
The first question is: Are you actually experiencing shorter battery life each day?
If not, if battery life is still pretty normal, then it’s best to ignore the Settings → Battery view and just not worry about battery life. That view is incredibly misleading, and also sometimes simply wrong.
I’ll go into more detail on how/why the Settings → Battery view is misleading / wrong in a bit. But first I’ll give you a bit of context on why it’s very unlikely that Arc Recorder is actually using a large amount of battery:
Arc Recorder is built to do only one thing: record. It doesn’t do any of the daily background housekeeping tasks, it doesn’t have an energy expensive UI (eg map view), or really any UI at all. It basically can’t use a lot of battery, because it doesn’t have functionality that can use lots of energy.
Timeline recording is very low energy, very low battery cost. Under normal conditions Arc Recorder (or Arc Timeline app) can record continuously for at least 24 hours on a single battery charge, and up to 48+ hours on some iPhone models. Recording isn’t the energy expensive part of the app.
The energy expensive parts of Arc Timeline app are the UI (specifically the map view), and the scheduled background housekeeping tasks that run every day, and for some of them multiple times within a day. Because Arc Recorder doesn’t have any of those energy expensive functions, it can’t use a lot of energy.
Which leads me to the problems with the Settings → Battery view: Firstly, it’s very misleading. When it says “20%” it doesn’t mean that the app used 20% of a full battery charge, it means that of all the apps that used energy during that time, that app used 20% of the consumed energy.
So for example if within a day the battery went down 50%, and an app is listed as having used 50% in that day, that actually means that app consumed only 25% of the battery charge (50% of 50%).
On days where very little battery was used because the device was mostly idle, it’s possible to get weird situations where Settings → Battery might say something like 80% but that app only consumed 8% of a full battery charge. That’s why I say that view is very misleading - the percentages don’t mean what we intuitively think they mean.
The second problem with Settings → Battery is that sometimes it’s just wrong. I don’t know why or how, but sometimes it will show values that simply can’t be possible. This is less common, but does still happen.
So basically the first test is always: “Is the battery running out faster than usual” or “Do I have to plug the phone in to charge earlier than usual”. If the answer to those is “no”, then it’s best to just ignore Settings → Battery, no matter what it says.
If however the battery is running out faster, and you’re having to charge earlier or more often, there might be something to investigate! However given that Arc Recorder really doesn’t have the ability to use lots of battery, I’d still lean heavily towards the Settings → Battery view telling lies in this case.
Yes, while I see your point about how misleading the battery view can be, I am actually experiencing shorter battery life each day. If you look at the daily charge graph above, it’s constantly over 100%, meaning I can’t last the day without charging the phone in the middle of the day.
My current battery status is at 84%, but it still shouldn’t be that severe.
Hmm, ok. Let’s dig deeper then!
The only possible high energy consuming situation I can think of in Arc Recorder is where the phone is using extra energy to determine location.
That can happen when the phone has wifi disabled, and it is struggling to get line of sight to enough GPS satellites. When indoors the phone will often rely more on wifi hotspot triangulation than GPS/GNSS, but if wifi is disabled it can’t do that, so it’ll keep trying with the GPS receivers, potentially chewing up too much energy over an extended period of time.
Note that just turning off wifi in the control centre won’t cause that situation. As I understand it, wifi hotspot triangulation is only disabled if wifi is turned off in the Settings app.
Other than that… well I guess if the phone is in a situation where it has wifi turned on, but there’s not enough wifi hotspots nearby to get a reliable fix, it’ll again fall back to trying to use GPS/GNSS for too long. This can sometimes be the case in underground train stations, for example. Though typically we’re not underground for long enough for that to impact battery life.
That’s my only guess at this stage. If that doesn’t sound likely, then… I’m going to have to do some serious thinking. Arc Recorder chewing up battery is a very strange situation!
I’m also having this issue. Even with the setting that lowers battery life in exchange for having the blue indicator the app still used ~20% of my battery in the last 24h. Google Maps, which had a totally acceptable amount of accuracy for just walking around, used 2%. I only got the app this past weekend, so I’m not sure if this is a new situation or just normal.
I ride a lot of underground subway (I live in Seoul), so that may contribute to the battery drain.
(While subway has WiFi hotspots, it’s basically a mobile 5G router, so that probably doesn’t help with pinpointing location)
Hi @dayorbyte!
For the 20%, please see my explanation above for how that 20% doesn’t actually mean 20% of a battery charge. The percentages are relative to the other apps in the list. So for example if only 2 apps were used in a day, and both of them consumed the same amount of battery, both will show as 50% in the list, even if only 5% of a full battery charge was used.
Basically: Don’t take the Settings → Battery percentages at face value.
Beyond that, if you are getting less battery life each day (eg having to plug the phone in to charge earlier than usual), then with Arc Timeline app the thing to look at is its “on screen” time.
Arc Timeline uses very little battery when recording in the background, and almost all of its battery consumption comes from the UI, when the app is in the foreground, on screen. The map view especially is a high energy consumer, although updating the rest of the UI is also expensive, due to timelines containing large amounts of data.
Hm. I guess that could explain it! Although I’d still be surprised is Arc Recorder is consistently consuming significantly more energy/battery just because of underground train trips. I imagine in Seoul you’re probably not underground for more than maybe 30 minutes max per trip? Unless you take quite a lot of underground trips per day… it would still be quite unusual / surprising to see it have that much impact.
I live part of the year in Tokyo, and haven’t noticed any significant drain from underground train trips there. Though I’ll keep a closer eye on it when I get back to Tokyo in a few months. It might be time to do some more controlled testing on underground trains again.
Yeah, in practice I’ve found that in most countries the underground wifi doesn’t help with location at all. In some cases the hotspots in stations might provide the phone some useful data for triangulation, but the wifi actually on the trains is no help at all. And when the train is travelling station to station, the brief stop at each station is typically too short for the phone to triangulate a new location fast enough (though this does vary depending on the station, I’ve found in my testing).
Arc Timeline uses very little battery when recording in the background, and almost all of its battery consumption comes from the UI, when the app is in the foreground, on screen. The map view especially is a high energy consumer, although updating the rest of the UI is
also expensive, due to timelines containing large amounts of data.
My on screen time in the last 24h was 8 minutes, so it doesn’t seem like that would be the problem.
I guess it isn’t the % that bothers me so much as the % when compared to Google Maps, which is also doing background location tracking. When Arc was using 20% Google Maps was using 7%, and today Arc is using 31% and Google Maps is using 5%.
I think Google Maps timeline view is less detailed, and I’m fine with some additional battery use for better data, I’m just not sure how I feel about the app’s current balance.
Oh, I just realized that Arc Timeline Recorder is a different app. My issue was with Arc Timeline (I thought Arc Timeline and Arc Mini were the only apps). If using Arc Timeline Recorder would help please LMK.
The two apps aren’t comparable in that way, because they’re doing different kinds of location tracking. Using the approach Google Timeline does, it would be impossible to achieve anything like Arc’s level of detail and accuracy.
Google Timeline uses what’s called “significant location updates”. Using significant location updates means that the app is suspended completely between location updates, and only receives new location data once the device has moved maybe 100 to 150 metres or more. The app is then woken up, the location data delivered, and then goes back to sleep. That allows for very low energy consumption, but makes detailed path recording impossible. It’s incredibly low detail.
Arc instead receives a constant stream of location updates (except when stationary and in “sleep mode”). That constant stream is the only way to achieve detailed recordings, but it means that the app is never suspended in the background.
Arc also can’t allow itself to be suspended even when in “sleep mode”. Arc needs to be able to start actively recording again almost immediately, once you leave the place you’re at. If the significant location updates service were used, the first 100-150 metres or so of each trip would be lost.
That would also make it impossible to detect short trips between nearby places. For example if you pop out to go to a nearby convenience store, only 100 metres away, Arc can accurately record the walk to the store, the visit to the store, and the walk back home. Google Timeline can’t record those short trips, and is also likely to completely miss the fact that you ever left home!
Basically there’s a huge rift between apps like Arc and apps like Google Timeline. If Google Timeline wanted to record more detail, even if not as much detail as Arc, it would need give up on its strategy of using the significant location updates service, and that would mean using basically the same amount of energy/battery as Arc. There’s not really any middle ground between - it’s one or the other.
Hey, a bit of update.
I think another possibility of my battery woes may be also related to the fact that the main Timeline app and Recorder app is running simultaneously.
Since they are both tracking at the same time, thus basically double the battery consumption.
The apps should never be recording at the same time. They negotiate between themselves as to who will be the “active recorder” and who will be in “standby”. Then if the active recorder disappears (eg is swiped closed or terminated by iOS), the other app that’s in standby will notice that it’s gone, and will take over the recording job.
My current suspicion is that Arc Recorder is using more energy when in “standby” due to the new LocoKit2 recording engine not yet having LocoKit1’s “dynamic desired accuracy” system.
That’s the system that adjusts what level of location data accuracy it requests from iOS, depending on what level of accuracy the phone is currently achieving. For example the recording engine will step between requesting 10 metre, 100 metre, or 1000 metre accuracy, depending on the current conditions.
For example if the current setting is 100 metres and the phone is managing to beat that request, by perhaps achieving 30 metre accuracy, the recording engine will change its request to be 10 metre accuracy, to see if even better results can be achieved.
But let’s say the recording engine is requesting 10 metre accuracy and the phone is only managing 200 metres or worse. Continuing to request 10 metre accuracy is clearly wishful thinking and the phone can’t do it at that time. So it’s better to request 100 metres instead, using less energy, and requesting something that’s closer to what the phone might be capable of achieving.
LocoKit1 (in Arc Timeline) does that automatically, but LocoKit2 (in Arc Recorder) doesn’t yet do that. I had wondered whether it was even useful to do anymore, with more modern iPhone models and newer iOS versions. But given what you’re seeing, combined with the high use of underground trains (where location data accuracy is often worse than even 500 metres or 1 kilometer), my current suspicion is that it’s still a useful feature to have. So I’ll put it in to LocoKit2 shortly (it’s on my todos for this week).
I should have updates on the App Store for both Arc Timeline and Arc Recorder within the next week or so. I’ve had some updates ready for a while now, but haven’t been able to submit them to the store due to iOS 18 beta / Xcode beta restrictions. But now that iOS 18 has shipped, I can also get those updates shipped! And I’ll try to make sure that dynamic requested accuracy feature is back in there in Arc Recorder in that first update.
Thanks for all the great work. Am wondering, the current geofence timeout is set to 30s.
Would it help to make it configurable?
I notice that I am stationary most of the time, so I wouldn’t mind if it dropped down to 1-2 minutes either.
Last I worked on iOS the OS would wake up the app after the phone goes out of static geofence. So am guessing even longer sleep intervals wouldn’t hurt (though am not sure if the wake strategy you use also helps keep alive in background)
The sleep cycle durations are actually already dynamic! They range from I think around 6 seconds to around 60 seconds.
The durations are based on the currently visit’s Place model, and the common leaving times and visit durations in that model. The more likely the model thinks you are to leave the shorter the sleep cycle duration, and the less likely to leave the longer the duration.
So if for example you’re at home and it’s right around the time you usually leave for work in the morning, the wakeup checks will be happening around every 6 seconds, in expectation that active recording mode will resume soon. This allows for capturing more detail at the start of the trip away from home, as well as more accurate capturing of the time you actually leave.
If instead you’re at home and it’s 4am and you’re definitely not going to be going anywhere, the sleep cycles will be around 60 seconds, because there’s no point in spending extra energy on capturing more detail or being hyper alert at that time.
The caveat with Arc Recorder is that Arc Recorder doesn’t yet have the Places system, so it doesn’t know the current Place nor current leaving probability. So it instead I think uses dynamic sleep cycles based on duration since arrival. I think in Arc Recorder’s case the sleep cycles range from 6 to 30 seconds, with the shortest cycles being closest to when you arrived, given that the most likely time to leave any place is shortly after you arrived.
LocoKit2 is in the process right now of getting the Places system - I’m porting it over from old LocoKit, in preparation for the launch of the new Arc Editor app. So once that arrives Arc Recorder will also get that functionality and will have dynamic sleep cycles based on Place leaving probabilities too.
Unfortunately iOS’s built in geofencing is far too slow to be useful for an app like Arc. It tends to only fire once the device has moved hundred metres. It’s good for something like Google Timeline, which aims for very low detail/accuracy, but can’t work for something like Arc.
Yep! Basically in order to achieve near immediate switching to active recording after leaving a place the app needs to be permanently alive in the background (albeit in LocoKit’s sleep mode, using almost no energy). iOS’s built in geofencing tools instead put the app into suspended state, and don’t wake it again until the delayed geofence trigger fires some hundreds of metres away.
It would make sense to assume that that suspended state has significant energy/battery savings, so might be worth attempting to use in some cases. But in practice it’s really a very insignificant energy use difference. As long as the app is doing as little as possible while in the background, its energy use can be nearly the same as if it were fully suspended.
Which is what Arc does - it does absolutely nothing during its sleep cycles, then wakes for only enough milliseconds to get potentially a single location update, then if that location indicates the device hasn’t moved it goes back into sleep mode. A typical iPhone can happily run Arc’s sleep mode for 24-48 hours on a single charge. So in practice sleep mode isn’t worth optimising further.
The big energy use / battery life gains are actually to be found in the UI. Things like the map view chew up as much battery in a minute as an hour or more of sleep mode in the background.
Maybe it might make sense for there to be a setting to pause all calculations while on battery
I know low power mode is like that but sometimes I want low power mode in the app but not on the phone for various reasons
Not sure what you mean by that? When Arc / LocoKit are in sleep mode there aren’t any calculations. There’s nothing more to be removed.
Or do you mean in the app’s UI? I have toyed with the idea of being able to switch Arc into a Low Power UI that includes the timeline view but no map. That would cut down foreground energy use significantly.
Yeah from what I understand low power mode removes the UI and limits the timeline calculations and cleaning in the background, it would just be nice to have that mode as a toggle so that I can have it always on on battery regardless of whether or not the temp is high or I’m in system wide low battery mode.
I generally don’t want any calculations while on battery so as to limit battery use.
One caveat: Arc’s Low Power Mode is only a difference in UI and nothing else.
For the limiting of background housekeeping tasks, those are only ever done when the phone is plugged in to power, so those aren’t a concern. The rest of the time Arc is always using as little energy as possible while in the background, only doing what’s absolutely necessary.
But the different UI is worth a lot in terms of energy savings. So yeah, I agree it would be great to be able to toggle it on without having to turn on iOS’s Low Power Mode.
The main reason why I haven’t done that yet is because, well, because the current Low Power UI is pretty shit. It’s basically useless. It tells you battery level, thermal state, recording state, and that’s essentially it. There’s no useful information about the actual timeline data, so there’s almost no point in ever looking at it.
With a UI that minimal there’s essentially no point in opening the app to look at it. So you achieve the same result by just not opening the app (if the app is in the background there’s no UI so no UI cost, regardless of whether it would be using Low Power UI or full UI).
If however the Low Power UI had something actually useful, like the timeline list view and item details views. And maybe some limited timeline editing features, like place correct/confirm and activity type correct/confirm, there’d actually be a point in opening the app up and looking at it and using it. Then it’d make sense to be able to actively switch to that Low Power UI even when iOS isn’t in Low Power mode.
I can see that kind of Low Power UI being useful for things like hiking, or any long trip where you’re going to be forced to run on battery with limited ability to charge the battery for some hours. You’d be able to check the timeline, see some useful item info, do edits and cleanup, all without the battery draining impact of the map.
Actually… is that on Changemap? I don’t remember seeing that in the feature requests list! But it’s long been a one I’ve wanted myself - an actually useful Low Power UI. Ooh yes, it is there!
“Travelling Mode” is a good way to phrase it too I think. Specifically designed for those times where you’re hours away from the next power plug, need to minimise battery use as much as possible, but still want access to useful information about the trip you’re currently on.
