Battery Health Management for Mac

Calling a macOS mid cycle update a 0.0.1 update may be technically right, and that’s the best kind of right, but if we do that we should probably also call the yearly updates minor and start complaining about the lack of major updates in almost 20 years.

This seems like a good idea, although I don’t understand why Apple keeps making significant non-bug-fix changes in 0.0.1 updates.

I really wish they had taken the opportunity (when they hit 10.10, or when they rebranded to macOS, or whenever) to remove the initial 10. The major version is clearly 15, and now unlike iOS, tvOS, etc., they lack separate digits to represent minor vs. bugfix.

While adding features in minor releases is hardly new, it is interesting that almost every Catalina update has added features. That’s unprecedented, I believe.

The macOS Catalina 10.15.1 update includes updated and additional emoji, support for AirPods Pro, HomeKit Secure Video, HomeKit-enabled routers, and new Siri privacy settings, as well as bug fixes and improvements.

The macOS Catalina 10.15.2 update improves the stability, reliability and performance of your Mac and is recommended for all users.

(Despite this description, this one had lots of minor things, such as the return of the Column Browser in the app formerly known as iTunes!)

The macOS Catalina 10.15.3 update improves the stability, reliability, and security of your Mac, and is recommended for all users.

This is the first one was truly minor.

macOS Catalina 10.15.4 introduces iCloud Drive folder sharing, Screen Time communication limits, Apple Music time-synced lyrics view, and more. The update also improves the stability, reliability, and security of your Mac.

This one wasn’t.

And it looks like 10.15.5 won’t be minor either.

So to me, it really ought to be 15.0.0 (10.15.0), 15.1.0, 15.1.1, 15.2.0, 15.3.0 (a.k.a. 10.15.4), and now the upcoming 15.4.0 (a.k.a. 10.15.5).

So I’m not sure if your criticism here refers to containing features in the third digit, which is more of a strange historical artefact of Mac OS X, or whether you’d rather they shift more features back to the annual release. On the latter point, I think this is good, really. Catalina clearly contained some architectural changes that arguably weren’t quite ready in fall, and have been slowly maturing since. I’d much rather they roll these features (some of which I assume depend in one form or another on those changes) out piecemeal, when they’re ready, than do it all with a big annual bang that’s neither necessary nor wise from an engineering perspective.

Lay out a roadmap of what’s to come at WWDC, especially in terms of which SDKs are relevant for that, but don’t necessarily ship it all in one go.

(This is also smart from a PR perspective. Shipping this feature in 10.15.0 or soon after would have drowned it in negative press over Catalina; now, most of that is over with, and people can focus on the positive.)

I would rather they not roll the features out piecemeal because it increases the likelihood of bugs being introduced. And then, at later stages of the release cycle, those bugs will probably not get fixed until the next major release. So we no longer get a final, super-stable release before the next big update.

The difference between major and minor Mac updates is that major updates receive months of public beta testing, while minor updates receive almost no beta testing. As Michael suggests, that's why you don't want to ship new features in minor updates. Of course, beta testing has not been a panacea when major updates have been forced to ship on a fixed yearly schedule, but some beta testing is better than none.

I would rather they not roll the features out piecemeal because it increases the likelihood of bugs being introduced. And then, at later stages of the release cycle, those bugs will probably not get fixed until the next major release. So we no longer get a final, super-stable release before the next big update.

OK, but we really shouldn’t accept “macOS is only stable in early summer of each year” as the pinnacle of software development anyway. If Apple can’t ship in reasonable quality, they need to reduce the amount of features altogether.

The difference between major and minor Mac updates is that major updates receive months of public beta testing, while minor updates receive almost no beta testing.

The testing cycle is shorter, but the amount of changes is smaller, too.

(And I’ve never found point release betas to be anywhere near as buggy as ‘major’ release betas. Clearly, the surface area they touch is quite small in comparison.)

This battery health feature is quite different for a laptop compared to a phone. With my phone I charge on a relatively consistent schedule: I charge it every night. The battery health feature can delay charging to 100% until just before I unplug it.

However, I plug and unplug my laptop much more randomly. Some days it's plugged in all day, some days it's on battery most of the time, some days I use it on battery for the first half of the day, some days for the second half of the day.

So unlike with my phone, I assume that when this feature is on means, it will almost never charge to 100% because it won't be able to reliably predict my charging schedule? That's a much bigger tradeoff than the same feature running on my phone.

"The testing cycle is shorter, but the amount of changes is smaller, too."

The length of the testing cycle isn't the most important part, it's the number of testers. Most Mac developers and beta testing program members — as well as many iOS developers — install the major Mac betas. Almost nobody installs the minor Mac betas. In my entire career I've never installed a minor Mac beta. Most developers just don't have time to be constantly testing betas year round. Even once every year is more of a burden than we want, but that's when we do it, at WWDC time.

OK, but we really shouldn’t accept “macOS is only stable in early summer of each year” as the pinnacle of software development anyway. If Apple can’t ship in reasonable quality, they need to reduce the amount of features altogether.

Right. They should either do that or lengthen the schedule.

>Instead of meaning that it’s charged to 100 percent of what
>the battery could take, it will now mean it’s charged to 100
>percent of what the battery should take to maximize it’s
>lifespan

Just showing this as 100% feels like a bad idea. My Lenovo has the same feature, and it shows the battery as its actual percentage, without a charging indicator, when the feature is enabled. Hovering over the indicator says "plugged in, not charging."

This tells me that the feature is currently enabled, and it tells me how much battery I can expect when I unplug it. It also reminds me to disable the feature ahead of time when I want to use my laptop on the go.

If Apple wants to show this as 100%, it should at least have some kind of indicator or reminder next to the percentage telling people if the feature is active.

(The actual feature is great, though. I've destroyed all of the batteries in all of my MacBooks by constantly having them plugged in.)

It makes intuitive sense that reducing the number of features would improve release quality, but I doubt it would work out that way in practice. You'd could put more engineers on each (new or existing) feature, but we know that's not a reliable way to improve quality. It might make it worse, especially in the short term. You could have some of them work on improving automated testing, CI, and the like, but most engineers currently doing feature work won't want to do that stuff.

There could be a marginal improvement from QA being spread less thin -- at least that shouldn't make things worse -- but the complexity of the existing system is already so great that I suspect the improvement would be very small.

There is no Button for Battery health management after updating to 10.15.5., nothing changed in Energy saver on my MacBook Pro.

@Reinard The feature requires a Mac with Thunderbolt 3 ports.

The feature requires a Mac with Thunderbolt 3 ports.

I wonder why.

A newer battery controller, probably?