iOS 17 / iPhone 15 battery woes

[agastya]

I am using the newest beta. I’ve cleaned segments for Home perhaps dozens of times but for example checking today, there are perhaps around 20 location dots within the circle for home. Maybe that is the bug you are referring to. From what i recall, checking older visits that I have not cleaned up might have been the same ; perhaps those were confirmed. I’m not sure.

Related though perhaps a difficult issue. For other locations frequently visited sometimes they are stores or places that might slightly overlap. If there was some way to change the circle radius to get just one specific location that might be nice. But maybe a nice UX for that would be difficult.

[matt]

@agastya

I am using the newest beta.

The newest iOS beta? iOS betas typically get worse location data, due to things like the wifi hotspot triangulation database being either purged locally or on Apple’s servers or both. It’s a not-so-obvious cost of using the betas - your location data gets more flakey, especially when inside buildings.

Though if it’s a public beta you can usually expect there to be more people using it, so the wifi hotspot triangulation data should be less anaemic. It’s the iOS developer builds that get the worst hit.

@agastya

For other locations frequently visited sometimes they are stores or places that might slightly overlap. If there was some way to change the circle radius to get just one specific location that might be nice.

Unfortunately place centre and radius have to be the result of the actual recorded data, otherwise things won’t hold together

Although those of us on this forum tend to do lots of manual editing of our data, the processing engine still does 95% of the work. If we start fiddling the calculated values too much the processing engine won’t be able to make its automatic choices properly.

It’s a bit of a troublesome balance to maintain! We depend on the processing engine being able to understand what’s going on, because it’s doing 95% of the work, and that ends up limiting what we can get away with in terms of manual overrides.

For the places that overlap, luckily location data has in general been getting better and better over the years, due to either improvements in iPhone hardware or in iOS software (even if sometimes it temporarily blips backwards due to iOS version quirks). So that means that smaller places and more closely clustered places are automatically getting recognised better than they were just a few years ago. The new phones and new software are gradually solving that problem for us - allowing automatic identification of more smaller / closer places than Arc could manage previously.

Aside: That’s actually opened up new problems for Arc, in the sense that initially Arc couldn’t identify anything inside buildings at all, like individual shops inside malls, but now with better hardware and software our indoor activities are starting to show up in the data, which means data that previously was a clear cut “inside a building” is now much more ambiguous.

In Arc’s earlier years, as soon as you stepped inside a building the reported location data accuracy would go from 5-10 metres to 60-100 metres. The processing engine then had an easy time knowing when you’d stepped inside or outside. But now the reported indoor location data accuracy can stay as high as 10-30 metres in some cases, which makes the indoor/outdoor boundary much more ambiguous. We get better data, and the ability to identify more indoor places/visits, but at the cost of clarity and certainty. It’s something I’m still trying to juggle and get the best results from!

[agastya]

Perhaps for public places it matters less. I’ve tended to notice merely one place location dot with a large radius and sometimes multiple visits with walking in between. Maybe that’s fine.

[ray]

Same problem of battery on iPhone 15 pro Max and 17.1. Had this issue since I changed my phone last October. Arc is always the 3rd most consuming after Mail and Safari. Before, I barely noticed its presence in the battery list.

[matt]

@ray Are you actually noticing shorter battery life each day? Because if not, I’d just ignore what you’re seeing in the Settings > Battery view.

That view is, as I always say, incredibly misleading. So unless you’re actually having genuine battery life problems, it’s best to just ignore it.

[ray]

Not necessarily every day but when I find that my battery meter is lower than expected (personal insight), I use to have a look at Settings > Battery and it always shows Arc at the second or third place. Compared to Safari which use the display, it’s quite surprising.

I wouldn’t tell that I have a “genuine” battery life problem because my phone is brand new and I haven’t had any demanding battery day yet but I would tell that Arc is consuming more battery than on my iPhone 14 Pro Max on iOS 16.

Anyway, it’s not that annoying for now… let’s see how it evolves.

Here’s my today’s battery settings screenshot (I have been on Safari about 1 hour) :

Regards

