Thanks Quinn for your answer. Everything makes sense now and we are relieved that you confirmed that the arguments evaluation is done in the logging call thread.

I've just run into this issue and I can confirm that the memory leak does not occur on iPhone (iOS 18.7.1 and iOS 26) even when using UITabs occurs on iPad (iOS 18.7.1) only when using UITabs. It does not occur when setting the tab bar controller children the old way (setViewControllers(:animated:)). A work around is to use a custom TabBarController inheriting from UITabBarController and override viewDidDisappear(:) as follows: override func viewDidDisappear(_ animated: Bool) { super.viewDidDisappear(animated) // HACK: clear the tabs property to prevent memory leaks when using UITabs if #available(iOS 18, *) { setTabs([], animated: false) } } It effectively triggers the children view controllers deinit. App build with Xcode 26.2 on macOS 26.2.

Moff, I confirm that on my side the unreleased reference also comes from _UIFloatingTabBarItemView. Richard, as to why my hack didn't work for Moff, it is definitely related to the version of iPadOS. iPadOS 18.7.1 (physical iPad): there is an additional unreleased reference to the tab bar view controller from a _UIFloatingTabBarItemCell. However my hack works. iPadOS 26.2 (simulator): there's only one reference from a _UIFloatingTabBarItemView, exactly as you described (same memory graph as yours). And indeed my hack doesn't work I hope the issue will be fixed for both versions of iPadOS. Please keep us posted here.