'InlineArray' is only available in macOS 26.0 or newer

ibex · January 13, 2026, 5:19am

I am using Xcode 26.2 on a Mac (15.7.3 (24G419)) with Intel cores.

I am unable use InlineArray for some reason.

'InlineArray' is only available in macOS 26.0 or newer

What is the reason?

vanvoorden · January 13, 2026, 5:25am

This sounds correct? InlineArray requires SwiftStdlib 6.2:

github.com/swiftlang/swift

stdlib/public/core/InlineArray.swift

swift-6.2.3-RELEASE


      
          /// ----------------------
          ///
          /// Array literal syntax can be used to initialize an `InlineArray` instance.
          /// A stack-allocated array will do in-place initialization of each element.
          /// The `count` and/or `Element` can be inferred from the array literal.
          ///
          ///     let a: InlineArray<4, Int> = [1, 2, 4, 8]
          ///     let b: InlineArray<_, Int> = [1, 2, 4, 8]
          ///     let c: InlineArray<4, _>   = [1, 2, 4, 8]
          ///     let d: InlineArray         = [1, 2, 4, 8]
          @available(SwiftStdlib 6.2, *)
          @frozen
          @safe
          @_addressableForDependencies
          public struct InlineArray<let count: Int, Element: ~Copyable>: ~Copyable {
            @usableFromInline
            internal let _storage: Builtin.FixedArray<count, Element>
          }
          
          @available(SwiftStdlib 6.2, *)
          extension InlineArray: Copyable where Element: Copyable {}

Which requires macOS 26:

github.com/swiftlang/swift

utils/availability-macros.def

swift-6.2.3-RELEASE


      
          SwiftStdlib 5.3:macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0
          SwiftStdlib 5.4:macOS 11.3, iOS 14.5, watchOS 7.4, tvOS 14.5
          SwiftStdlib 5.5:macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0
          SwiftStdlib 5.6:macOS 12.3, iOS 15.4, watchOS 8.5, tvOS 15.4
          SwiftStdlib 5.7:macOS 13.0, iOS 16.0, watchOS 9.0, tvOS 16.0
          SwiftStdlib 5.8:macOS 13.3, iOS 16.4, watchOS 9.4, tvOS 16.4
          SwiftStdlib 5.9:macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0
          SwiftStdlib 5.10:macOS 14.4, iOS 17.4, watchOS 10.4, tvOS 17.4, visionOS 1.1
          SwiftStdlib 6.0:macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0
          SwiftStdlib 6.1:macOS 15.4, iOS 18.4, watchOS 11.4, tvOS 18.4, visionOS 2.4
          SwiftStdlib 6.2:macOS 26.0, iOS 26.0, watchOS 26.0, tvOS 26.0, visionOS 26.0
          
          # Like SwiftStdlib 5.0, but also the oldest visionOS.
          SwiftCompatibilitySpan 5.0:macOS 10.14.4, iOS 12.2, watchOS 5.2, tvOS 12.2, visionOS 1.0
          
          # Identical to SwiftStdlib 6.2.
          SwiftCompatibilitySpan 6.2:macOS 26.0, iOS 26.0, watchOS 26.0, tvOS 26.0, visionOS 26.0
          
          # TODO: When you add a new version, remember to tell the compiler about it
          # by also adding it to include/swift/AST/RuntimeVersions.def.

ibex · January 13, 2026, 6:19am

Thank you, but would you know the specific reason?

I would understand the requirement if it were to do with the concurrency system which might have a dependency on Apple silicon cores, but for a data structure I am baffled by this requirement.

vanvoorden · January 13, 2026, 6:26am

I don't actually think there is a lot of precedent here that new data structures should — or can — be backdeployed.

The Span types are backdeployable but AFAIK it was a lot of effort to get that working.

David_Smith · January 13, 2026, 7:02am

In general, new types are extraordinarily difficult to back port, regardless of what they do. New functions/methods are much much easier. Among other issues, system libraries adopting them internally and then clients bringing their own copy and trying to pass into the library would lead to problems.

CrystDragon · January 13, 2026, 7:47am

In addition to what David has said, InlineArray also relies on the language feature of "Integer Generic Parameters", which already requires a Swift 6.2 runtime in the first place.

Related thread: Using InlineArray on macOS

tim1724 · January 14, 2026, 7:04pm

On Apple platforms the Swift Standard Library is part of the system software. So you're stuck with whatever version shipped with a particular version of the operating system. (I suppose Apple could update it in a software update, but they generally don't.)

matthewruzzi · January 14, 2026, 10:50pm

It used to be bundled with the app itself. Is there still any way to do this?

tim1724 · January 14, 2026, 10:59pm

Not for a long time now. Not since Apple's system libraries started using Swift. They need the version Apple ships, and you can't load two copies of the standard library into the same process, so if you link against just about any Apple library (aside from maybe libSystem and other C stuff) you wouldn't be able to use any version of the Swift Standard Library aside from the system one. Thus the option to use your own was removed a long time ago, as it's not useful for much besides perhaps command line utilities (as anything GUI will pull in the system's copy of the Standard Library)

David_Smith · January 14, 2026, 11:35pm

libsystem actually indirectly links libswiftCore now it turns out. iirc the dependency chain is libsystem -> libdispatch -> libobjc -> libswiftCore

tim1724 · January 15, 2026, 1:56am

Well, that pretty conclusively rules out using your own copy of the Swift standard library for anything on modern macOS. You can't even make system calls without libSystem (at least not safely, as the Go maintainers learned the hard way)