Swift Observability for Ferrostar 1.x

[Archdoog]

Problem

In Kotlin/Android there's a single, well supported solution for observability with Kotlin Flows. On iOS with Swift, there are several solutions, each with advantages and drawbacks. These include Combine, SwiftUI ObservableObject, SwiftUI @Observable and AsyncSequence.

SwiftUI @Published & ObservableObject

Combine is a feature rich solution and backs the @Published property wrapper used with SwiftUI's ObservableObject. This is an effective tool to trigger SwiftUI updates while also enabling combine sink usage. However, it has the following drawbacks:

1. When used with SwiftUI's ObservableObject, it requires initializing FerrostarCore in the SwiftUI View heirarchy as either @StateObject or @ObservedObject. This makes improper usage possible with more advance architectures where you might create it as a service. This is especially true when multiple view ports might need access to the same ferrostar core instance, e.g. CarPlay.
2. Swift protocols don't support property wrappers. If the value behind @Published is passed through a protocol, it's not longer published nor observable. This can result in unexpected behavior when a developer uses an ObservableObject's @Published property in a SwiftUI view, but doesn't realize it's lost observability somewhere in the code stack.
3. Swift 6+ introduces more tooling for modern concurrency. Combine can still be used in this environment, but there are better modern concurrency focused solutions available that force correctness with Swift 6's compiler safety.

Basic Combine

Basic Combine subjects and publishers solve some of the potential misconfigurations with SwiftUI's ObservableObject through a more basic typed Swift approach with CurrentValueSubject and AnyPublisher. They don't rely on a property wrapper, enabling a protocol safe way to hold the source data and publish observable data streams through an app. The drawbacks with standard combine are the code is verbose, can't be directly consumed in a SwiftUI view, and integrates older swift techniques and tools. All combine subjects and publishers provide a .values AsyncSequence type that allows direct use in modern concurrency contexts. However, its larger scope of legacy Swift tooling means there are several ways to solve the same problems. This increases reviewer workload and the potential for code variance, bugs, etc.

SwiftUI @Observable

The @Observable macro is a great solution for observable values that are used in SwiftUI views. It's automation is simple, efficient and effective. The primary drawback is the lightweight implementation in iOS versions before 26.0. In our existing Ferrostar environment, this means it's extremely difficult to consume an @Observable parameter outside of a SwiftUI view. In Swift 6.2 (os 26.0) several new features are available for this API based on this proposal SE-0475.

This is the best solution, but for now not possible while supporting our current minimum deployment targets.

AsyncSequences

Lastly comes AsyncSequences (the AsyncStream and AsyncThrowingStream). AsyncSequences are a first class modern concurrency tool that makes usage of a stream extremely safe, with compiler safety checks to enforce standard usage. Most modern API's are adopting this as the primary tool for publishing data over time. E.g. CoreLocation's newer CLLocationUpdate.liveUpdates().

The primary issue with an AsyncSequence, is that the system lacks a true data source that can be listened to by multiple consumers. Several solutions to this are coming forward, but many are also guarded by newer Swift 6.2 and iOS 26 availability flags. E.g: AsyncSequence.share() for sharing a sequence across multiple consumers.

Recommended Approach

The ideal outcome is @Observable with the AsyncStream-like Observations behavior in SE-0475. However, with our minimum deployment targets, we won't have reasonable access to the full Observable framework until a year or two from now. Without an aggressive minimum update to iOS 26.

For now, we could adopt AsyncSequences for FerrostarCore's data streams. This gives us a straightforward and safe way for developers to consume updates in a modern concurrency environment. It'll allow us to drop SwiftUI imports for FerrostarCore's target and focus UI behaviors in the UI targets.

public class FerrostarCore {
    var state: AsyncStream<NavigationState>
    var route: AsyncStream<Route?>
}

A developer can then safely use the state as a service in any Swift Task. They can also safely consume it using SwiftUI's task modifier.

struct NavigationView: View {
    
    @State var navState: NavigationState
    
    var body: some View {
        SomeView(navState)
            .task {
                for await state in ferrostarCore.state {
                    self.navState = state
                }
            }
    }
}

Future Enhancements

This solution doesn't force us to abandon SwiftUI's @Observable macro. It just means we'll have to move it to a SwiftUI focused wrapper for ferrostar core. This allows us to support multiple SwiftUI wrappers for different versions of iOS. Allowing developers the flexibility to initialize ferrostar core as a simple Swift service, or directly in a SwiftUI view with a specialized wrapper.

@Observable
public class FerrostarObservable {
    
    private let ferrostarCore: FerrostarCore
    private let stateTask: Task<Void, Never>
    private let routeTask: Task<Void, Never>
    
    var state: NavigationState = .idle
    var route: Route?
    
    public init(_ ferrostarCore: FerrostarCore) {
        self.ferrostarCore = ferrostarCore
        stateTask = Task.detached {
            for await state in self.ferrostarCore.state {
                self.state = state
            }
        }
        routeTask = Task.detached {
            for await route in self.ferrostarCore.route {
                self.route = route
            }
        }
    }
}

