Seeing the same thing on iOS 27.2 (24B119, iPhone 14 Pro) and the iOS 27.2 simulator. The same code works on iOS 26.5. I've filed FB25376507 with a minimal sample project, before and after recordings, and a UI test that fails on 27.2 and passes on 26.5. It's likely a duplicate of FB24779236 above. From what I can tell, it only happens when the minimized search is inside a TabView. Without the TabView, minimized search goes to the bottom toolbar and closes normally. A bare NavigationStack + List + .searchable + .searchToolbarBehavior(.minimize) in a tab is enough to reproduce it. What I found with breakpoints and logging: On iOS 27 the close button is a UIBarButtonItem whose action calls -[UISearchController setActive:NO] directly. SwiftUI's internal SwiftUISearchController receives willDismissSearchController: but never updates its state, so the isPresented binding and isSearching stay true. On the next toolbar update, SwiftUI queues isActive = true (enqueueIsActiveUpdate → flushPendingIsActive), which reopens search as soon as the dismiss animation finishes. On iOS 26.5 the same tap goes through the search bar's cancel path, with no setActive: call, and the binding goes false as expected. None of these changed anything: isPresented:, .searchFocused, placement: .toolbar, DefaultToolbarItem(kind: .search, placement: .topBarTrailing), .tabViewSearchActivation(.searchTabSelection), .searchPresentationToolbarBehavior(.avoidHidingContent), or moving .searchable onto the NavigationStack.