Investigate replacement of Combine with async sequences

[defagos]

As a Pillarbox developer I would like to keep Pillarbox aligned with current practices and tools. In particular Pillarbox could provide APIs that are friendlier for integration with Swift Concurrency.

Hints

Pillarbox currently makes heavy use of Combine, which has frictions with Swift Concurrency annotations. Async streams, on the other hand, lack essential features that Combine provides.

We could perform several investigations, e.g.

• Providing more async/async stream friendly APIs but keep our implementation Combine-based.
• Check if a minimal prototype player can be implemented with new concurrency-related APIs.
• Use of Observation as a replacement for published properties.

The problem is that:

• Some fundamental tools provided by Combine are missing in the Swift Concurrency and async stream worlds.
• Main challenges is probably multicast and custom publishers we have (e.g. replay subject).
• Async algorithms is still a WIP.

Some tools might bridge the gap between both worlds, but they probably lack essential tools we require, e.g:

• Additional (unofficial) extensions
• Async Combine

Probably worth a PoC on emblematic publishers (player publishers, custom periodic time publisher, replay subject, wait operator, triggers and signals, etc.). Also interesting to see how we could provide backwards compatibility with Combine code (we have a publisher wrapping a sequence on our AVMetrics branch).

We should also investigate if new test helpers are required or if Swift Testing suffices (unlike what we had to do for Combine).

Current best guess about what we could do in the future:

• We should in any case keep the two APIs, Combine and async streams. Async streams can be trivially created from Combine publishers (values property), and a publisher can be created from an async sequence (we have a working implementation on our AVMetrics branch).
• Once async algorithms support the same feature set as Combine we could replace Combine with async sequences internally. The external API would remain the same but we would benefit from the compiler help (most notably regarding sendability checks).

I think that we should for this reason explicitly provide our public Combine API translated as async sequences. Even though the implementation is trivial this means that, no matter how our implementation works internally (Combine or async streams), the public API would remain stable during the update process.

Remark

xOS 26 introduces new automatic observability for AVPlayer. Works with rate, time ranges, but is a global opt-in. Probably more fun than useful but still could be inspiring for Observation adoption or interaction with async sequence.

Acceptance criteria

• ...

Tasks

• ...

• Maybe we can use assumeIsolated to bridge a Combine closure which we know on the main thead to main actor state? (Maybe not even needed; it seems there is a runtime assertion). Maybe a helpful link.

https://www.massicotte.org/combine-annotations
https://mastodon.social/@wlumley/115353284152985685