[matt]

Hmm. Try tapping on AFFICHER L’ACTIVITÉ and see what screen time it shows for Arc.

Basically almost all the energy consumption for any app comes from screen time. And Arc’s recording in the background uses almost no energy in comparison.

If the screen time is high, there’s the source of the energy drain. It doesn’t matter which app it is - if it’s in the foreground, it’s powering the screen (or rather, having the energy cost of the screen counted towards it), and it will unavoidably be higher in the list in that view. The screen is the most energy expensive part of the phone, almost always more so than the CPU or GPU.

Notably, Arc’s UI always has a map visible, and maps are very energy expensive bits of UI. They’re complex to build and update, so they cost more energy (CPU/GPU) than an app that just has a plain UI with simple text.

Though really it does just come down to the amount of screen time. The energy cost difference between map or no map is much less significant than the difference between screen or no screen.

[denleschae]

I had used Arc years ago and last weekend decided to try it again to replace Life Cycle. At the same time I also loaded up Rond and Marauder to see which one I liked best. Arc is a huge battery hog compared to the other three. Over the last few days Arc has been in the top 2 of my battery usage. Life Cycle, Rond, and Marauder barely register. Here are some screenshots from my commute this morning where I didn’t open up any of these apps on screen. I have an iPhone 14 Pro and am running iOS 17.1.2.

edit: I have noticed decreased battery life throughout my day. Typically I’d get past 9pm and be at 20-30% left. The last few days I hit below 30% at 1pm.

[matt]

Hi @denleschae!

First thing to clarify is that those screenshots aren’t telling you what you’re thinking they’re telling you. The Settings → Battery view includes energy used while plugged in to power, and because Arc runs everything on device, with no server side component, there are significant background tasks for housekeeping that run when plugged in to power. Those throw off the Settings → Battery view results significantly on most days.

Also when the Settings → Battery view says things like “Background location” that doesn’t actually mean that’s what used the most energy, it’s just saying that because the app did do that thing. In practice those secondary sentences don’t equate to what actually caused the majority of the energy drain. It’s useful information sometimes, but more often than not it’s misleading, because it implies something that usually isn’t the case.

@denleschae

edit: I have noticed decreased battery life throughout my day. Typically I’d get past 9pm and be at 20-30% left. The last few days I hit below 30% at 1pm.

This it the actual test you want to pay attention to! The Settings → Battery view will mislead you more often than not, and can’t tell you what’s really going on, but if you’re having the phone run out of charge earlier in the day and requiring earlier charging, then that’s real world data that indicates a problem.

Although keep in mind that it could also merely indicate that you used more screen time than you usually would. Screen time is what eats battery, with almost everything else being insignificant in comparison.

As I’ve shown further up in the thread, Arc’s timeline recording can run continuously for 24-48 hours on a single charge, even on older model phones with dying batteries. It’s not the recording that eats battery - that is extremely efficient (and sometimes even more efficient than other apps that record significantly less detail and data).

The overwhelming majority of Arc’s energy consumption comes from screen time, updating the UI and the map, and paying the cost of powering the screen (which is attributed to whichever app is in the foreground at the time).

So the thing to look for is how much time Arc was “on screen” (shown when you tap the “SHOW ACTIVITY” button in the Settings → Battery view).

Because Arc’s UI is more complex than most other apps of this kind, and it shuffles around much more data than all other apps of this kind, that screen time is more expensive than most. (Aside: That is something I’m working to improve in upcoming releases, with modernisation of the UI code, and UI energy efficiency improvements where I can find them).

Anyway, what I would suggest is to:

1. Pay attention to the amount of screen time Arc is accumulating versus other apps
2. Give it at least 10 days, and have a look at the “Last 10 Days” view of Settings → Battery, again paying attention to relative screen time

Although that 10 day view will still mislead you, due to it including the energy consumed when the app is doing its daily scheduled housekeeping tasks while plugged in to power. But it can still give you a better sense of what’s going on, to a degree.

For example the 10 day view on my main phone shows:

