`Store.ifLet(then:else:)` migration: `observe` re-fires on child state mutations

[renatorodrigues]

Description

Store.ifLet(then:else:) was deprecated in TCA 1.24.0 in favor of Observation-based tooling. The two APIs have fundamentally different semantics that make a direct migration non-trivial, even when both parent and child states adopt @ObservableState.

ifLet(then:else:) fires only when the optional transitions between nil and non-nil. Internal mutations to the child state do not re-fire the then closure.

The observe { if let store = store.scope(...) } replacement fires whenever the optional's value changes, including internal child state mutations.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

After the nil → non-nil transition, subsequent child state mutations should not re-enter the observe block. The behavior should match ifLet(then:else:).

Actual behavior

The observe block re-fires on every child state mutation while the optional remains non-nil. In a UIKit context, this means view creation code executes multiple times, resulting in duplicate views or view controllers being added to the hierarchy.

Reproducing project

// First tap: nil → non-nil
observe: called ✅

// Second tap: child state mutation (title updated, feedback still non-nil)
observe: called ❌ → duplicate view added to stack

Preview

if-let-store.mp4.mp4

Xcode Project

→ https://github.com/renatorodrigues/if-let-store

The Composable Architecture version information

1.24.1

Destination operating system

iOS 26.2 / iOS 18.2

Xcode version information

26.2.0

Swift Compiler version information

swift-driver version: 1.127.14.1 Apple Swift version 6.2.3 (swiftlang-6.2.3.3.21 clang-1700.6.3.2)
Target: arm64-apple-macosx26.0

[renatorodrigues]

@stephencelis I did some more digging into this and I think I found the actual trigger.

In my repro, I have a parent observation like this:

observe { [weak self] in
    guard let self else { return }

    if let store = store.scope(state: \.feedback, action: \.feedback) {
        let feedback = FeedbackView(store: store)
        stackView.addArrangedSubview(feedback)
    }
}

After digging further, I found that this only happens because FeedbackView sets up its own observation during initialization:

final class FeedbackView: UIView {
    init(store: StoreOf<Feedback>) {
        self.store = store
        super.init(frame: .zero)

        setUpView()
        setUpObservers()
    }

    private func setUpObservers() {
        observe { [weak self] in
            // ...
        }
    }
}

If I defer the child observation setup, the issue disappears and everything behaves as expected:

final class FeedbackView: UIView {
    init(store: StoreOf<Feedback>) {
        self.store = store
        super.init(frame: .zero)

        setUpView()
        DispatchQueue.main.async {
            self.setUpObservers()
        }
    }
}

So at this point my suspicion is that the problem is caused by nested observe calls.

I also validated this against one of the TCA UIKit examples (Load Then Navigate), where a parent view controller observes optional child state and pushes/pops a child view controller:

observe { [weak self] in
    guard let self else { return }

    activityIndicator.isHidden = store.isActivityIndicatorHidden

    if let store = store.scope(state: \.optionalCounter, action: \.optionalCounter) {
        navigationController?.pushViewController(
            CounterViewController(store: store),
            animated: true
        )
    } else {
        navigationController?.popToViewController(self, animated: true)
    }
}

That sample works fine as-is: the if let branch only runs when optionalCounter becomes non-nil.

However, the child CounterViewController in that example sets up its own observation in viewDidLoad, so there is no nested observation during initialization. When I moved that child observe call into the initializer instead, I was able to reproduce the same issue: every time the counter state changes, the parent pushes another CounterViewController.

So this now looks much more specifically related to creating a child view/controller that immediately starts observing inside the same parent observation pass.

[mbrandonw]

This is just generally a sharp edge with how @Observable works and it plagues SwiftUI too. If you construct an @Observable model in the body of a view, and if that model provides a custom initializer to set its properties, then the view observe those "accesses" to the model, even though they aren't really accesses. And that will cause the view to be re-computed when you don't expect, which can also cause the model to be discarded and recreated.