Handling app moving from foreground to background

[andwrobs]

Hi TCA community,

My app needs to do async cleanup work when it moves to background, e.g. flushing queued events, saving latest profile.

Currently, I'm unable to explain the behavior I'm seeing in a barebones example repo I've set up when the app moves to .background.

TLDR:
it's acting on changes to@Environment(\.scenePhase) private var scenePhase, but when this variable switches to .background the following code block’s second print statement only runs when I reopen the app, i.e. the next time it moves from .background -> .inactive.

case .background:
     print(".didChangeScenePhase(.background)")
     return .run { send in
      print("background alive 1 sec later") <-- runs in expected spot
      try await mainQueue.sleep(for: .milliseconds(500))
      print("background alive 2 sec later") <-- does not run until next .inactive
     }

I thought apps had around 5 seconds to do cleanup work, so am puzzled as to why the print gets frozen in a time machine until re-open.

---

see also:

• https://developer.apple.com/documentation/swiftui/scenephase
• https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622997-applicationdidenterbackground (esp “Discussion” section disclaimer)

happy sunday 😃

[tgrapperon]

Hey @andwrobs! In this simple case, you should probably fence your .run block with (begin|end)BackgroundTask:

return .run { send in
  let backgroundTaskID = await UIApplication.shared.beginBackgroundTask(withName: "\(Self.self)")
  // Perform your work
  try await mainQueue.sleep(for: .milliseconds(500))
  await UIApplication.shared.endBackgroundTask(backgroundTaskID)
}

This will grant you a little more execution time (around 30s AFAIK). There is a variant for extensions which can't touch UIApplication.shared. If you need more time, there are more complex background operation APIs, but this one should work.

Beware though, send doesn't await for the effects produced by the emitted action to finish before continuing, so you may need to pass the id around and end the task yourself at a later point, in another place, when you're sure that the work is done. The PR #1895 should greatly improve the ergonomics here (and maybe allow to formalize this solution into something reusable).

Ideally, this UIApplication should be modelized as a Dependency. This is what I did in swift-dependencies-additions, but you can completely model this as a very simple two-endpoints dependency yourself:

extension DependencyValues {
  public var backgroundTask: BackgroundTask {
    get { self[BackgroundTask.self] }
    set { self[BackgroundTask.self] = newValue }
  }
}

public struct BackgroundTask: Sendable {
  public let begin: @Sendable @MainActor (String?) -> UIBackgroundTaskIdentifier
  public let end: @Sendable @MainActor (UIBackgroundTaskIdentifier) -> Void
}

extension BackgroundTask: DependencyKey {
  public static var liveValue: BackgroundTask {
    .init {
      UIApplication.shared.beginBackgroundTask(withName: $0)
    } end: {
      UIApplication.shared.endBackgroundTask($0)
    }
  }

  public static var testValue: BackgroundTask {
    .init(
      begin: unimplemented(#"@Dependency(\.backgroundTask).begin"#),
      end: unimplemented(#"@Dependency(\.backgroundTask).end"#)
    )
  }

  public static var previewValue: BackgroundTask { liveValue }
}

[andwrobs]

Hey @tgrapperon!

I also see the extended version of BackgroundTask dependency here: ApplicationDependency,

Beware though, send doesn't await for the effects produced by the emitted action to finish before continuing

Appreciate you surfacing this point & related PR!

This is all very helpful, thank you so much for the thoughtful answer. Cheers