Low Power Mode Is the Wrong Knob

Low Power Mode is the wrong knob. Not one knob too many. The wrong one.

I don’t want my phone in Low Power Mode. I want it alive at 23:00, because that’s when I get home and it goes on a charger. No phone I’ve owned offered me a way to say that. What they offer is a switch that makes everything slightly worse for an amount of time nobody will quantify.

Solving backwards

Low Power Mode hands you a binary switch and expects you to work out, in your head, whether flipping it buys enough runtime to reach a deadline you were never invited to state. That calculation needs your discharge rate, your screen-on time, how hard the modem is fighting for one bar of 5G, how much of the next four hours is video, and how many minutes the throttling actually buys.

The phone has every one of those numbers. You have none of them.

You do hold the one thing it can’t measure: what you’re about to do. It has no idea you’re about to film forty minutes of a birthday party, or that you’re getting on a plane, or that you’re handing it to a five-year-old.

So neither of you can answer alone. The phone knows the state, you know the intent, and the interface between you is a switch.

The prompt then arrives at 20%, when the decision matters most and your options are thinnest. A control loop with the human wired in as the slowest, least informed component.

They already know how to do this

The machinery exists. It shipped years ago, pointed somewhere else.

Since iOS 13, Optimized Battery Charging learns your daily charging routine, holds at 80% overnight, and finishes the last 20% just before you typically unplug. That is deadline planning: predict a future event, work backwards, schedule energy against it. Apple built the prediction, the plan, and the solver, then aimed all of it at the battery’s chemistry instead of at your day.

The deadline is already in the OS too. If you use Sleep Focus, you have literally typed in what time you intend to go to bed. Your phone knows when you wake up, knows when you plan to sleep, and connects neither to how it spends the battery in between.

Both platforms stopped at the same place. iOS 26’s Adaptive Power and Android’s Routine Battery Saver both predict your usage and start saving early. Two vendors, independently, each built the forecast and each declined to let you state the target or see the plan.

There’s an objective function in there now. You just can’t set it, can’t read it, and never get told when it won’t be met.

None of this is new. In 2004, Flinn and Satyanarayanan published Managing battery lifetime with energy-aware adaptation: tell the OS how long the battery needs to last, and it degrades application fidelity to hit your number. They never claimed to predict the future. They ran a loop. Measure, degrade a little, measure again, re-plan.

You don’t need a good forecast if you’re allowed to correct every minute.

The destination is a time

Aircraft have low-fuel warnings. They also have something your phone doesn’t: a plan you satisfy before you leave the ground. Under IFR, that’s fuel to reach the destination, then the alternate, then 45 more minutes at cruise. If the numbers don’t close, you don’t leave.

The warning light is a backstop. The plan is the product.

Tesla’s consumer version is the trip planner. Enter a destination and the car tells you which chargers you’ll stop at, how long each takes, and what the battery will read on arrival. You set the arrival percentage you want.

The caveat is sharper than it looks. A Tesla with no destination shows a range number that isn’t a bad prediction, it’s not a prediction at all: state of charge times a constant. But notice what it gets along with the destination. It gets the road. Distance, elevation, weather, charger ratings.

A phone handed “23:00” has the deadline and no route.

Nobody wants to make a promise

The route, for a phone, is what you’re willing to give up.

“Alive at 23:00” is half a contract. It says what I want and nothing about what I’ll pay. The payment is the whole thing, because the wrong sacrifice is worse than a dead phone. Dropping 5G to LTE costs me nothing. Capping the camera costs me everything if I’m at a birthday. Some evenings I’d take full performance and a dead phone at 22:00, because I’m going to bed anyway.

So the contract has two halves: the outcome, and the compromises you’ll accept, in order. Then the trades become visible and priced. LTE instead of 5G, 25 minutes. 60Hz instead of 120, 40 minutes. No background uploads, 15.

Low Power Mode does all of them at once, invisibly, and tells you nothing about what any of them bought.

We know what happens when the second half is missing. In 2017 Apple started throttling peak performance on iPhones with aged batteries to stop unexpected shutdowns. The engineering trade was defensible. Doing it silently was not, and it cost them class actions and a €25 million fine in France for not telling users. The remedy was a battery health screen and a toggle.

The failure wasn’t making the trade. It was making it without stating the objective or getting consent on the order.

Fair objection: I’ve replaced one switch with a deadline plus a ranked list, which is more configuration, not less. But the fix is the one Apple already demonstrated with Optimized Battery Charging, which never once asked me what time I get up. Learn the defaults. Infer bedtime from the alarm, the charging routine, the calendar. Notice I’ve never cared about 120Hz. Show me the contract only when it’s about to break, and keep the manual switch underneath, the way Kubernetes kept a replica count under the autoscaler.

Then it optimizes, or it tells you it can’t

With both halves, the system does one of two things.

It optimizes quietly and you stop thinking about your battery.

Or it tells you it can’t, which is a feature and not a failure mode. The alert stops being about how full the battery is and becomes about whether the plan still closes. It can fire at 80% on a weekday morning if you’re filming video and the margin just went negative. That I can act on. “20% remaining” at six in the evening, I can’t.

The loop never has to predict your evening correctly. It only has to notice, every minute, whether it’s still on track, and spend one cheap rung when it isn’t. Forecast versus controller, which is why the 2004 work didn’t need to solve prediction.

A warning you learn to ignore is worse than none, so the alert has to carry the fix rather than the bad news. Twelve minutes on a charger at lunch closes the gap. A prompt that cheap can afford to be wrong sometimes.

Nobody has shipped this, and it isn’t ignorance. Apple used to show a “time remaining” estimate on macOS and deleted it in 2016, explaining that the percentage was accurate but the time estimate couldn’t keep up with how dynamically people use a machine. Faced with a number it couldn’t stand behind, Apple removed the number. Not a confidence interval. Not a target you set with a warning when it slipped. Silence.

An estimate with error bars that widen honestly beats silence. We’ve known this in operations for a decade. You don’t promise 100%, you publish a target, and you say so out loud when you’re burning it.

The same wrong knob, everywhere

I hit this at work constantly. (Disclosure, since it’s about to be obvious: I run Mergify, which sells this kind of system. Discount me accordingly.)

Mergify users want to configure their merge queue’s batch size. Batch size is a mechanism. What they care about is that main never breaks, that a pull request lands inside some tolerable window, and that CI spend stays under a number. Those three pull against each other, so the useful thing to tell me isn’t a batch size. It’s which one gives first when they collide.

Same shape all over our tooling: replica counts, thread pool sizes, cache TTLs, timeouts, retry budgets. Infrastructure worked this out for its own operators and called the targets SLOs. Then we hand our users a settings screen full of levers.

Vendors prefer it that way, and it isn’t laziness. A toggle can never be wrong. Flip Low Power Mode, watch your phone die anyway, and that one’s on you. The moment a device accepts “alive at 23:00”, it has accepted accountability for 23:00.

Objectives create liability. Mechanisms launder it back to the user.

Which is why I’m the wrong person to find this hard. I’ll take the liability, because the solver is what I sell. Apple sells the phone. When the optimizer is the product you’re paying for, the vendor has every reason to accept your objective. When it’s a feature buried in a device already in your pocket, the safest thing they can ship is a switch and your own bad judgment.

Worth making anyway. I’d rather use a system that occasionally admits it can’t than one that has quietly arranged never to be blamed.

A toggle can’t fail you. That’s the whole appeal, and the whole problem.