Strict concurrency incompatible with Apple frameworks re. `var` static members

What's the intended workaround for dealing with Apple frameworks that are not compatible with Swift concurrency, but for which @preconcurrency does nothing? e.g. CoreImage.

public struct CIFormat : Hashable, Equatable, RawRepresentable, @unchecked Sendable {
    public init(rawValue: Int32)

extension CIFormat {
    @available(macOS 10.4, *)
    public static var ARGB8: CIFormat


These are logically constants, but declared as var for some reason. So they apparently cannot be used at all, because any attempt to do so results in:

:warning: Reference to static property 'ARGB8' is not concurrency-safe because it involves shared mutable state; this is an error in Swift 6

I have to reference these constants - it's the only way to use many of the CoreImage APIs. I can choose to ignore the spurious warnings for now, although that's annoying, but then what can I do once Swift 6 arrives?


Really our only hope is that Swift 6 / Xcode 16 / 2024 OS versions include fully audited Apple SDKs to fix these warnings, whether through updated types or markup to disable concurrency checking for those values. Whether those fixes will properly backward deploy (perhaps for types which were always correct, probably not for types they had to fix), who knows.


this problem isn’t limited to Apple SDKs, CommandLine.arguments suffers from the same problem.

1 Like

We're hoping to resolve this ASAP. We landed this last week: [stdlib] Deprecate CommandLine.arguments setter by Azoy · Pull Request #72258 · apple/swift · GitHub


I belive @hborla has confirmed that @preconcurrency not having an effect is a bug. I’m not sure there is a workaround until a new compiler is released with a fix.


I'd do that (YANGNI). By the time of Swift 6 things will improve, and if they don't and that appears to be an error in Swift 6 and you can't avoid switching to Swift 6 – deal with the issue right there and then. e.g. by introducing a C wrapper that reexports those variables as constants.

Hopefully. But I'm concerned that indications are Swift 6 is coming in June, which is really close compared to the amount of work that needs to be done. The compiler might be ready, but Apple's frameworks aren't.

Many of the Apple frameworks we're working with currently are the better part of a year old, so we really have no idea what state they're in until we see the first betas.

out of curiosity, what indications have you observed for a June release?

I suppose mostly that Swift 5.10 has already shipped. I guess it's possible that Apple won't release a new Swift version around WWDC, but that would be unusual.