Livsy Code

anyAppleOS in Swift 6.4

Greetings, traveler!

Availability checks in Swift are usually clear when the API belongs to one platform.

@available(iOS 26.0, *)
func useNewiOSFeature() {
    // ...
}

The code gets noisier when the same API is available across Apple’s platforms at the same OS version.

@available(macOS 26.0, iOS 26.0, watchOS 26.0, tvOS 26.0, visionOS 26.0, *)
func useNewSharedFeature() {
    // ...
}

This works, but it is not pleasant to read. It also makes small mistakes easier. A developer can forget one platform, type a slightly different version, or keep old availability lists around after the API becomes shared across Apple OSes.

Swift 6.4 adds a cleaner option for this case: anyAppleOS.

What anyAppleOS does

anyAppleOS is a new availability platform name. It lets Swift describe APIs that are available across Apple operating systems with the same major version.

The previous example can now be written like this:

@available(anyAppleOS 26.0, *)
func useNewSharedFeature() {
    // ...
}

The same syntax works in runtime availability checks:

if #available(anyAppleOS 26.0, *) {
    useNewSharedFeature()
} else {
    useFallback()
}

It also works in conditional compilation:

#if os(anyAppleOS)
import Foundation
#endif

That replaces the older pattern:

#if os(macOS) || os(iOS) || os(watchOS) || os(tvOS) || os(visionOS)
import Foundation
#endif

The feature does not change how availability works in Swift. It removes repetition when the availability boundary is the same across Apple OSes.

Why it starts at 26.0

anyAppleOS is tied to Apple’s aligned OS versioning.

Starting with the 2025 Apple platform releases, Apple OS versions use the same major version number. That means iOS 26, macOS 26, watchOS 26, tvOS 26, and visionOS 26 can share the same availability spelling.

That is why this works:

@available(anyAppleOS 26.0, *)
func newAPI() {
    // ...
}

But this does not:

@available(anyAppleOS 25.0, *)
func invalidAPI() {
    // ...
}

anyAppleOS is not a shorthand for older mixed platform versions such as iOS 18, macOS 15, watchOS 11, tvOS 18, and visionOS 2.

For older platform releases, use the explicit platform list:

@available(macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0, *)
func olderSharedAPI() {
    // ...
}

@available and #available

@available annotates a declaration. It tells the compiler where that declaration can be used.

@available(anyAppleOS 26.0, *)
struct SharedRenderer {
    // ...
}

#available checks availability at runtime.

if #available(anyAppleOS 26.0, *) {
    let renderer = SharedRenderer()
    renderer.render()
} else {
    renderWithFallback()
}

These two forms answer different questions.

@available says, “this declaration requires Apple OS 26 or newer.”

#available says, “this code path can run only when the current OS is Apple OS 26 or newer.”

For iOS apps, the runtime check is still required when the deployment target is lower than the API you want to use.

#if os(anyAppleOS)

#if os(anyAppleOS) is different from #available.

It is evaluated at compile time. It checks whether the current target is one of Apple’s operating systems.

#if os(anyAppleOS)
func platformName() -> String {
    "Apple platform"
}
#endif

This does not check the OS version. It only checks the target platform family.

Use #if os(anyAppleOS) when a block of code should be compiled only for Apple OS targets.

Use #available(anyAppleOS 26.0, *) when a block of code should run only on Apple OS 26 or newer.

Mixing anyAppleOS with specific platforms

anyAppleOS does not remove the need for platform specific availability. Some APIs are available on most Apple platforms but have exceptions.

For example, an API may be available on Apple OS 26, except watchOS and tvOS:

@available(anyAppleOS 26.0, *)
@available(watchOS, unavailable)
@available(tvOS, unavailable)
func makeAdvancedRenderer() {
    // ...
}

Or an API may arrive on most Apple platforms in 26.0, but later on one platform:

@available(anyAppleOS 26.0, watchOS 26.4, *)
func makeAdvancedRenderer() {
    // ...
}

Swift uses the most specific availability rule for the current compilation target.

That makes anyAppleOS useful without making it too broad. It can describe the common case, while platform specific rules handle the exceptions.

A practical iOS example

Imagine a shared module used by an iOS app, a macOS companion app, and a visionOS experience.

Before Swift 6.4, a shared feature might look like this:

@available(macOS 26.0, iOS 26.0, watchOS 26.0, tvOS 26.0, visionOS 26.0, *)
public struct TimelineSnapshot {
    public let title: String
    public let date: Date
}

With Swift 6.4:

@available(anyAppleOS 26.0, *)
public struct TimelineSnapshot {
    public let title: String
    public let date: Date
}

The second version is easier to scan. More importantly, the intent is clearer: this type belongs to the shared Apple OS 26 availability boundary.

The same applies to functions:

@available(anyAppleOS 26.0, *)
public func makeTimelineSnapshot() async throws -> TimelineSnapshot {
    // ...
}

And runtime use:

func loadTimeline() async {
    if #available(anyAppleOS 26.0, *) {
        let snapshot = try? await makeTimelineSnapshot()
        // Use the new implementation
    } else {
        // Use the fallback implementation
    }
}

When not to use it

anyAppleOS is useful only when the API really has the same Apple OS availability.

Do not use it for iOS only APIs:

@available(iOS 26.0, *)
func configureiOSOnlyFeature() {
    // ...
}

Do not use it when versions differ across platforms:

@available(iOS 26.0, macOS 26.1, visionOS 26.0, *)
func configurePlatformSpecificFeature() {
    // ...
}

Do not use it instead of canImport when the code depends on a framework rather than an operating system.

#if canImport(UIKit)
import UIKit
#endif

os(anyAppleOS) checks the platform family. canImport(UIKit) checks whether a module is available. Those are not the same thing.

Compiler diagnostics

Swift also includes a diagnostic that can suggest anyAppleOS when an availability list can be simplified.

For example, this declaration can trigger a warning:

@available(macOS 26, iOS 26, tvOS 26, watchOS 26, *)
func foo() {}

The suggested replacement is:

@available(anyAppleOS 26, *)
func foo() {}

A diagnostic makes the cleanup easier and less manual.

Objective-C and C interop

anyAppleOS is not limited to Swift declarations.

Clang also supports the same availability spelling, which means C, Objective-C, and C++ APIs can use it too.

__attribute__((availability(anyAppleOS, introduced=26.0)))
@interface NewIn26
@end

What about Package.swift?

anyAppleOS is useful inside Swift source files, but it should not be treated as a replacement for platform declarations in Package.swift.

A package manifest still usually lists supported platforms explicitly:

let package = Package(
    name: "SharedFeature",
    platforms: [
        .iOS(.v26),
        .macOS(.v26),
        .watchOS(.v26),
        .tvOS(.v26),
        .visionOS(.v26)
    ],
    targets: [
        .target(name: "SharedFeature")
    ]
)

Inside the target source code, anyAppleOS can still be used for declarations and runtime checks:

@available(anyAppleOS 26.0, *)
public func useSharedFeature() {
    // ...
}

Conclusion

anyAppleOS is not a large language feature. It is a small cleanup for code that targets multiple Apple platforms. Use it for Apple OS 26 and newer shared availability.

It might be interesting: