Apple Operating Systems Jump to 26?

Article Comments
22

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.)

2 Likes
23

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.

1 Like
24

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.

25

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.

3 Likes
26

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.

27

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!

1 Like
28

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

29

Didn’t Apple learn anything from Y2K?

Nobody thinks about the long term anymore :frowning_face:

1 Like
30

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

1 Like
31

Could not agree more, Michael.

32

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.

33

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

34

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.

2 Likes
35

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.

1 Like
36

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

37

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.

38

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

1 Like
39

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

40

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!

41

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.