"Heavy" view updates are ran on a background thread instead of the main thread

[josh-arnold-1]

Hello,

This isn't necessarily a Perception bug but more so a behavior I've noticed with both @Observable and @Perceptible. For this post, I will use @Observable but the behavior is the same with @Perceptible.

I've noticed, if you make "light" / "simple" updates from a background thread using @Observable, it updates the view just fine.

However, if the updates from the background thread are "heavy" (high volume of view updates triggered), I've noticed the view updates occur on the background thread.

I think I've so far only noticed this with UIViewRepresentable.

Does anyone have any insight into whats going on an why?

I know that you should probably ensure view updates are dispatched to the main actor by await MainActor.run { /* update here */ }, or by marking your view model / model with @MainActor, but I'm more so trying to understand whats going on under the hood.

Here is an example:

import SwiftUI
import Observation

@MainActor
struct ContentView: View {
    @State private var model = Model()

    var body: some View {
        LabelRepresentable(text: model.text)
            .padding()
            .task {
                model.heavyUpdate()
            }
    }
}

@Observable // Same behavior with `@Perceptible` too
final class Model {

    private var count: Int = 0

    var text: String {
        String(describing: count)
    }

    func heavyUpdate() {
        DispatchQueue.global().async {
            for _ in 0..<100 {
                Task.detached { [self] in
                    repeat {
                        try? await Task.sleep(nanoseconds: 100_000)
                        count += 1
                    } while true
                }
            }
        }
    }

    func lightUpdate() {
        DispatchQueue.global().async {
            for _ in 0..<100 {
                self.count += 1
            }
        }
    }
}

@MainActor
struct LabelRepresentable: UIViewRepresentable {
    typealias UIViewType = UILabel

    let text: String

    func makeUIView(context: Self.Context) -> Self.UIViewType {
        return UIViewType()
    }

    func updateUIView(_ uiView: Self.UIViewType, context: Self.Context) {
        // a warning will appear here that this is being updated from a background thread
       // only when `model.heavyUpdate()` is invoked. Not for `model.lightUpdate()`
        uiView.text = text
    }
}

#Preview {
    ContentView()
}

Thanks for your time!

[stephencelis]

I believe this is the expected behavior of @Observable and Swift concurrency. Views are main actor isolated, and so are most view action closures, Tasks in views inherit the main actor, and async work started from the main actor often remains on the main actor till the first suspension point. Because of this, most of the time a simple Observable model will just happen to automatically process updates to its state on the main actor.

That said, you probably want to explicitly apply @MainActor to observable/perceptible models that power the UI to avoid those background updates.

[josh-arnold-1]

Thank you for the reply!

Does this mean that, even when we dispatch to DispatchQueue.global(), since this code has not yet to be "suspended", the main actor will handle dispatching the work to the main thread for us when needed?

I'm still a little confused because I assume that dispatching to DispatchQueue.global() will switch off the main actor to some background thread? And if that is true, isn't that the same case as switching off the main actor due to a suspending await call? Like how does the difference between the background thread via DispatchQueue / GCD and the async await suspension affect whether or not the swiftui view is updated on the main actor or not?

Thanks!

[stephencelis]

Dispatch queues and Swift concurrency are almost completely different paradigms (the main dispatch queue is an exception with some built-in @MainActor affordances and compiler special casing for diagnostics), so once you dispatch to a background queue the main actor won't be involved in that operation unless you explicitly introduce it again via a Task (or main queue).

I've found that for low-traffic updates, background updates to observable state are reflected in the UI quickly, but I don't think this is guaranteed. You should always be explicit with the main UI thread if your goal is to drive the UI from some model state.