[devnull133]

This looks like a great summary!

I'd agree with almost all points. Personally, I do use @Observable, and I do use AsyncSequences (mostly as a client of some frameworks and libs). I do agree both are the way to go. I didn’t know about SE-0475 proposal, but that’s great.

This summary mentions that both techs can live together. That was my very first thought. Personally, I'd totally see NavigationState as an @Observable too. I know it isn’t, since there’s the concept of a state machine and immutable state, but I think this might not feel so natural in this ecosystem, and I wonder if it’s worth exploring an option to have an observable wrapper at that level too. Even though this wouldn’t be consistent with Rust core. But then, the client could either use async streams in their models or just grab NavigationState once and use it directly in their SwiftUI views. If FerrostarCore is observable, I’d somehow expect the child models to be as well if I didn't know more about this specific framework. A nice side effect of that is increased performance of SwiftUI views, which would re-render only when the given property of NavigationState is updated. In the current solution, a new NavigationState basically forces a re-render of every view that depends on it. Obviously, the client app can provide its custom wrapper (I do exactly that in my own app).

I currently don’t really understand @CurrentValueChannel, custom locks, or why you’d need AsyncChannel, but it’s late here and I might just need to revisit that with more energy to dig deeper. I’d say that if, on the client side, I can use it like every other AsyncStream, I don’t mind what’s on Ferrostar’s implementation side. But custom locks look a bit worrying in fresh Swift 6.2 design. I just wonder if it's not worth trying to start very simple and consider these custom libs/solutions where there's a particular use case for that.

btw,

When used with SwiftUI's ObservableObject, it requires initializing FerrostarCore in the SwiftUI View heirarchy as either @StateObject or @ObservedObject. This makes improper usage possible with more advance architectures where you might create it as a service.

I do believe you can initialize your Combine-based class as a service and later pass it into SwiftUI views where you’d use @ObservedObject as always. I think @StateObject initialization is not a requirement. It’s only necessary when the model is initialized within the SwiftUI view so it can survive the specific SwiftUI View lifecycle. Having said that, I definitely wouldn’t try the Combine path.

[Archdoog]

Funny enough, the lack of sense with the CurrentValueChannel was correct. Some misleading documentation on AsyncChannels led me to believe it actually behaved like a Combine subject. The goal being a singular data source that could be listened to as an AsyncStream by multiple consumers, all receiving the same data. My main motivation here was to was to create something that would be close enough to the behavior of @Observable while enabling us to use async streams as the public.

The primary goal

Can we adopt an architecture prepared for first class iOS 26+ @Observable functionality in a backwards compatible manner. I'm not opposed to bumping things myself, but since iOS 16 is our current minimum, @Observable doesn't exist there yet.

---

I do believe you can initialize your Combine-based class as a service and later pass it into SwiftUI views where you’d use @ObservedObject as always. I think @StateObject initialization is not a requirement. It’s only necessary when the model is initialized within the SwiftUI view so it can survive the specific SwiftUI View lifecycle. Having said that, I definitely wouldn’t try the Combine path.

That's could well be. I've attributed some strange behavior with stuck speed limit and road name views to this or the fact it's erasing something through the protocol.

---

The idea of an @Observable NavigationState is definitely solid. Since it's less of a state and more of a combination of states. Detaching it from the core might also let us clean it all up. NavigationState on the swift and kotlin side where some early additions to the library, that seem at odds with the specific state values FerrostarCore hosts.

[Archdoog]

@devnull133 & @ianthetechie thoughts on bumping to iOS 17+ so we can leverage @Observable directly? I still think we want to make FerrostarCore more like CLLocationUpdate and add a new lightweight @Observable around it in place of NavigationState.

Reasoning

After working through similar issues on multiple projects I found the key reason was dropping @Published. It turns out this is a bigger one than I released in the past. Since combine is @preconcurrency it has significant drawbacks moving forward versus AsyncSequences and @Observable. This alone means that @Published (and by proxy ObservableObject) is likely to be a notable burden soon. These challenges will be immediately apparently when we attempt Swift 6 or start to leverage more modern concurrency in code and testing.

If there are no major objections, I'll get started on a MR that aims to align everything architecturally that we can use to finalize this RFC.

[ianthetechie]

Yeah, completely agreed; even iOS 17 is an ancient level by this point. And iOS 16 is just 2%.

https://telemetrydeck.com/survey/apple/iOS/majorSystemVersions/

[devnull133]

Also agree. I probably wouldn’t drop support for an iOS version just because its usage is small, but this affects the architecture at a level that justifies it.

[Archdoog]

This should help facilitate things. It's includes a shim that lets us extract AsyncSequences from @Observable types without requiring a minimum of iOS 26+.

https://github.com/Archdoog/ObservationsKit