Apple Operating Systems Jump to 26?

Seen here with a link to a Bloomberg article.

https://www.bloomberg.com/news/articles/2025-05-28/apple-to-rebrand-device-operating-systems-ios-26-macos-26-watchos-26

NEW: Apple will announce its biggest ever software rebrand at WWDC, tied to operating system redesigns. Apple is moving from version numbers to years (like Windows in the 90s). The new OSs: iOS 26, iPadOS 26, macOS 26, visionOS 26, tvOS 26, watchOS 26.

I hope that this is true - it will make things a lot easier I think.

Maybe. Maybe not.
Only Apple knows what will (not) happen.

What I’d really like to see is Apple getting away from deciding that it has to produce a “major” new release each year whether it is ready or not.

There is no need for a major release every Oct.

1. Fix bugs and add minor features with routine updates throughout the year.
2. Release major updates only once the features are ready. Ready here means once features have been implemented, tested, fixed, retested, and refixed, and then finally retested again. Not a day earlier.
3. Also, pre-announce only changes that require devs to prepare things on their side. If Apple is releasing a new Finder feature, there is no need to announce it a day earlier than it is ready (and that is ready as detailed in #2).
4. Documentation needs to be caught up. Don’t release major new features before you can supply the proper documentation. Not properly documenting crucial aspects of the OS or failing to keep that documentation up to date for years (here’s looking at you, APFS) is unacceptable.

Oh, joy.

And the website Feedback - macOS - Apple. When I submitted a report of some anomaly earlier this year, neither the hardware (MBA M3) nor the software (I forget which version of macOS 15) was available in the dropdown menus. Sheesh. (A moment ago, the MBA M3 was still not listed.)

While I agree with all four of your suggestions, I think the most critical one is #4: documentation. Inadequate documentation of new and changed features makes things harder for everyone—including Apple’s own employees. Documentation is, in general, the aspect of software development with the greatest lag time between proper updates.

Agreed completely.

The problem (at least as I’ve observed it over my career) is that there are very few good engineers who are capable of writing good documentation. And there are few good writers who can properly understand cutting-edge technology well enough to write documentation for the masses to read.

Companies are often willing to pay nice salaries to top-tier engineers, but they are generally unwilling to pay similarly for top-tier writers.

So most projects end up with poor quality documentation, and not a whole lot of it at that.

I also wouldn’t mind if Apple standardized hardware product names to include the “model year”, as automobile manufacturers do. The 2026 iPhone, the 2024 MacBook Pro, the 2025 iPad, etc. Stop the numbering, stop the inconsistent product naming.

The 10.xx sequence of Mac OS releases was when the operating system was named OS X (roman 10). This makes no sense now that OS X has changed to macOS so a move to year designations could be on the cards.

On poor product documentation … the success of Take Control books is evidence of this.

I would far rather have a good, stable, useful OS upgrade every two or three years, rather than one lacking those attributes every year. Hell, I’d even pay for such an upgrade!

The funny thing is that they do this for most (but not all) Macs. But they don’t advertise these names. Note the text in your “About this Mac” box:

Screenshot 2025-05-29 at 09.48.59392×611 57.9 KB

The MacTracker app lists these names as a part of the descriptions. For example:

• iMac (17-inch Late 2006)
• iMac (Retina 5K, 27-inch, 2020)
• Mac mini (Mid 2011)
• Mac Pro (2019)
• MacBook Air (15-inch, M2, 2023)

But you’re right that it would be nice to do this for other device types. Looking at MacTracker, I see that iOS devices (iPad, iPhone) usually are listed as a product category and a generation number, which means you need to do a bit of research to determine if the latest model is new or a few years old.

I was thinking it was the finale of " OS " … Like OS for all the devices when iOS and MacOS merge. /s

I don’t see the logic. I mean are users that confused? There was Windows 95 but no 96, 97, Windows 2022… And next will be Windows 12.

I just want better documentation, the ending of pushing it out the door and patching later. I guess that last one is just too much to ask for.

Meanwhile, iTunes/music still can’t fix the artwork not matching the original artwork.

Maybe not, but it’s going to make the job for people like Adam a lot easier. For example, you can access this new feature so long as you have the 26 or later version of your OS installed is a lot easier than anything newer than iOS/iPadOS/tvOS 18, MacOS 15, watchOS 11 or visionOS 2. Really that applies to Apple talking about minimum OS required for particular features, too.

What is the difference between IOS and iPad IOS?

And Books has trouble displaying the right book cover image — even for purchased content.

Apple split them a few years ago to make it easier to have iPad-only features like Split View. Whether they have made good use of this ability is a matter of debate.

This. The yearly “major” release cycle is not a net positive. I miss the days when Apple issued new OS versions when there was good reason to do so and the new OS was mostly ready for prime time.

There are quite a few good reasons why some of us nurse along our older hardware and software.

Not much. The two are based on the same OS kernel and share most of their system frameworks.

The differences are primarily:

• Hardware-specific device drivers and system frameworks (e.g. Pencil support, FaceID) in order to support unique hardware differences.
• UI changes to optimize the user experience for the different size/shape screens.
• Bundled apps and app availability.

Personally, I think these differences are minor enough that I think the two names are just for marketing purposes.

What @LarryR said.

Also, I was mildly chastised for using the term “iPadOS” not too long ago because the poster said it was “not a thing.”

Except that it is. And in my humble opinion it’s a good thing, because pure iOS apps on an iPad will run, but they look awful.

Aww, shucks. Many of us want to bemoan the annual OS drop, because it has sometimes been used by Apple as an excuse to drop support for stuff that we still find useful.

I get it that protocols like LocalTalk on twisted-pair station cable may be long in the past, but I wonder what useful standards have been deprecated by Apple simply because they aren’t as new and shiny as something that can be rolled out at the next WWDC? (I don’t have anything particular in mind, just the uneasy sense that every year we lose something when that version number clicks up.)

I agree with you, but some counter-points from a software developer:

• Every feature you release needs to be tested and supported, even if it isn’t popular. There’s a cost for that. At some point, it makes sense to drop support, even if the feature is working, just because it’s not worth the cost to keep it.
• Even if a feature doesn’t change, the code needs to be kept up to date as various lower-layer OS APIs change. AFP is built over TCP/IP, which shouldn’t really be changing, but it also interacts with system services like the Finder, which definitely changes over time.

In the Linux world, if the maintainer of a package decides it isn’t worth maintaining, it may be picked up and supported by others. And if a distribution no longer supports a package, it is usually possible to get it from a third-party or download/compile it yourself from sources.

Unfortunately, in the Mac (and Windows) world, this may not be possible. Especially for low-level system features like file-sharing protocols and file systems - the system security model may prevent third parties from developing these packages due to the risk of bugs/malware causing big problems.

On the other hand, when Apple got rid of kernel extensions, they provided more specialized APIs for things that used to require them, like the Virtualization framework. So maybe they can develop a framework for third-party file-sharing and file-system protocols, which would allow others to develop and sell packages to those who still require (for example) AFP and HFS support.

The issue I see with the new “numbering”, at least for the mac OS, is that Apple plans on releasing macOS 16 (or is it 26?) this fall, but it will still be 2025. If they are going to make this “number switch”, better to wait until January 2026, and then every January thereafter. Does not have to be exactly in January, but just in the firts part of each year.

No, it’s numbered 26 since it will be the active OS on January 1, 2026. This is the same as automobile model year designation or magazine issue dates.

You are assuming that the next major mac OS release will be on or after January 1 ,2026. But from what has been written, Apple will release the next version of the mac OS this fall, which is still 2025. That is not 2026.

If I were a software engineer at Apple (ha ha) I would be much more at ease if OS updates were released when they were ready - not to some artificial deadline that applied pressure to wrap up the development in, for example, a certain year.
But then I expect marketing and bean-counting will win out!

He’s not. He’s saying that on January 1, 2026, it’ll be the OS in release.

Didn’t Apple learn anything from Y2K?

Nobody thinks about the long term anymore

Honestly, I’d be happy to move to a pattern of more frequent smaller releases. In some sense Apple has started down this path by delaying some announced features to the .x releases.

I’ve done software development before, and I’m now engaged in standards development, and in both cases a schedule that involves fewer releases with more changes per release slows things down badly. You end up playing the game of “well if this change can’t get into THIS release, then we’ll be stuck waiting a few years until the next “major” release”. And testing and validating a “major” release slows feature development and integration because you’ve split release N (being tested) from release N+1, so any changes resulting from testing need to be implemented and tested in both versions.

A schedule of more releases, each with a more limited scope, is apt to improve things faster than having fewer large monolithic releases.

Dave

Could not agree more, Michael.

Still very unclear. As I mentioned, so far all signs point to the next version of the mac OS to be released in the fall of this year, which is still 2025. So, seems like that version will be designated as mac os 16.0, or is it mac os 26.0? If it’s 16.0, then supposedly any version released on or after January 1st will be designated as mac os 26.x. If instead it will be named mac os 26.0 in the fall, again that is confusing, as the year is still 2025. But if the next mac os release is not until January 1 or later, then the name mac os 26.0 makes a lot more sense.

Maybe. Nonetheless, that seems to be what they’re doing.

It may not make sense to you, but it makes sense to anyone who keeps abreast of the automobile market, where the next year’s models are released in the fall. Personally, I hardly care whether the number of the release precisely correlates with the last two years of the era in the Christian calendar.

And just to add a few maybe relevant data points…

Many open source projects use year/month for release numbers.

For example, Ubuntu Linux usually issues releases every April and October and uses versions like 23.04, 23.10, 24.04, 24.10 and 25.04. These releases are supported for 9 months (3 months after the next release). Every fourth release is designated a “long term support” release, with the version having an “LTS” suffix (e.g. 22.04 LTS, 24.04 LTS), which are supported for 5 years (and may have paid support for much longer).

Microsoft’s current Windows versioning scheme is even more interesting. The main product number (10 and now 11) each represent “major” releases. The changes when the product number gets bumped are usually those that will be incompatible with old hardware or otherwise have fundamental changes to the software architecture.

But within each major Microsoft release, they issue “version” releases, which add features but generally don’t break hardware or app compatibility. These versions use date-coded version numbers. Initially, they were year-month (1511, 1607, 1703, 1803, 1809, 1903, 1909, 2004), but today they are half-year (20H2, 21H1, 21H2, 22H2, 23H2, 24H2).

And to make things more confusing, these date-coded version numbers are reused for different products. So Windows 10 has versions 21H2 (November 16, 2021) and 22H2 (October 18, 2022), and Windows 11 also has a 21H2 (October 4, 2021) and 22H2 (September 20, 2022). And another similar set of version numbers for Windows Server (whose main release number has been date-coded since Windows 2000).

I assume there’s some relationship between these (e.g. Windows 10 and 11 being branches from a common code repository and Server being a branch from a corresponding desktop release), but they are definitely not identical.

So when Apple is announcing yet another versioning scheme (apparently year for the major version and sequential numbers for minor/patch versions), it’s really nothing new to the industry and isn’t something I expect to care about, one way or the other.

Read the thread again. That’s not what I was saying.

As long as Apple starts the new numbering designation this fall, then I (and others) can get used to it. And yes, it would be like the automobile market. However, if they name the initial release/releases that come out in the fall as mac os 16.x, but then switch to mac os 26.x starting in January, that would not be like the automobile market, and could cause confusion.

I agree completely. We’re all used to how the car industry does. Years make more sense.

Well stated. And just as long as they start the renaming when the new version of the mac OS arrives.

Actually, Apple should not have used MacOS 10.10.x through 10.15.x. After 10.9 they should have gone to 11.0, then to 12, etc. IF they had done that, the the current version 15 would be “21”. As for the code names, I always thought that 10.9 should have been “Smilodon”!

IF Apple does change to using years, I wonder if Microsoft will revert to them? Imagine MacOS 26 vs Windows 26!

When I was taking evening classes for my college degree, one I took to fulfill a writing requirement was “Technical Report Writing”. Do they even teach this today?

And David Pogue’s “The Missing Manual” series.

That has long fallen by the wayside. New models are now released throughout the year but bearing the next year date.

I think the main issue with the annual release cycle is not just the annual release itself, but that it’s an annual major release, that is, a release that can break backward compatibility and cut off older hardware. Forcing people to accept that every year can mean your Mac falls off the scales or you need to update your old FM Pro for $500 regardless of actually released feature set just makes a lot of people uncomfortable.

With some annual cycles lately having brought little new to the table if at all (with many pre-announced features not coming until half a year later with some dot update) does for a lot of folks not create the justification for breaking backward compatibility or cutting off older hardware. I personally find that an understandable concern.

Apple could get out of this conundrum by either not breaking compatibility or ending support on a quite annual basis, or by ensuring that there is so much value in the major updates that do, that people consider it a justifiable price to pay for that kind of progress. And, for the latter to work, judging by how things have been going the last half decade or so, it appears Apple needs substantially more time than just 12 months to create that kind of value proposition, IOW in effect stretching that major update cycle to perhaps 18 or 24 months. Minor improvements (not to mention security fixes) could still be issued as soon as they’ve been properly readied.

Yes, and there’s the elephant in the room.

Justified or not, designating a software release “major” and doing that major release annually could be seen as a cynical move to break older hardware releases.

I have a MBPro purchased in fall 2018. It was spec’ed above the baseline by my employer, and is still more than functional. But, it has an Intel processor and no TouchID facility. So, it fell out of the supported software cycle 2 years ago.

Many, many hardware and software improvements have been made to the MBPro line since that machine was designed. (The keyboard is the most prominent example, but it’s just a small example.) I just acquired my new working MBPro, and the M4 Pro chip is stunningly fast.

But…I still like that slim, fast MBPro from 7 years ago. And I’m still not persuaded that Apple had any reason to cast it into the “legacy” bin other than they wanted me to buy a new one.

They couldn’t really force me to unless I wanted to have a platform that runs current versions of the apps I depend on. So, hello Sequoia! And 5 months from now, goodbye Sequoia!

To be fair, I only installed Sequoia on my 2019 iMac this month, and pro apps were still being updated on Sonoma until now. That’s a break from past releases, when a MacOS major upgrade would arrive and immediately be followed by feature updates for Final Cut Pro and other apps that could only be installed on the new platform.

We seem to have this “Apple shouldn’t upgrade every year” discussion a lot, don’t we?

The reality is this:

1. Apple’s biggest hardware product and profit-driver is the iPhone
2. In order to compete with other hardware phone makers, they feel that they must release a new iPhone every year.
3. In order to get enough people to buy the iPhone when it’s released, they feel it must contain new features that didn’t exist in older models.
4. In order to support those new features, they feel it needs an update to the OS with new APIs, which they feel requires a new release of iOS.
5. Much of Apple’s strength lies in providing a platform where new features in the iPhone are matched in the Mac and the iPad, so those require new APIs that communicate with each other (and with iCloud)

So imagining an Apple that will not update their OSes every year, or not introduce new features, I think is a fantasy so long as they must compete with other mobile devices and OSes that update every year.

I do hope that an Apple chagrined by the failure of promised Apple Intelligence features for this year has learned a lesson and will not repeat anything like that anytime soon. I’d love to see underpromising and overdelivering in 2025/26.

Yes, Apple should do a much better job of fixing bugs, documenting new APIs for developers, documenting new features for users, communicating back and forth with people who report bugs, etc. But I really can’t imagine that we are ever going back to an Apple that waits to release new OSes “until they are ready and bug-free” (I put that in quotes because I don’t think that ever happened anyway.)

I think that’s true, and it is an issue bigger than Apple.

I’m by no means the first to suggest this, but the way we think of “platforms” has shifted in a dramatic way, and I don’t think it gets enough attention.

The conventional wisdom used to be that people and businesses bought platforms to run specific apps, usually third party apps. People bought Apple ][ computers to run Visicalc. People bought IBM PCs to run Lotus 123. People bought Macs to run Pagemaker. The expectation was that platforms would be steady, stable foundations for running important tools over time and in predictable ways. New platform features would be introduced from time to time, but new features that had a major impact on how a platform worked were very serious matters and were very carefully tested and planned for.

Today’s platforms, or at least their business models, are much more about selling the platform vendor’s in-house services ecosystem, e.g., Apple Music, Apple Store, Microsoft 365, Microsoft Co-Pilot, etc.

Ironically, as platforms invest less in attracting third party software vendors, there is less incentive for third party vendors to take advantage of platform-specific features, often reducing the overall user experience. (Witness the old controversies over writing apps with Electron rather than using native frameworks.)

It’s hard to miss the ensh*ttification that follows.

Harrumph.

No one is stopping you from continuing to use it.

Of course. And I do. Not the point, of course, as I’m sure you’ll agree.

It’s my point. You have the same computer you purchased. You like it and it clearly works well for you. It’s probably roughly about as secure as it was when you got it. Apple hasn’t taken any of that away from you.

Okay.

So it also looks like a first step towards a unified OS. As features harmonise it’ll be a lot easier to identify when you can simply state the year of release rather than a feature being available on a bunch of OSes with different version numbers.

Okay. Again, I understand your point, and agree with the main outline.

And, there is a nevertheless involved:

Nevertheless, while my MBPro designed in 2017 works fine, it is frozen in time. I used it on the Web, but no more security updates for it. I used it to produce video, but no more codecs or feature updates for the software.

As I have done with my 2011(!) iMac and my iPad Air 2, I will put it to other uses. But it can’t be in my main workflow anymore because the OS bars it from those security and feature updates.

That’s what Apple has taken away. And if I were not the persistent type, I’d have simply bought a new laptop 3 years ago a la Windows.

I am not complaining. Apple has done so much right over the years that I have no reason to. But the annual major OS upgrade cycle leads to situations like this.

Thanks! Then don’t tell me what I agree to or don’t agree to.

Apple has taken away nothing that you had. The computer works just as it did when you got it. You’re making the decision not to use it, even though it works just as well as it did when you got it.

Alright, no more of this back-and-forth—it’s not constructive.

The only substantive change that is in play here is the public version number of these operating systems. (I wouldn’t be surprised if the internal versions that developers query when targeting different operating systems will retain the old version numbers.)

There is nothing new about annual updates. As I pointed out in the article, iOS has received major updates every year since 2007 (18 years), and macOS has received major updates every year since 2012 (13 years).

How quickly Apple discontinues support for a particular model depends on numerous variables, but support usually lasts for at least 5 or 6 years, often longer.

https://tidbits.com/?s=real%20system%20requirements

And as has been pointed out, you can keep using older machines with older operating systems as long as you like. Particularly if you can use a Web browser that continues to receive security updates and avoid sketchy websites and apps, there isn’t much to worry about.

MacTracker is indispensable to me. I’ve been using Macs since 1985, and overall Apple has been pretty bad at naming things in a useful way. If they start naming operating systems and hardware more logically, that’s a good thing.

I can only assume the marketing argument must have evidence supporting it, but it’s not one I can embrace.

Operating systems have always been numbered (not counting the earliest days).

The oldest distributions had different version numbers for the System file and the Finder, but by the time of System 6, there was a consistent numbering scheme.

Internally, Apple, like most software companies, uses code-names for projects. This makes perfect sense because the version number used at release time isn’t necessarily known at the time development starts. And, thanks to an inquisitive press, these code-names would typically leak to the public at some point.

Where much of the confusion got started was when (starting with Mac OS X 10.2, “Jaguar”) Steve Jobs decided to start using these code-names as product names. From that point, most people, both in and out of Apple, started using these names instead of the numbers. After dozens of releases, that has become very confusing.

And, of course, the fact that Apple (and just about everybody else these days) has obliterated the meaning behind major and minor version numbers, has made it hard to know which releases are very important and which are less important.

Once upon a time, major version number changes (e.g. from 6 to 7 or 7 to 8) indicated a major architectural change to the software, usually accompanied by breaking compatibility with the oldest hardware. Microsoft still (mostly) follows this - the shift from Windows 8 to 10 and then from 10 to 11 included major changes in hardware requirements. But Apple does not. There is no way to know, from version numbers alone, which upgrades are major workflow-breaking changes (e.g. dropping PPC hardware support from 10.5 to 10.6, or drppping PPC application support from 10.6 to 10.7) vs those that are mostly just cosmetic changes or changes to bundled apps (e.g. 10.7 to 10.8).

But this is not just an Apple thing. We see lots of software projects all over the place choosing to bump “major” and “minor” version numbers based on a calendar schedule or for marketing reasons instead of reflecting the magnitude of the software changes.

For instance, the Linux kernel used to be pretty strict about major/minor/patch versions from its beginning up to version 2.6 (which ended at 2.6.39.4. But then they decided that the first number isn’t likely to change ever again (version 1 to 2 changed all kinds of system calls that broke nearly everything) so they now bump it every 20 releases (3.19 went to 4.0 for no technical reason whatsoever). Which make as little sense as anything else in the industry these days.

My favorite numbering system is for the TeX typesetting system, written by Donald Knuth. Version 3.1 was followed by Version 3.14, then Version 3.141, and so on. The most recent release is Version 3.141592653; my understanding is that when Knuth dies, the final version of TeX will be designated Version π.

Dave

Yep. As I understand it, Knuth decided that the feature-set would be forever fixed after version 3, so all subsequent releases would simply be bug fixes. So as time progresses, the quality of the software approaches (but can never actually reach) perfection. Hence the idea of limiting each digit to the corresponding digit of pi.

And, similarly, the associated Metafont font-rendering engine has a version numbering scheme that asymptotically approaches e.

Of course, these versioning constraints don’t apply to add-ons and forks of these projects, like L^AT_EX.

Here’s a thought, lets go back to system 9 and give Copland another shot .