Seems to be related to DocumentGroupLaunchScene. If I take that scene out entirely of their demo app, and just leave the DocumentGroup scene, the issue doesn't present. Happens in both iPhone and iPad simulators. I see a lot of console log noise with NSLayoutConstraint warnings. That seems like a hint here. Apple needs to issue a fix it seems. Xcode 16.1 / iOS 18.1

This appears fixed in the Xcode 16 GM. Anecdotally, I can no longer reproduce the issue now with it. The issue had been moved to Resolved Issues in the release notes: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes#Foundation

It appears the preview titlebar rendering may be incorrect / buggy. As a test, I put a rectangle in the inspector and it is consistent with the runtime behavior of filling only the under-titlebar area. It just seems like the preview is incorrectly rendering the titlebar as full-height, but the preview is not actually a full-height inspector. struct ContentView: View { var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .padding() .toolbar { Text("test") } .inspector(isPresented: .constant(true)) { Rectangle().fill(.red) } } } Preview: Runtime:

I can reproduce this. Issue only occurs on-device with iOS 17 beta 6. Works fine in a simulator. I believe it's an internal bug in AVAssetExportSession. I've submitted a radar to Apple (FB12986599) with detailed info and an example Xcode project to reproduce the issue.

Same issue here. After trying everyone's suggestions from this thread and coming up dry, I finally narrowed down the needle-in-a-haystack. In my case it was a Swift Package. Debug builds built fine, but Release builds (with optimizations) caused the Swift compiler to crash with the same stack trace and error: Abort trap: 6 as others have mentioned. The culprit? A single missing import statement in one of the package's .swift files. To elaborate the particulars: PackageA (crashed compiler) has PackageB as a dependency, which in turn has PackageC as a dependency. All three packages show up in the dependency pool of course. PackageA was accessing methods from PackageC without actually using an import PackageC statement (possibly by way of PackageB exporting types from PackageC in some of its interfaces). The missing import statement was forgotten because compilation succeeded in Debug builds and development and testing was only ever done in a Debug build. It wasn't until production Release builds of an application that imported PackageA that the compiler crash mysteriously cropped up with very little context.

From the swift.org forums, this solution was presented: Inside of PackageA, replace all import PackageB with @_implementationOnly import PackageB There may be some side-effects, but so far it has worked exactly as desired in several different scenarios.