App	Energy	Screen time
Arc App	11%	19h 13m
Threads	8%	8h 22m

So from that I can see that even though Arc used 3% more energy relative to Threads app over 10 days, it had more than twice as much screen time, so that’s actually a big win in terms of efficiency. Like, if they were both using the same amount of energy per minute of screen time, then Arc should’ve used twice as much energy, ie 16%.

Oh, and last point: Don’t forget that the percent shown in Settings → Battery isn’t the amount of energy it used of a single battery charge, it’s the amount of energy used relative to other apps during that time period. So if for example only 10% of a single battery charge was used, and only two identical apps were installed on the phone, each having exactly the same amount of time on screen, then each app would show as 50%, even though in reality what it means is each app used only 5% of a battery charge.

So it’s important to remember that the absolute values of those percentages don’t really tell you anything - it’s the relative values that matter. The comparison you want to make is one app’s percent versus the next app’s percent, and not to compare either of them to 100%, because the Settings → Battery view doesn’t tell you what 100% actually is in terms of a full battery charge.

[matt]

Oh I just noticed your screenshots are for a single hour. Ok, yep, you need to then take into account the above caveats but even more extremely!

That single hour of phone use might for example have contributed only 1% to the drain of the full battery charge. So what you’re seeing is 41% of 1%, meaning 0.41% of the full battery charge. So basically nothing at all.

When Arc is recording in the background, that’s not the time to bother paying attention to its energy use. That’s when it’s running at peak efficiency, using almost no energy at all. It can keep doing that for 24-48 hours on a single charge.

The time where you want to see how much energy Arc used is when it was on screen, when you were browsing and interacting with the data and map. That is where Arc will chew through battery. One minute of screen time could easily use more energy than one hour of recording in the background.

[denleschae]

I’m pretty clear on how to read the battery usage app. I worked at the fruit store for 8.5 years teaching and troubleshooting everything. I know the details of background and screen usage can differ and that the percentages are percentages of percentages. It can also include battery and charging usage so you have to really zoom in to the details to understand what’s going on which is what I’m trying to do now. The essence of it is to gather which apps are using battery over a given period of time whether that be from screen use or background updates.

Those previous two screenshots were from 2 specific hours yesterday morning during my walking then driving commutes. During these two hours screen time for Arc, Rond, Life Cycle, and Marauder are 0. There may have been screen time for other apps though. The bulk of my usage is listening to Apple Music radio stations so it would be expected that drain most of the battery during those times. It’s concerning that Arc, while not on screen, was consuming as much or more battery life than Apple Music streaming music over Carplay.

The concerning thing, as I previously mentioned, is that since using Arc I have noticed my battery draining significantly faster over the course of the day. For fairness the last two days I’ve been keeping screen time of Arc, Rond, Life Cycle, and Marauder to a minimum. Certainly the first few days Arc got a lot of screen time as I was learning it’s ins and outs. I’m not concerned about battery usage then.

Here are the battery stats from the same two hours this morning over the same commute. During these two hours I’d estimate my overall battery drained about 10 - 14%. The 7am - 8am hour Arc was running in the background for 51 minutes compared to the Apple Music background time of 3 minutes. Rond, Marauder, and Life Cycle barely make a blip in usage. During the 8am - 9am hour Arc looks good, but upon closer inspection it entirely missed one of the usual locations I stop at, a walk, and an entire drive. My guess is that the app crashed in that hour which is why it didn’t consume any battery. The other apps logged my movement and locations correctly.

[denleschae]

Here is another hour snapshot with more battery drain details. No screen usage with Arc, just 55 minutes of background activity. You can see the battery level chart went from about 70% down to about 55%. 93% of that drain was from Arc. The iPhone was at my desk and I walked to the bathroom once. For 30 minutes of the hour I was on a call on my MacBook Pro so the phone was stationary most of the time.

[matt]

@denleschae

During these two hours screen time for Arc, Rond, Life Cycle, and Marauder are 0.

Because Rond, Life Cycle, and Marauder don’t use your real time location when travelling between places.

