Never mind - it was due to me putting device anchor matrix in my view model, thus causing the observing SwiftUI view to excessivly refresh.

We have a similar issue but with AVAudioPlayer. Dismissing then reopening immersive space / window causes the audio to stop, and attempting to call play() again has no effect.

I cannot reproduce the Data error you are seeing. However, Xcode is complaining Argument passed to call that takes no arguments on your PhotosPicker( selection: $selectedItems, selectionBehavior: .ordered, matching: .images ) { Text("image!") } code. That is because you named your struct PhotosPicker as well, which is confusing the compiler.

You certainly can navigate to DetailsScreen simultaneously on multiple navigation stacks. Each DetailsScreen would then be a separate instance. Did you run into any actual issue, or is this a conceptual question?

@Vision Pro Engineer Hey Sydney, Thanks for responding. I tried the advised approach, but discovered that the flickering issue happens on the inner tab's Swift Chart view. Specifically: On Xcode 15.4, setting the inner tab's tint color to a non-nil color behaves normally. However, setting it to .tint(nil) causes the chart to randomly switch between the default blue tint and the outer TabView's tint (in the above example, red color). On Xcode 16.0 betas, even setting the inner tab's tint to an explicit color causes flickering. In the above example, the chart would randomly switch between red and green. I have filed feedback FB14694434.

@Vision Pro Engineer Thanks for clarifying. Regarding the original question - is there any other way to customize the tab bar's foreground tint color in SwiftUI, if this modifier is unavailable on iOS?

@DTS Engineer Thanks for the response. I could use .listStyle(.plain), but I'd still like to maintain the inset grouped style for other rows. I think there is no way to mix-and-match plain and inset grouped styles in the same list? As I have mentioned, the offset approach seems to cause bad scrolling performance. Any idea why that is?

@DTS Engineer Hi Paris, Thanks for following up. I was still able to reproduce this behavior on iOS 18 beta 4 (22A5316k). I have commented on the feedback report.

@DTS Engineer Thanks for your respsonse. I have filed feedback FB14508189. I was able to find a workaround by creating the background context as a child to the view context, in contrast to as a standalone context. I would then perform operations on this child context, save it, then save the view context. This seems to avoid the crash. Can you comment on the performance difference between this approach and saving on a standalone background context then wait for the system to auto merge changes to the view context?

Submitted TSI case ID 8425387

I have submitted FB14464408.

Have you tried .ignoresSafeArea(.keyboard)?

@DTS Engineer Thank you for the example. In my app, TabView is the root view, and NavigationStack is nested within each Tab. I changed the provided example to match the structure of my app, and found that the animation issue was still present. Is this expected behavior? struct ContentView: View { @State private var isEditing = false var body: some View { TabView { Tab("Received", systemImage: "tray.and.arrow.down.fill") { NavigationStack { Button("toogle") { isEditing.toggle() } .toolbar(isEditing ? .hidden : .visible, for: .tabBar) .toolbar(isEditing ? .visible : .hidden, for: .bottomBar) .animation(.easeIn, value: isEditing) .toolbar { ToolbarItem(placement: .bottomBar) { Text("hello world") } } } } .badge(2) Tab("Sent", systemImage: "tray.and.arrow.up.fill") { Color.blue } Tab("Account", systemImage: "person.crop.circle.fill") { Color.green } .badge("!") } } }

I have resubmitted feedback FB13965455