I mean... I wouldn't mind... but the preview in this case is:

#Preview {
Text(“test”)
}

For what it's worth, the solution I found - and which often works for me - was to move the views into a package.

Selecting the auto-generated scheme for the package and viewing the preview that way works a lot more reliably than with the app scheme.

This is quite a big commitment, since anything that the views rely on also have to move into a package, but luckily I tend to factor my code that way anyway, and I was in the process of moving my views across.

@samdeane for me what they depend on doesn’t have to move into the package but do have to be visible from the package.

@dimsumthinking yeah 👍.

I've always tended to structure my app projects fairly similarly to @ameahim's ExtremePackaging layout, and so having all my views in a package, and model or other stuff in dependant packages, all comes quite naturally.

I like being able to build and test as much as I can without needing XCode, but making previews more stable is another helpful benefit.

I’d been a bit sloppy with this app and left a lot in the main project, so I’m now paying down some debt :)

@samdeane @dimsumthinking Always nice to meet another ExtremePackaging believer. The preview stability benefit is real — turns out giving Xcode less to think about helps it actually do its job. Good luck with the migration — the other side is worth it.

@ameahim @dimsumthinking 👍👍👋

I’ve been organising my projects that way for a few years - or approximations thereof anyway 🙂. I like that you’ve formalised it though.

In the early days of Swift/SwiftUI, XCode could get a bit confused, but it’s generally better now.

On a good day.
Downhill, with a following wind…

@samdeane @ameahim it paid off big for me during the swift 6 transition. I could do it package by package. Also it’s made introducing other platforms (car play, tvOS, watchOS, app intents , widgets…) or removing them much easier