Those apps rely on “significant location change” events, or on distance filtered location updates (ie no update provided until the device was moved X metres). Of those apps, Arc is the only one that records the actual path of your location as you travel. So they’re essentially doing nothing when you’re between places.

For a more realistic comparison you could try comparing Arc versus Quantified Self, Move X, or even Google Timeline, while travelling. Those apps all do record your real path between places, albeit at greatly reduced detail.

@denleschae

It’s concerning that Arc, while not on screen, was consuming as much or more battery life than Apple Music streaming music over Carplay.

Was the phone plugged in to power for that time? If you were using CarPlay I imagine it was? If so, Arc wouldn’t have been bothering to record at peak efficiency, given the lack of need. Although it would have been deferring non-essential tasks until recording stopped (or the app was foregrounded, thus needing some metadata updates for the UI).

@denleschae

My guess is that the app crashed in that hour which is why it didn’t consume any battery. The other apps logged my movement and locations correctly.

Did they? You haven’t listed any apps that actually record paths between places yet (Marauder appears to simply plot a “road snapped” path between places, provided by the mapping service, with no actual relation to how you actually travelled between them).

@denleschae

Arc looks good, but upon closer inspection it entirely missed one of the usual locations I stop at, a walk, and an entire drive.

For this I recommend running Arc Mini as well. When both apps are installed they will communicate, and ensure that only one of them is recording at a time, and recording to the same shared database. Then if one app is killed off by iOS the other will notice and will take over recording, avoiding data gaps.

The overall battery consumption stays the same when both apps are installed and alive, because only one is recording at a time, but you get extra protection from gaps in the timeline.

[matt]

@denleschae

Here is another hour snapshot with more battery drain details. No screen usage with Arc, just 55 minutes of background activity. You can see the battery level chart went from about 70% down to about 55%. 93% of that drain was from Arc.

This one is more concerning, because when you’re stationary inside a building Arc will be in “sleep mode”, doing essentially nothing and consuming no energy at all. If energy consumption is high during that stationary period something is running inefficiently (and abnormally).

In normal operation Arc can record easily for 48+ hours on a single charge if the phone is simply sitting in a building not going anywhere. Because Arc will be in “sleep mode” the entire time, essentially consuming no energy at all. When that is the case, the phone runs for almost as long as it can in terms of “standby” energy consumption, with the caveat that the phone won’t completely go into “standby” due to being kept slightly awake due to not all apps being suspended.

So for that case, stationary inside a building, there’s something worth investigating! I’d start by having a look at the Individual Segments view for the visit, so we can see what was actually recorded. It’s likely that there were a large number of “wake ups”, causing Arc to go back into active recording, on the false belief that the device had moved and left the building. So we’ll want to work out why that happened.

[matt]

Oh, you could also do energy use comparisons versus GPS recording apps, which are designed to capture your entire movements while recording, ie the same as Arc. Things like AllTrails, BikeMap, or … well those are the ones I use personally.

Anyway, that’s probably the most realistic comparison in terms of what you’re actually getting from the recording.

When comparing to Move X or Google Timeline you’re still not quite comparing apples to apples, given that those two still rely on updates only after the device moving some metres. But they at least do record trips between places, and I’m pretty sure Move X has their filter set much lower than Google Timeline’s, so it captures much more detail than the latter.

Really there’s three classes of apps:

1. Apps that record only place visits: eg Rond, Life Cycle, Marauder (with Marauder faking up the trips between)
2. Apps that record some level of trip detail between place visits: eg Move X, Google Timeline, Quantified Self (which I think might record the highest detail of these three)
3. Apps that record the entire detail of trips between places: Arc App, AllTrails, BikeMap

[matt]

One more note, while I’m thinking about it!

I know I’ve already belaboured this point, but screen time really is where all the energy goes, and Arc’s screen time is especially expensive, due to the amount of information that’s crammed into the UI. Having that map there all the time, and updated as you navigate through the data, is extremely energy expensive.

That’s why for example old Moves app never had its map visible in its main view - it costs too much, and old phones back then couldn’t afford that energy cost.

