Thanks @sha921. I created a feedback report with id FB13465249 :)

I have the same issue :-(

Same issue here as well on Xcode 16 – no idea how the problem even occurred.

This is still present in iOS 18; tested in Xcode 16 Previews for iOS 18

Filed a bug report: FB15300614

Filed bug report: FB15300701

@DTS Engineer Of course. We chose to have a nested SplitViewController inside a StackController because it allowed us to have an always visible bottom toolbar, even in smaller viewports. These are screenshots from our app (on iPadOS 17.6.1) that is used primarily by bus drivers. This approach has worked great in UX testing, and we would like to be able to continue using format.

Filed bug report: FB15331755

I've noticed that this problem occurs as soon as selectedId gets set a value, then persists even if I remove the selection. This modified example shows that as long as the selected id does not get set, everything works as expected. When you select tap "Option", the selection is set, and my problem occurs as shown in the video above. Even if I remove the selection by tapping "Unselect", the problem still persists. @State var selectedId: String? = nil NavigationSplitView { List(selection: $selectedId) { NavigationLink("Sidebar", value: "test") Button("Unselect") { selectedId = nil } } } detail: { Text("Detail") .toolbar { Button("Button") {} } }

I understand that the buttons inherit their style from the list, but I honestly believe that the default behavior looks really odd; a normal destructive button in a list looks like this: Is there really no other way to have buttons keep their style, without individually setting an explicit .foregroundStyle(…) to color the icons? In my code example above I have the smallest possible example to describe my issue. In our app we rely on Lists – I can't switch to a ScrollView there.

Filed bug report: FB15369138

I am pretty sure this is because adding a new PlaceItem causes a re-render of the view PlaceView (due to the @FetchedResult that looks for PlaceItem), which causes the dynamically added predicate to be "discarded". Unfortunately I do not have a solution to this problem, I just ran into it myself. Let me know if you figured out a work-around for this.