SwiftUI Bug may cause issues in TCA with any .task that you have (or .onAppear, .onDisappear, etc...)

[oliverfoggin]

I have raised this as a bug with Apple. FB11763863

We make use in our app of the .task view modifier to trigger subscriptions to certain caches and endpoints that we have in the app. And similarly, we do things in .onAppear and .onDisappear.

Before I understood what this bug was we had an issue where a user would log out of the app and we would clear any cached data. But when logging back in with a separate user (this is all in our debug env) the cache would still have old data from the old user.

I traced it down to the fact that our .tasks were being run at the wrong time.

Here is a quick example that highlights the problem

import SwiftUI

struct ContentView: View {
  @State var loggedIn: Bool = false

  var body: some View {
    switch loggedIn {
    case false:
      Button("Login") {
        loggedIn = true
      }
      .onAppear {
        print("🍏 Login on appear")
      }
      .onDisappear {
        print("🍎 Login on disappear")
      }
      .task {
        print("🍌 Login task")
      }
    case true:
      TabView {
        NavigationView {
          Text("Home")
            .navigationBarTitle("Home")
            .onAppear {
              print("🍏 Home on appear")
            }
            .onDisappear {
              print("🍎 Home on disappear")
            }
            .task {
              print("🍌 Home task")
            }
            .toolbar {
              ToolbarItem(placement: .navigationBarTrailing) {
                Button("Logout") {
                  loggedIn = false
                }
              }
            }
        }
        .tabItem {
          Image(systemName: "house")
          Text("Home")
        }

        NavigationView {
          Text("Savings")
            .navigationBarTitle("Savings")
            .onAppear {
              print("🍏 Savings on appear")
            }
            .onDisappear {
              print("🍎 Savings on disappear")
            }
            .task {
              print("🍌 Savings task")
            }
            .toolbar {
              ToolbarItem(placement: .navigationBarTrailing) {
                Button("Logout") {
                  loggedIn = false
                }
              }
            }
        }
        .tabItem {
          Image(systemName: "dollarsign.circle")
          Text("Savings")
        }

        NavigationView {
          Text("Profile")
            .navigationBarTitle("Profile")
            .onAppear {
              print("🍏 Profile on appear")
            }
            .onDisappear {
              print("🍎 Profile on disappear")
            }
            .task {
              print("🍌 Profile task")
            }
            .toolbar {
              ToolbarItem(placement: .navigationBarTrailing) {
                Button("Logout") {
                  loggedIn = false
                }
              }
            }
        }
        .tabItem {
          Image(systemName: "person")
          Text("Profile")
        }
      }
      .onAppear {
        print("🍏 Tabview on appear")
      }
      .onDisappear {
        print("🍎 Tabview on disappear")
      }
      .task {
        print("🍌 Tabview task")
      }
    }
  }
}

The problem exists for any apps that use a TabView and then at some point in the life of the app the TabView is removed from the hierarchy.

In this example, you can "log in" to the app. This will then show the tab view. When you switch between the tabs you can see the various onAppear, onDisappear, and task logs.

However, when you then tap "log out" you will again see all the onAppear, onDisappear, and task of any of the views that you had previously opened but are no longer the current tab.

This meant that our log out was clearing the cache but then SwiftUI was causing all our subscription caches would fetch new data and also send actions into their respective view stores which causes a huge rush of incoming purple warnings from TCA.

Something to keep an eye out for.

[pyrtsa]

Have noticed this as well and this keeps us from using TabViews in our apps for now, falling back to UIKit tabs in the meanwhile.

[SilverTab]

@oliverfoggin Thanks for posting this... I'm seeing the same issue you described (in a very similar context where my tab bar is only presented to logged in users). Curious as to wether you found a decent workaround (I haven't had much luck so far), or just stopped using TabView altogether 🤔

[tgrapperon]

@SilverTab I coincidentally wrote this destinationTask modifier a few days ago to provide a stable .task modifier. NavigationView/Stack indeed restarts the tasks of the parent view when you pop from a child, but without changing the view's identity/resetting its @State values, and this behavior that differs from presentation can be surprising.
So I wrote this destinationTask that is a drop-in replacement for .task that makes the .task live as long as the View (i.e. as its identity). When you're using it, .destinationTask always behaves the same, whether you're presenting or navigating.
According to my tests, it doesn't start the task again when you log out in @oliverfoggin's example.
It however doesn't restart the task when you go back to the tab from another, so you may need to perform a few adjustments using onAppear/onDisappear to make it work as you would expect (if this is something you would expect to happen).
As I was planning to propose it for TCA, I made it iOS 13 compatible, hence the rather weird implementation. If you can live with iOS 14+, you can refactor/simplify it using @StateObject and onChange modifier instead. Let me know if there is interest.

[oliverfoggin]

I haven't found a fix. More of a workaround to make sure that all the effects that get re-triggered don't do anything if there user is not logged in. So it still goes wrong but its "safe".

[wshamp]

Bumping this as this basically makes TabViews unusable with a switch store setup for log in and log out. Using onAppear to start effects is basically a requirement at this point. Has anyone found any solutions or workarounds for this. The ability to start an effect when the view appears and not just the first time is critical.

[mbrandonw]

Hi @wshamp, I recommend you file a bug with Apple so that they are aware of the problem.