@DTS Engineer Thank you. I was able to symbolicate the crash report with MacSymbolicator and pinpoint the crash site.

I encountered a similar issue. It looks like shadows are part of the glass effects themselves. I set clipToBounds on my UICollectionView to false to avoid clipping the shadows, which made the collectionView look like it had a gray background color.

@Vision Pro Engineer I am also curious as to why the overlay is still covered by the RealityView, now that the RealityView contains only a plane of 0 "thickness" and the overlay is applied above the RealityView on the ZStack.

@Vision Pro Engineer Thanks for your response. Yes - I figured to add a corner radius to the entity itself, although I used the generatePlane(width: Float, height: Float, cornerRadius: Float = 0) API which seemed to generate a plane along the X-Y plane and eliminated the need to set the transform. I would also like to add a SwiftUI overlay to the RealityView to display additional information over the image. What's a recommended approach to do this? This has the same problem as the clipShape modifier where the overlay is applied as a 2D view at the "back" of the RealityView and thus isn't visible. One approach I can think of is to put the overlay at the frontmost of the ZStack that contains the RealityView. The ZStack's depth should just be the same (or just a bit more) than the max z scale of the RealityView. However, I am unsure about the best way to calculate this depth value. Can you provide some guidance on this? Thanks!

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.