backgroundTask(_:action:) + TCA concurrency

[kamcma]

Hello,

I've been experimenting with getting TCA's new concurrency APIs integrated with the new background refresh APIs in iOS 16. This API is a bit like last year's refreshable(action:) modifier, where you provide an async closure. However, unlike refreshable(action:), I get a warning about capturing the view store:

struct MyScene: Scene {
  @Environment(\.scenePhase) private var scenePhase
  let store: Store<SceneState, SceneAction>

  var body: some Scene {
    WithViewStore(self.store) { viewStore in
      WindowGroup {
        EmptyView()
          .refreshable {
            await viewStore.send(.refresh).finish() // no warning
          }
      }
      .backgroundTask(.appRefresh("my-background-task-identifier")) {
        await viewStore.send(.backgroundTask).finish() // ⚠️ Capture of 'viewStore' with non-sendable type 'ViewStore<SceneState, SceneAction>' in a `@Sendable` closure
      }
      .onChange(of: self.scenePhase) { viewStore.send(.didChange(scenePhase: $0)) }
    }
  }
}

My intuition here is to mark the closure I'm providing as @ MainActor, since it's going to be capturing the view store. Is this the correct fix?

-     .backgroundTask(.appRefresh("my-background-task-identifier")) {
+     .backgroundTask(.appRefresh("my-background-task-identifier")) { @MainActor in
        await viewStore.send(.backgroundTask).finish()
      }

Looking at the documentation, neither refreshable(action:)'s nor backgroundTask(_:action:)'s closure parameters seem to be marked @ Sendable per se, but backgroundTask(_:action:)'s closure does have sendable generics, which just happen to be void in the overload I'm calling. Or perhaps refreshable(action:)'s closure could stand to be marked @ MainActor too, for the same reason of capturing the view store, it just hasn't been audited for concurrency yet so no warning for now? Thanks in advance for any pointers.

[mbrandonw]

Although the docs say that backgroundTask's closure isn't @Sendable, it does seem to be the case in the Swift headers:

public func backgroundTask<D, R>(_ task: BackgroundTask<D, R>, action: @escaping @Sendable (D) async -> R) -> some Scene where D : Sendable, R : Sendable

No idea why the docs are wrong, but maybe a feedback should be filed.

Also, even the refreshable closure is marked as @Sendable as can be seen in the Swift headers, but again the docs report it as being merely @escaping. So, it seems weird that we get the sendable warning for backgroundTask but not refreshable.

Well, to figure out why we had to go all the way into the .swiftinterface file, and there we can see a big difference between the two methods:

public func refreshable(@_inheritActorContext action: @escaping @Sendable () async -> Swift.Void) -> some SwiftUI.View

public func backgroundTask<D, R>(_ task: SwiftUI.BackgroundTask<D, R>, action: @escaping @Sendable (D) async -> R) -> some SwiftUI.Scene where D : Swift.Sendable, R : Swift.Sendable

The refreshable API is marked as @_inheritActorContext, which means it is run as @MainActor, and hence why we don't need to mark the closure as @MainActor.

So, for now I do believe the best solution is to just mark the closure of backgroundTask as @MainActor, and in the future maybe there are a few tricks that TCA can pick up thanks to @_inheritActorContext. It's not ideal to use underscored attributes in the library, but also it's a pretty handy tool!

[kamcma]

Wow, thanks for the thorough answer! And it ended up being quite interesting. Very cool.

[kamcma]

On reflection, I think the different behaviors of these two APIs make sense. A refresh action from the UI is by definition coming from the main actor, but a background task action, being unrelated to any UI events, doesn't have to be. In theory, I could do my refresh work here entirely outside my TCA store and off the main actor. But, if I want to route this callback through my TCA store, for business logic/testability reasons, it makes sense that I need to direct that callback to the main actor before hitting the store (which can then in turn kick off concurrent effects). Neat!