I believe the problem is in the fact that the navigator object, which is an ObservableObject, contains an array items, which are also ObservableObjects. This is nesting ObservableObjects inside ObservableObjects. The $ references the outer ObservableObject, but there isn't a way to reference the nested ObservableObject. The code that works grabs the inner ObservableObject, an item, and then can pass it as the new view which expects the ObservableObject.

Same problem here. I spent lots of time updating to NavigationStack, and now my published app is completely broken for iOS 16.4. Just beginning to dig into it.

@Gong I add items to the existing sections. When they tap the item at the top of the section, that section expands with additional items. I want the section to scroll to top. But because of this bug, one you expand and scroll to a section, then try to expand and scroll to another section that comes after the first one expanded, the app crashes. To mitigate the crash, I give the list a view Id, which, for iOS 16, is based on the expanded section. Now when the expandedItemId changes, the whole list reloads and the scroll happens without crashing! It's not perfect, but it gets the item to the top without crashing. Now, when I tap the item again to collapse it, when the list reloads, it is positioned at the top of the list. That's why I added the scrolledToTopItemId. I set it when the item was expanded and the list scrolled to that item. Now when the item is collapsed, and the view is refreshed (because of the list view id), I can scroll to the previously selected item so that the list maintains its context. I'm open for betters ideas. This isn't perfect, but so far its as good as I've been able to come up with @State private var expandedItemId: String? @State private var scrolledToTopItemId: String? private var iOS16CrashAvoidingViewId: String { guard #available(iOS 16, *) else { return "-view" } // This prevents a iOS 16 crash when to you expand a key indicator further down the screen from the 1st one you expanded. With this solution, // each key indicator doesn't scroll quite to the top: 1st one does, 2nd a little lower, third one yet lower, etc. But at least it doesn't crash! // Changing the view ID causes the whole to get reloaded when ever the expanded section changes. return "\(expandedItemId ?? "")-view" } var body: some View { ScrollViewReader { scrollView in List { statusSection(title: "not_submitted".localized, items: agent.initiatedForms) statusSection(title: "pending".localized, items: agent.pendingForms) statusSection(title: "returned".localized, items: agent.rejectedForms) statusSection(title: "success".localized, items: agent.successForms) } .id(iOS16CrashAvoidingViewId) .onChange(of: expandedItemId) { newValue in withAnimation { if let value = newValue { scrollView.scrollTo(value, anchor: .top) scrolledToTopItemId = value } DispatchQueue.main.async { guard scrolledToTopItemId != nil else { return } withAnimation { scrollView.scrollTo(scrolledToTopItemId, anchor: .top) } } } } } .navigationTitle("Submitted Forms") }

I don't add sections to my list, but I do add items to the existing sections. When they tap the item at the top of the section, that section expands with additional items. I want the section to scroll to top. But because of this bug, one you expand and scroll to a section, then try to expand and scroll to another section that comes after the first one expanded, the app crashes. To mitigate the crash, I give the list a view Id, which, for iOS 16, is based on the expanded section. Now when the expandedItemId changes, the whole list reloads and the scroll happens without crashing! It's not perfect, but it gets the item to the top without crashing. Now, when I tap the item again to collapse it, when the list reloads, it is positioned at the top of the list. That's why I added the scrolledToTopItemId. I set it when the item was expanded and the list scrolled to that item. Now when the item is collapsed, and the view is refreshed (because of the list view id), I can scroll to the previously selected item so that the list maintains its context. I'm open for betters ideas. This isn't perfect, but so far its as good as I've been able to come up with @State private var expandedItemId: String? @State private var scrolledToTopItemId: String? private var iOS16CrashAvoidingViewId: String { guard #available(iOS 16, *) else { return "-view" } // This prevents a iOS 16 crash when to you expand a key indicator further down the screen from the 1st one you expanded. With this solution, // each key indicator doesn't scroll quite to the top: 1st one does, 2nd a little lower, third one yet lower, etc. But at least it doesn't crash! // Changing the view ID causes the whole to get reloaded when ever the expanded section changes. return "\(expandedItemId ?? "")-view" } var body: some View { ScrollViewReader { scrollView in List { statusSection(title: "not_submitted".localized, items: agent.initiatedForms) statusSection(title: "pending".localized, items: agent.pendingForms) statusSection(title: "returned".localized, items: agent.rejectedForms) statusSection(title: "success".localized, items: agent.successForms) } .id(iOS16CrashAvoidingViewId) .onChange(of: expandedItemId) { newValue in withAnimation { if let value = newValue { scrollView.scrollTo(value, anchor: .top) scrolledToTopItemId = value } DispatchQueue.main.async { guard scrolledToTopItemId != nil else { return } withAnimation { scrollView.scrollTo(scrolledToTopItemId, anchor: .top) } } } } } .navigationTitle("Submitted Forms") }

Any resolution to this? I'm getting this crash too. My code seemed to work fine until I built with Xcode 14.0 (release), although I'm not sure that Xcode 14 the determining factor.