[Suggestion] Let `anyAppleOS` support OS releases earlier than 26

Platform
1

I strongly suggest extending anyAppleOS parameters to handle 25.x, 24.x, 23.x, 22.x to automatically mapping OS releases earlier than 26 for different platforms. The earliest border is the year when Swift 1 releases. This reduces troubles for those devs who need to customize their own toolchains to back-support obsolete OS releases covering macOS 10.9 Mavericks and later.

E.g. anyAppleOS 25 maps to macOS 15 and iOS 18.

1 Like
2

Unfortunately said versions only really align for major releases and a subset of minor releases. What would anyAppleOS 24.7 mean? There was an iOS 17.7, but no watchOS 17.7.

1 Like
3

In your provided example then let the compiler automatically assume that it is the latest watchOS 17 minor release.

4

Actually, this is close to how dyld already works with SDK-set checks and availability.

Judging from various publicly available documents, open-source code, and implementation details that have surfaced over the years, Apple seems to have had similar cross-platform availability abstractions internally for quite a long time. So I don’t think the limitation is primarily technical.

For example:

sdk 0x07E8_0000 (2024.00.00)
  -> macOS 15.0, iOS 18.0, watchOS 11.0, ...
  -> anyAppleOS 24

sdk 0x07E4_0601 (2020.06.01)
  -> macOS 10.15.4, iOS 13.6, watchOS 6.2,
     tvOS 13.4, bridgeOS 4.1, DriverKit 19.0
  -> hypothetically anyAppleOS 19.x
     (the SDK-set encoding is 20, but these are still 2019-era OS releases)

sdk 0x07E3_0902 (2019.09.02)
  -> macOS 10.15, iOS 13.1, watchOS 6.0,
     tvOS 13.0, bridgeOS 4.0, DriverKit 19.0
  -> hypothetically anyAppleOS 19.x
     (though calling this 19.1 also does not feel quite right)

sdk 0x07E3_0901 (2019.09.01)
  -> macOS 10.15, iOS 13.0, watchOS 6.0,
     tvOS 13.0, bridgeOS 4.0, DriverKit 19.0
  -> hypothetically anyAppleOS 19.0

image
image3680×2382 1.69 MB

You can learn more information about dyld and AvailabilityVersions here

This is the kind of mapping I was referring to: a single SDK-set version can correspond to concrete release versions across Apple platforms.

My guess is that this is more of an API design decision. The current design keeps anyAppleOS focused on the new unified versioning model introduced with OS 26+, while extending it to historical releases would introduce additional edge cases around minor-version alignment and platform-specific release schedules. For example, not every platform ships the same set of x.y releases, so a single historical anyAppleOS minor version may not have an obvious or stable meaning.

That may simply not fit the direction the (Apple) Swift team wants for this feature IMO.

1 Like
5

You don't even have to dig as far as weird dyld headers.

The Darwin kernel version number has been consistent across all Apple OSes for at least a decade, and has roughly corresponded to the year in which the OS was first released. For example, Darwin 25 was the version released on the OSes in Fall 2025. What's funny about that is that Apple decided to use 26 for the user-facing version numbers that year instead of 25.

But then, apparently Apple skipped Darwin 26 because macOS/iOS/etc. 27 now have Darwin version 27. So now all the version numbers actually do align for the first time.

I think the lesson here is that version numbers are incredibly arbitrary and organic, and trying to apply some kind of false consistency like supporting anyAppleOS with numbers older than when that numbering scheme was used is likely to cause far more confusion than any benefit it would provide.

8 Likes