Swift 6 compatibility

[defagos]

As a developer I would like to benefit from improvements made with Swift 6.

Acceptance criteria

• Swift 6 support has been enabled (not to be delivered before Xcode 16 is officially available).

Tasks

• Update version in package manifest.
• Fix issues.
• Update Swift version in the demo.
• Fix issues.
• Enable explicit modules in the demo target.
• Report issues found to Apple, if any.
• Think about publishers and guarantees (e.g. should publishers provided by Player always publish on the main thread? Offer no such guarantee?)

[defagos]

There is an issue with structs and strict concurrency checking:

public struct Flags {
    public static let none = Self(isEnabled: false)       // Static property 'none' is not concurrency-safe because non-'Sendable' type 'Flags' may have shared mutable state
    public let isEnabled: Bool
}

struct Flags2 {
    public static let none = Self(isEnabled: false)       // No issue
    public let isEnabled: Bool
}

struct Flags3 {
    static let none = Self(isEnabled: false)              // No issue
    let isEnabled: Bool
}

I am not really understanding why this happens with a constant and since global instantiation is guaranteed to be safe. But this might be worth a deeper look and possibly a bug report if appropriate.

[defagos]

I investigated further how we could implement Swift 6 concurrency checking in Pillarbox, especially in the PillarboxPlayer package.

Current thoughts:

• I am not sure we should blindly adopt @MainActor everywhere. AVPlayer is marked as @MainActor but almost all its public API is marked as nonisolated since iOS / tvOS 16, which means that most of the API can be used off the main thread.
• Instead we should probably focus in making Player (and other types) simply @Observable. It namely seems that no additional work is required for SwiftUI updates to be read from the main thread. This would also make Player more flexible and would avoid @MainActor spreading through the codebase like a disease. More information might be available on the Swift forums, in the revised pitch or in the evolution proposal itself. Of course this does not make the Player implementation thread-safe, e.g. with the use of a recursive lock.
• We can use weakAssign(to:on:) to plug publishers to properties of the observable object. Of course the assigning / reading such properties should be made safe with locks.

I wrote a small prototype to evaluate the feasibility of this approach.

If adopting @Observable is the best way to adopt Swift 6 without littering our code with @MainActor in an unnecessarily restrictive way, we should pause Swift 6 concurrency adoption and make the move to Observable when we can drop support for iOS / tvOS 16.

[defagos]

I opened an issue #931 for thread-safety. Player should likely not be annotated as @MainActor unnecessarily, we should rather document that in the meantime it is safe to be used on the main thread only.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 14 days or if the stale label is not removed.

[github-actions]

This issue has been automatically closed because it has not had recent activity.