Observation Support

[woodymelling]

Hey Team!

I'm diving into Android Support for the point-free tooling, including TCA 2.0, Sharing, and SqliteData

It's starting to be possible to compile a bunch of these libraries for Android, but I believe that Observation support is going to be a big hurdle.

Many of these libraries don't directly use the @Observable macro, but manually conform to the Observable protocol. This works properly in SwiftUI, and when an Observable conforming type emits a withMutation notification, it signals for a recomputation of any interested views.

Sharing is the easiest to test this with, and the most trivial uses of @Shared don't work in skip.

import Sharing

struct ContentView: View {

    @Shared(.inMemory("count")) var count: Int = 0

    var body: some View {
        VStack {
            Text("\(count)")
            Button("Increment") {
                $count.withLock { $0 += 1 }
            }
        }
    }
}

This compiles, but the view never re-renders after the mutation.

What needs to happen to migrate skip towards being able to handle these cases?

[marcprux]

The problem with @Observable (or manual implementation of the Observable protocol) is that while it "works" just fine with the Swift SDK for Android (as Observation is one of the supported modules on Android), we don't have any way to hook into the observation process in order to trigger recomposition, and any changes made to the model state will not be seen on the Compose side.

We touch on this a bit at https://skip.dev/docs/app-development/#observables and you can see how we implement the fake "Observation" shim that makes this all work at https://github.com/skiptools/skip-android-bridge/blob/main/Sources/SkipAndroidBridge/Observation.swift. But in order to use this solution, the module needs to be "skip-aware", in that it imports the skip-fuse repository and the module must import SkipFuse. This is generally acceptable to models that exist at the Skip app level, but third-party repositories are unlikely to want to add a dependency on Skip just to be able to work properly with Skip's Compose bridging.

The best solution would be to figure out a way to properly hook into the Observation machinery to just support this out of the box, but the (rather weird) machinery of observation doesn't seem to have been designed with this scenario in mind. I'd be happy for other folk to take a look at it and verify this conclusion. We'd be doubly-happy if anyone can suggest a clean solution. 😉

For the time being, kludgy workaround might be to observe-the-observable at the View level, and then do something like update a local @State variable when the observable changes, which will trigger a recomposition. I haven't tested this personally, so I would be interested to hear if this workaround actually works at all.

[woodymelling]

Sounds good.

I can start to look into the different options. The Observation mechanisms are tricky, and Skip has do tricky stuff for it's views. I don't expect this to be trivial, but I do think it'll be worth it, and I'm willing to put my time towards that goal.

I'll see what I can do, and try to bring relevant parties here to discuss different approaches.

[stephencelis]

While it would probably be nicest for end users for Observation to just work as expected in Skip, would it also be reasonable for a third party framework to have a SkipFuse trait that conditionally brings Skip in on a trait (enabled by default on Android)?

[marcprux]

