iOS 17 / iPhone 15 battery woes

I’ve been an ARC user since the very beginning and have always been happy with this app.

Ever since upgrading from iPhone 14 to the 15 last week (and to iOS 17 which the 15 came with) I’ve been noticing some terrible battery life. after going into settings and looking at battery usage it turns out ARC is the culprit with its background tracking. Over 35 % in the past 24 hours and that’s when I’ve been home all day. This happens even when I’m at home doing nothing- arc will continuously chop away at my battery percentage. If I stop ARC recording then my battery life is much much much better.

I’ve never experienced this before with my older phone / iOS 16. I’m assuming Apple changed some APIs around and ARC needs an update to properly handle itself in the background.

Hi @Logicwax!

I’m 99% sure this will be due to the iPhone 15 rather than iOS 17. Basically when you have a new phone or fresh iOS install, things take a while to settle in.

Part of what happens over time is iOS “learns” the apps you use, how often you use them and when, etc, then adjusts various thresholds in the background in response to that learned knowledge. A common way we see this process happening is with Arc getting terminated frequently after a fresh iOS install - iOS hasn’t settled in to understanding how you use Arc yet.

It can also manifest as higher energy use, due to a bunch of different factors that are part of that iOS learning / settling in. One common one that you’ll also see when you move to a new neighbourhood or going travelling is the iOS install not yet having fleshed out wifi hotspot triangulation data for that area. That results in the phone using more energy trying to use GPS/GNSS, and still ending up with worse location data for the first few days.

In Arc that worsened location data while iOS is settling in can result in more frequent and longer “wake ups” while Arc is in sleep mode, consuming more energy. You might be able to see this in more noisy/messy looking segments in the “Individual Segments” view for your Home visits. All that mess = more energy used when Arc gets woken up unnecessarily and starts recording for a few minutes until it sifts through the noise and realises you definitely haven’t actually gone anywhere, and it can go back to sleep.

You can actually help Arc along, speeding up the improved energy efficiency of sleep mode in these cases, by using the new “clean up” feature for your Home visits (or any visits with messy looking individual segments). You can get to the clean up button from the ellipsis/more menu on Item Details view, Item Edit view, and the Individual Segments view.

It will tell you what it’s going to do before it does it, but basically it goes through all the recorded samples and converts them to “stationary” type if they should be. That then helps Arc to much more quickly adjust its “Trust Factor” system, for knowing how much to trust the location data in that area. That makes it much easier for Arc to either stay in sleep mode or go back to sleep quickly, if the phone is sending through not-quite-sensible location data.

Anyway, the short version is: It’ll settle down on its own, hopefully within a few days. If it’s still consuming excess energy after another week, then it’ll mean something isn’t right, and we should dig deeper. But for now, yeah, just wait it out and the phone / iOS should settle down on its own and everything should get more efficient each day.

Hey, wanted to add onto this thread – I’m having the same issue since I upgraded to iOS 17, and I have NOT gotten a new phone at the same time. I’m using an iPhone 14 Pro and am noticing similarly large battery use (sitting in one place and my battery dropping dynamically and needing to charge multiple times per day).

I have many years worth of Arc usage (and I fairly religiously look at my recent travels and resolve any inconsistent information) so It does appear to me at least to be related to iOS 17.

Hope this helps, as I love Arc but can’t be worried about my phone dying this fast on a day-to-day basis.

Hi @grayedog!

My phrasing wasn’t great there - I meant that it won’t be due to the change in iOS version, ie it’s not a problem with iOS 17, but instead a temporary problem that happens whenever you do either a fresh install of iOS or a major version update (eg 15 to 16, or 16 to 17).

When you do a major version update, often most or all of the cached learning information iOS has gathered is wiped out and started fresh - the wifi hotspot triangulation data, learned app usage patterns, etc. It’s definitely all wiped out and started fresh if you do a fresh iOS install, but much of it is also started fresh when doing a major version update.

So we can’t really conclude that any of the problems are do with iOS 17 until it’s been at least a week since the upgrade (and sometimes even a couple of weeks - though hopefully not!)

There’s also the fact that I think most Arc users are already on iOS 17. So the weight of probabilities has it that iOS 17 itself probably isn’t the problem.

