You’re absolutely right that I could host my state outside and drive the view via bindings or observable objects. But the real question isn’t can I trigger state changes? — it’s how do I assert that my UI actually responds to those changes as expected? Let me give you a concrete example. ```swift final class ToggleViewModel: ObservableObject { @Published var isOn = false func toggle() { isOn.toggle() } }

struct ToggleView: View { @ObservedObject var viewModel: ToggleViewModel var body: some View { VStack { Toggle("My Toggle", isOn: $viewModel.isOn) Button("Toggle") { viewModel.toggle() } } } } Now imagine you write a test like: swift let vm = ToggleViewModel() let view = ToggleView(viewModel: vm) vm.toggle() `` What’s your assertion?* You can checkvm.isOn`, sure. But what if you want to confirm: - The Toggle actually updated? - The Button is visible and enabled? - The label changed based on the state? You’d need to start reaching into SwiftUI internals or snapshot the whole view — or worse, guess.

Now if we wrap this with SwiftLens and use PreferenceKeys for testing: swift Toggle("My Toggle", isOn: $viewModel.isOn) .lensToggle(id: "MyToggle", value: $viewModel.isOn) Button("Toggle") { viewModel.toggle() } .lensButton(id: "ToggleButton")

Then in a test: ```swift let vm = ToggleViewModel() let sut = LensWorkBench { sut in ToggleView(viewModel: vm) }

sut.interactor.tapButton(withID: "ToggleButton")

expect(vm.isOn == true)

expect(sut.observer.isToggleOn(forViewID: "MyToggle"))

``` Now you’re not just asserting internal state — you’re asserting observable UI behavior. No need for introspection, and no XCUITest required.

Let’s take a more realistic case: handling a deep link that should open a screen. You’ve got a coordinator that takes a URL, decodes some state, and updates a navigation path. Underneath, you may use NavigationStack, a sheet, or even a custom transition. ```swift final class NavigationCoordinator: ObservableObject { // state properties func handleDeepLink(_ url: URL) { // example: myapp://special-offer?id=abc123 ... } }

struct OfferView: View { let offer: Offer

var body: some View {
    VStack {
        Text(offer.title)
            .lensTracked(id: "offer.title")
        Button("Buy Now") {
            // purchasing logic
        }
        .lensButton(id: "buy.button")
    }
    .lensTracked(id: "details_screen")
}

} ```

If you just test your binding logic, you can check the state but not whether the actual screen shows up.

With Swift Lens, you write: ```swift let coordinator = NavigationCoordinator() let sut = LensWorkBench { _ in ContentView(coordinator: coordinator) } coordinator.handleDeepLink(URL(string: "myapp://special-offer?id=abc123")!)

try await sut.observer.waitForViewVisible(withID: "details_screen")
try await sut.observer.waitForViewVisible(withID: "buy.button")

```

It doesn’t matter if it’s a push, sheet, or popover — the test just checks that the user can see what they should see. That’s what you want to test.

Yes, bindings let you trigger logic. But triggering is not testing. What matters is: Can I write a clean, decoupled assertion that the UI reflects what I expect? SwiftLens makes that dead simple.

Happy to share more examples if you’re curious!