Post

Replies

Boosts

Views

Activity

Reply to TabView auto-dismisses fullScreenCover after tab list changes (crash with .zoom animation)
@Pokpong Thanks for the reply! Moving the presentation above the TabView is exactly what we validated as the long-term fix: with a single fullScreenCover owned by the parent and the selected item lifted out of the tabs, none of the triggers reproduce in a lab with our production hierarchy, and the zoom still animates from the tapped cell using the tab’s namespace. We shipped the .id and ZStack workarounds first because they’re one-line. Lifting the cover is an architectural change for us: today each tab embeds a reusable grid component that owns its own presentation (view model, zoom namespace, present/dismiss callbacks), so the parent would have to take over that ownership, consolidate the per-tab state into one, and coordinate with the sheets it already presents. That’s the follow-up. Agreed that these are two separate reports, one per framework. FB25287840 covers the SwiftUI side: the page-style TabView dismisses a fullScreenCover on its own after its tabs change, with the item binding never set to nil. I’m filing a second one for UIKit: dismiss(animated:) during a queued zoom presentation asserts with “Cannot morph from a view that is not in the hierarchy” instead of falling back, reproducible with five public-API calls and no SwiftUI. I’ll cross-reference them.
Topic: UI Frameworks SubTopic: SwiftUI
20h
Reply to TabView auto-dismisses fullScreenCover after tab list changes (crash with .zoom animation)
@Pokpong Thanks for the reply! Moving the presentation above the TabView is exactly what we validated as the long-term fix: with a single fullScreenCover owned by the parent and the selected item lifted out of the tabs, none of the triggers reproduce in a lab with our production hierarchy, and the zoom still animates from the tapped cell using the tab’s namespace. We shipped the .id and ZStack workarounds first because they’re one-line. Lifting the cover is an architectural change for us: today each tab embeds a reusable grid component that owns its own presentation (view model, zoom namespace, present/dismiss callbacks), so the parent would have to take over that ownership, consolidate the per-tab state into one, and coordinate with the sheets it already presents. That’s the follow-up. Agreed that these are two separate reports, one per framework. FB25287840 covers the SwiftUI side: the page-style TabView dismisses a fullScreenCover on its own after its tabs change, with the item binding never set to nil. I’m filing a second one for UIKit: dismiss(animated:) during a queued zoom presentation asserts with “Cannot morph from a view that is not in the hierarchy” instead of falling back, reproducible with five public-API calls and no SwiftUI. I’ll cross-reference them.
Topic: UI Frameworks SubTopic: SwiftUI
Replies
Boosts
Views
Activity
20h