At first blush, traits would be an ideal solution to this. But there are various shortcomings (which we agonized over in groue/GRDB.swift#1708 and groue/GRDB.swift#1827) when trying to implement them for GRDB to support custom SQLite/SQLCipher builds) like not playing well with Xcode. Furthermore, a trait cannot hide a dependency from being visible in the package manager interface even when it is disabled, which might be troubling to some folk with a parsimonious attitude towards dependencies. Also, SwiftPM package plugins cannot be enabled/disabled based on a trait, so unless everyone wants to see and trust/enable the Skip plugin regardless of whether it has relevance for their use case, it's a non-starter.

Basically, traits are not (yet) a good fit for this sort of issue. But they have potential.

What a package maintainer could do is tack on some addendum to their Package.swift that checks for a TARGET_OS_ANDROID environment variable. This is an unofficial env that is automatically set by skip android build and when building Skip apps from Xcode via the (gnarly) skip-bridge-generated Gradle build (controlled by https://github.com/skiptools/skip-bridge/blob/main/Sources/SkipBridge/Skip/skip.yml). It would go something like this:

let package = Package(…)

let android = Context.environment["TARGET_OS_ANDROID"] ?? "0" != "0"
let android = ProcessInfo.processInfo.environment["TARGET_OS_ANDROID"] == "1"
if android {
    package.dependencies += [
        .package(url: "https://source.skip.tools/skip.git", from: "1.0.0")
    ]

    package.targets.forEach { target in
        guard target.type == .regular || target.type == .test else { return }
        if target.plugins == nil {
            target.plugins = []
        }
        target.plugins?.append(.plugin(name: "skipstone", package: "skip"))

        // Add the SkipFuse dependency
        target.dependencies.append(.product(name: "SkipFuse", package: "skip"))
    }
}

That's sort of a big ask for a package maintainer that might not want to know or care about Skip, and is a lot to do just to get Observation working, but it could be a short-solution for a sufficiently motivated developer.

[woodymelling]

This also impacts the upcoming TCA26 (which now does compile for android 🙌 )

import SwiftUI
import ComposableArchitecture2

@Feature
struct Counter {
    struct State {
        var count = 0
    }

    enum Action {
        case didTapIncrement
    }

    var body: some Feature {
        Update { state, action in
            switch action {
            case .didTapIncrement:
                state.count += 1
            }
        }
    }
}


enum ContentTab: String, Hashable {
    case welcome, home, settings
}

struct ContentView: View {

    let store: StoreOf<Counter> = .init(initialState: Counter.State()) {
        Counter()
    }

    var body: some View {
        VStack {
            Text("TCA")
                .font(.largeTitle) 
                
            Text("\(store.count)")
                .font(.headline)
            Button("Increment") {
                store.send(.didTapIncrement)
            }
        }
    }
}

A simple feature like this does the same thing. On iOS, the changes are reflected in the view, but Android does not recompute its view to observe the changes when observation is emitted.

Screen.Recording.2026-04-10.at.2.08.08.PM.mov

I know that @stephencelis and @mbrandonw have some pretty deep knowledge of Observation, (and a in depth series on it). Maybe they can help guide a true Observation implementation for skip

I'm definitely interested in getting this working, and I think it's the whole cross platform story for TCA26+skip is looking achievable and very enticing as an app developer. 😃

[woodymelling]

I think we're in luck!

My initial tests seem to show that true observation support should be straightforward!
A helper like this seems to makes both of the cases I posted above work.

struct WithObservationTracking<Content: View>: View {
    @ViewBuilder let content: () -> Content
    @State var _token = 0

    init(@ViewBuilder content: @escaping () -> Content) {
        self.content = content
    }

    var body: some View {
        let _ = _token
        return withObservationTracking {
            content()
        } onChange: {
            _token += 1
        }
    }
}

If I remember correctly, the SwiftUI internals just insert something similar to this on every view. I think that should be possible in the bridge or in skip-ui directly.

I'll start excercising the WithObservationTracking wrapper against sharing and tca2. Theres prior art for this with https://github.com/pointfreeco/swift-perception. This same API on every view was needed to backport Observation to <iOS 17, back when it first came out.

If this works under more thorough testing, you might be able to adopt it in skip-fuse and do away with the @observable bridge altogether

[woodymelling]

Screen.Recording.2026-04-10.at.11.54.46.PM.mov

[marcprux]

That's exciting, although while I haven't had a chance to look closely, I have a recollection that we tried something similar in the past and it didn't work. I looks too good to be true 😁

Ideally you would be able to try this out against the Showcase Fuse https://github.com/skiptools/skipapp-showcase-fuse/blob/main/Sources/ShowcaseFuse/ObservablePlayground.swift (which requires a composite workspace with the various libraries, as described at https://skip.dev/docs/contributing/#skipui-and-skipfuseui).

[aabewhite]

I think it might be possible to build something like this in. There are just a lot of mysterious aspects of Observation that made me nervous. I don't remember the particulars I was concerned about.

I will point out, though, that this approach alone would not allow an Observable to transparently power a UI written directly in Compose. Our Observable support can do that today, and it's an attractive feature. So we'd have to think of a way that users could retain our current mechanism if they need that ability.