Combine and the road to Swift 6

My team has been leveraging structured concurrency to build a relatively large feature. We have been using structured concurrency extensively, incorporating it into the data layer, UI, persistence, and other aspects where we would have previously used the Combine framework. This has not been the smoothest ride but at the time of writing there are no bugs, no crashes, no performance comprises or comprises on developer experience attributable to our usage of structured concurrency.

Overall this has been a great case study in favor of using structured concurrency, especially considering the scale of our feature (~50k lines of production code) and the millions of active users on iOS 14+.

However, taking a broader perspective, the other teams at my company are still utilizing the Combine framework. I am curious about the future vision for Combine. Will there be a scenario where structured concurrency and Combine coexist for an extended period, or will the stricter concurrency checks anticipated in Swift 6 ultimately require a shift towards structured concurrency?

TL;DR: What is the envisioned future for the Combine framework?

8 Likes

Since large Apple's frameworks highly adopt Combine (e.g. SwiftUI states & updates is all about publishers), IMO for Apple platform it ain't going anywhere and will be here for long. Combine also have in mind a bit different paradigm of reactive programming, so I suppose it is not right to compare it with Swift Concurrency as well. With AsyncStream you can now write some code that earlier has required Combine, but it does not look as direct replace of publisher streams for all use cases.

1 Like

Could be wrong, but I think initially main difference of FRP vs. async/await is event streams of multiple values vs. one value. Later we have streams and observability for async/await, so don't see why Combine should be used, considering it's a closed framework.
On top of that when writing Combine code you end up in lot's of additional types and bouncing between .map, .flatMap and etc. async/await makes code cleaner as a language feature, IMHO.

3 Likes

Since large Apple's frameworks highly adopt Combine (e.g. SwiftUI states & updates is all about publishers), IMO for Apple platform it ain't going anywhere and will be here for long.

Indeed, the support of Combine is not going anywhere. I'm more curious about the vision. Will there be any new iterations of Combine that fit into actor model, etc?
Current evidence is that there were no significant updates to Combine at WWDC'23 and WWDC'22. And the significant update at WWDC'21 was bridging to structured concurrency.

Combine also have in mind a bit different paradigm of reactive programming, so I suppose it is not right to compare it with Swift Concurrency as well.

True, the paradigm is a bit different. Yet AsyncSequence can be extended to provide tooling that looks and behaves similarly to Combine. We did that in our feature and got code that looks very similar to code written with Combine. However there is no need for ubiquitous in Combine .receive(on: DispatchQueue.main) and handling one-shots is much better.

In terms of vision, I think it's telling that there has been little to no information on Combine in the last few WWDC conferences. In fact, I don't think Combine was even really mentioned the WWDC immediately following the one it was announced at.

2 Likes