If you’re still seeing excessive battery use after 1-2 weeks post upgrade (though really one week should be the worst case), then it’ll be time to start debugging deeper. But when the upgrade is relatively fresh, the upgrade itself still stands as the most likely cause of the problems, and that they will be both temporary and self resolving.

Also good to remember: The largest consumer of energy/battery by far is the phone’s screen and the phone’s CPU. And whichever app you have in the foreground is the one that the Settings → Battery view counts that energy consumption towards. So if screen time is high for an app, it’s unavoidable that it will also be one of the highest consumers of energy in the Settings → Battery view. (Tap the app name rows to get the view to show you screen time vs background time for each app).

If the app has high percentage of battery use but also high screen time, then that’s normal. If however the app has low screen time (eg less than 10 minutes) but also high percentage of battery use, that’s something to keep an eye on.

So for example on my main phone Arc is 5th in the list (on the “last 24 hours” view) with 11%, and has 32 minutes of screen time. So that’s actually really good.

The app at the top of the list is Strong - my gym workouts app - with 18% and only 13 minutes of screen time. So that’s pretty bad. But in Strong’s defence, it’s an app that you don’t use repeatedly throughout the day, so it’s not a big concern.

I also experienced that after upgrading an iPhone 14 Pro to iOS 17 and after getting an iPhone 15 Pro, but I can also confirm that this goes away after a few days! Currently, Arc’s battery usage stays at 8% for me with 45 minutes of screen time, which is absolutely within norm and, actually, about the same amount as Slack uses with 1h of screen time.

Basically, you only need to start worrying about this if this behavior continues for more than a week with no improvement, IMO

1 Like

Another upgrade battery anecdote, but for macOS Sonoma:

After upgrading my laptop to Sonoma, for the next week macOS was almost constantly doing Spotlight reindexing and various other reindexing tasks (maybe Photos app and some others). It was actually super aggressive and made life difficult, it was consuming so much battery!

Of course on macOS you can go into Activity Monitor and see the individual processes and their CPU and energy usage in real time. Can’t do the same on an iPhone. And on iPhone those system services don’t seem to show up anywhere in the Settings → Battery view. So if some post-upgrade reindexing is going on and consuming a lot of battery, we’re not going to know about it.

I’ve been attributing most of the post-upgrade extra energy use to temporary inefficiencies in Location Services and iOS’s learning of app usage patterns, but it could also be similar to on macOS, where it’s doing various aggressive reindexing tasks.

1 Like

As another as they say data point, iPhone 15 Pro about a week old, running iOS 17.1 beta 2 since release date perhaps tues or so, my last 24 hours 11% battery with about 2 hours screen time.

1 Like

@agastya 2 hours of screen time?! That’s a lot! :joy:

I would say that 11% sounds really good in that case. But unfortunately, as always, the Settings → Battery view doesn’t really mean what it intuitively feels like it does. So it might be good or bad, depending.

The catch is that the percent value can’t be compared between days, only between apps within the same day. So for example if an app shows as using 10% one day then 20% the next, it might still have used less total battery on the 20% day.

I tend to try to ignore the Settings → Battery view on my main phone, and only pay attention to it if something is genuinely going wrong, like I ran out of battery usually quickly. And even then it’s still likely to mislead. I’m really not a fan of the way they show the data there.

That got me thinking. Perhaps you’ve already considered such or it’s already implemented. Through ML or something, can or does Arc already perhaps sample at some lower interval – if without issues – when at common places or typical times such as at home or work?

Yep! Those Place Details you see, showing you common arrival and leaving times and common durations, as well as the graph showing similar for each weekday, those are the basis for Arc’s knowledge of how likely you are to leave now, soon, later, etc. And Arc uses that to adjust its sampling frequency.

So if you’re very unlikely to be leaving, for example you’re at home at 2am, the recording engine will be doing wakeup checks only maybe once a minute. Then if you’re very likely to be leaving, for example at home around 8am when you head out to work, the wakeup checks might be happening every 10 seconds. (I forget the exact upper and lower bounds, but it’s something like 8 seconds at shortest to 60 seconds at longest).

So that means that if it’s a place Arc knows well the energy use will be extra optimised. And conversely if it’s a place Arc has never seen before it won’t be as well optimised.

Nice yet just guessing. Perhaps not possible but who knows; perhaps through some future API. By lack of movement maybe check intervals could be even lower?