Arc does have a Low Power Mode UI, which is used when your phone itself is switched to Low Power Mode. That mode doesn’t include a map (or really anything at all), so is as energy efficient as possible. But I’m toying with the idea of adding a little more detail to that Low Power UI, to avoid people switching out of it into the full UI when they want to see some snippet of info, which then ends up defeating the point.

[matt]

Ok this one’s my last, I promise! I’m off to Ramblers Anonymous right after this

Here’s a demo from today of how Marauder’s trip recording isn’t actually “recording”, and is really just the map service plotting a path between the recorded visits.

Marauder, with fictional paths

Arc App, with the actual paths

Aside: The paths in Arc are looking particularly rough today because I’ve just moved to a new neighbourhood and iOS’s wifi hotspot triangulation hasn’t caught up yet. It’ll get much cleaner in a few days, as iOS learns.

Meanwhile the paths in Marauder look exceptionally clean, because they’re entirely fictional

Oh, and my old iPhone 11 Pro test device with the dying battery recorded the same route while in my bag, with battery going down only ~20% over 5 hours, due to there being zero screen time.

[denleschae]

Was the phone plugged in to power for that time? If you were using CarPlay I imagine it was?

My car has wireless CarPlay so my iPhone is always in my pocket when driving, running on battery.

This one is more concerning, because when you’re stationary inside a building Arc will be in “sleep mode”, doing essentially nothing and consuming no energy at all. If energy consumption is high during that stationary period something is running inefficiently (and abnormally).

This morning I was sitting on the couch using my iPad while my iPhone was lying flat on the table next to me for nearly the entire hour. I believe I looked at other apps for 2 minutes of that hour. Battery drained about 10%. 65% of that was from Arc and 8% from Arc Mini. Neither got screen time and for the full hour they were doing background location activities.

Over the course of this last week I’ll look back on previous battery usage hours and Arc is typically in the top 3 apps of the hour. Looking more closely it’s typically been working between 43 minutes and 1 hour of that hour doing background things, not screen time. These are hours when I’ve been indoors.

Thank you for the additional details about comparing Arc to the other apps I’ve mentioned. I’ll take that into consideration. Based on those differences I suppose it’s reasonable to infer battery drain would be expected to be greater comparatively.

You have mentioned some concerns about the information I’ve presented so it is sounding very much like there is an issue. To recap, here are the things you raised concerns about:

• The fact that I’ve noticed significant battery drain over the course of the day compared to when Arc/Arc Mini was not installed. You said this was the true test. Every day this week I’ve had to plug my iPhone in far more regularly. Every night it sits next to me charging so the day always begins at 100%.
• When driving listening to Apple Music over wireless CarPlay (on battery), battery consumption of Arc is as much or greater comparatively.
• When indoors and the phone is completely stationary (running on battery), Arc is performing background tasks and I typically see about a 10% or more overall drain and Arc is the reason for 70% or more of that.

What troubleshooting steps can I take? For one morning I tried disabling the precise location permission and that didn’t do much for battery, but certainly the mapping of my activity in Arc was extremely erratic so precise location should be on. All other access permissions for Arc/Arc Mini are on and set to the most allowing. I also tried restarting my iPhone, force quitting Arc, adding Arc Mini (which only increased battery drain). Is there anything else that can be done or is Arc just a battery hog?

[matt]

@denleschae

Neither got screen time and for the full hour they were doing background location activities.

One caveat there: When iOS says “Background Location” it doesn’t necessarily mean that the app was using location services throughout, nor that the bulk of its energy consumption came from location use. When Arc (or Arc Mini) is in “sleep mode” while stationary, it does a brief sub-second wakeup every 12 to 60 seconds, to get current location and check if the phone has moved. (The other dormant app, in “standby mode”, will do a check every 2 minutes, but to check whether the other app is still alive, rather than whether the location has changed).

So as long as there’s no spurious location data causing the app to go into active recording, it should be using location only a tiny fraction of the time (eg some milliseconds every minute).

