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.

@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 :)

@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 @dimsumthinking I want to move my business logic and data model layer into its own module/target/package/whatever. But it's such a big job… :(

(I have a bunch of build scripts and codegen in my main app target in order to bridge my SQL stored procedures to compiled typesafe Swift. There's big decisions about what should go where, too -- should I put mutation procs in the data layer but keep view-subscription procs in with the GUI?)