Using the accelerometer / gyroscope is energy expensive. So Arc doesn’t spin up those hardware systems until it knows you’re definitely going somewhere again. That means that the “wake up check” cycles have to rely on location data alone, otherwise each wakeup would cost too much energy.

I have in the past experimented with lower cost but similar system services like iOS’s device orientation notifications. Those tell you whether the phone is lying face up, face down, etc. But in practice they weren’t useful and didn’t help improve things :man_shrugging:t2:

1 Like

Got it. Perhaps such is outdated and/or you are already aware. Yet maybe you’d find this interesting.

SensingKit: Evaluating the Sensor Power Consumption in iOS devices

Interesting! I’ll give it a read.

Though I’d like to reiterate that Arc/LocoKit’s recording is already extremely optimised, and isn’t the source of any significant battery drain. When looking for places to optimise energy consumption, we need to look elsewhere.

Everyone’s instinct to go looking for energy savings in Arc’s recording engine, but that instinct is misguided. It makes intuitive sense, but it also made intuitive sense to me 6 years ago, which is why I put literal years of effort into optimising it as far as it could go. At this point further energy savings in the recording engine are going to be inconsequential, and the gains need to be found elsewhere.

As a recent example, here’s some screenshots from my iPhone 12 Pro, with a very old and unwell battery. It recorded continuously for about 10 hours of bus ride and cycling, then left overnight without being plugged in, achieving more than 24 hour of recording on a single charge, with still around 30% of battery left.

The recorded timeline with no data gaps

Charged at 7:40am then still 31% remaining at 8am the next morning

The battery health is only 78% yet it recorded for more than 24 hours

Note the misleading information in the Settings > Battery view

Oh, one more screenshot from that old iPhone 12 Pro.

I use it as my cycle touring navigation maps device, mounted on my bike, so that my main phone is free to take photos. Yesterday it recorded several hours of cycling, as well as walking around temples, while also having Google Maps in the foreground for navigation while cycling.

Here’s what the Settings > Battery view looked like in the end. Arc’s recording was barely more than the “Home & Lock Screen”, while Google Maps was 92% due. This is due to Google Maps being in the foreground, which is where almost all energy consumption goes to.

The screen uses the most energy, next to the CPU, so the foreground app will always use orders of magnitude more energy than apps in the background. And because Arc’s recording is extremely energy optimised, and it was in the background for the whole day (I didn’t check Arc until just now, the next day), Arc’s energy consumption was barely anything at all, relative to Google Maps.

Yeah I’m belabouring the point, but it’s something that keeps coming up. Arc’s recording uses hardly any energy at all, so if you’re having battery problems, pay attention to what apps you have in the foreground. It’s foreground time that chews up energy.

Thanks for taking the time for such details. I’ll give it a read in a bit. Certainly my impression was you’ve done much already yet I thought who knows maybe there’s possibly more or something obscure.

1 Like

Thanks Matt! Well, it’s been over two weeks and I can say that ARC is back down to its low levels of battery usage. About ~5% if I’m just at home.

I did notice a big change right about when I started using the new cleanup segments feature. Thanks for telling me about that as I had never known about that. I had a lot of noisy segments around my house and after cleaning them up I noticed a big drop off in power consumption.

Thanks for the speedy response and keep up the great effort on tuning the app for low power consumption!


1 Like

Yeah marking the noisy segments as stationary really helps the “Trust Factor” system, which then allows Arc’s recording engine to know when to ignore drifting data and stay asleep. I wish it was something Arc could do automatically, but it’s one of those things that an app can’t work out without the help of a human telling it what’s real and what’s not.

I forgot if I’ve asked. When cleaning up segments for Home, I’m not sure how much that helps for past or future visits.

Cleaning up the segments definitely helps! Especially for your home location, because that’s probably the one you spend the most time, thus want the cleanest data and best energy efficiency for. Or at least the one you’ll most notice messy data in.

Aside: There’s a bug/regression in recent iOS versions, where iOS is being extremely over confident (and wrong) in its location accuracy level reporting. (I might’ve mentioned it above, or in one of my other way-too-long replies). I’m probably going to report it upstream to Apple, to hopefully get some improvement on it, because it makes the first few days at each new place really messy in Arc’s data, and also means Arc has to much more heavily rely on its Trust Factor system. iOS’s reported accuracy has become extremely untrustworthy, and much more so than in the past, and that ideally should be fixed.