Aside: That “12 to 60 seconds” sleep cycle duration is determined based on the Place model for the place you’re currently at - if the model predicts a leaving time soon, then the sleep cycle duration will be the shortest, and if it predicts a very low chance of leaving it’ll be the longest. So for example while you’re asleep overnight the sleep cycles will be 60 seconds, then when you’re about to leave home in the morning they’ll be around 12 seconds. That allows for more accurate recording immediately after leaving places, while still getting peak energy efficiency when leaving is least likely.

@denleschae

The fact that I’ve noticed significant battery drain over the course of the day compared to when Arc/Arc Mini was not installed. You said this was the true test. Every day this week I’ve had to plug my iPhone in far more regularly.

Yeah, that is the big concern. Everything with Settings → Battery I tend to ignore unless it’s extremely egregious, because it doesn’t tend to translate into real world outcomes. But if you’re getting genuinely less hours out of a battery charge each day, that’s real world impact that needs to be dug into!

@denleschae

When driving listening to Apple Music over wireless CarPlay (on battery), battery consumption of Arc is as much or greater comparatively.

For me this comes as a low secondary concern. I’d want to test against other location recording apps to see whether Arc is actually consuming more energy while actively recording trips or not. In my years of daily comparison testing the answer has been a definitive “no”, in that Arc is almost always more energy efficient than other apps doing trip recording. But for completeness, that comparison test is perhaps worth doing.

@denleschae

When indoors and the phone is completely stationary (running on battery), Arc is performing background tasks and I typically see about a 10% or more overall drain and Arc is the reason for 70% or more of that.

Yeah, that shouldn’t be happening. When stationary and on battery Arc doesn’t schedule or run any background housekeeping tasks (nor can it), and should be spending the entire time in “sleep mode”, consuming almost no energy at all. So that energy drain shouldn’t be happening. Something’s going on there.

@denleschae

For one morning I tried disabling the precise location permission and that didn’t do much for battery, but certainly the mapping of my activity in Arc was extremely erratic so precise location should be on.

Yeah, turning off precise location will almost certainly make energy consumption worse, or at the very least make the data in Arc useless. Sleep mode requires reliable location data, to determine a definite stationary state, so without precise location it’ll likely never be able to go to sleep.

@denleschae

What troubleshooting steps can I take?

A screenshot or two of the “Individual Segments” views of some of the troublesome visits will tell us a lot. We need to see the segments that were actually recorded while this excess energy consumption was happening. That will tell us if there’s a lot of wasteful wakeups happening, due to misleading location data.

@denleschae

Is there anything else that can be done or is Arc just a battery hog?

When everything is running normally, it’s definitely not an energy hog! As I’ve said, sustained active recording can continue for 24+ hours on a single charge (and with a typical mixture of travelling time and stationary time it can even go 48+ hours, depending on device model). The recording itself, when everything is working normally, is as energy efficient as possible and doesn’t impact daily battery life.

As another recent example: My geriatric iPhone 11 Pro test device recorded over 24 hours of travel (airplanes, trains, taxis, buses, walking) a couple of days ago, all on a single battery charge. I think it had about 20% battery left when I checked it after arriving at the final destination.

I also experience the same on my main phone (iPhone 13 Pro), in the rare times when I’m not constantly opening apps.

Anyway, yeah, that “Individual Segments” view will tell us what’s going on. From there we can figure out where the energy is going.

[matt]

Here’s an example of what normal recording should look like. An hour of walking around Ginza in Tokyo, recorded by my geriatric iPhone 11 Pro.

There was no stationary time so no “sleep mode”, because I didn’t stop for much longer than two minutes at any point (was on the hunt for a decent Starbucks).

Battery drain for the hour looks to be maybe 1-2%, and the only apps running Arc and Arc Mini. Well, Photos was doing something apparently, but whatever.

This gives a really clean test of what those two apps alone should cost in energy consumption, when doing sustained timeline recording in the background, with no screen time.

Aside: The energy drain in the following hour was higher, because I foregrounded Arc and did my daily test device testing, to ensure everything’s working correctly. Two minutes of screen time looks to have cost perhaps twice as much energy as one hour of recording in the background.