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?)

@helge @samdeane @ameahim @dimsumthinking

My talk from Pragma Conf last year has some details! https://www.amyworrall.com/videos/v/pragma-conference-2024-codegen-driven-development

TLDR is, I'm using CG-SQL (or more accurately, Rico Mariani's “Author's Cut" fork: https://ricomariani.github.io/CG-SQL-author/ )

It essentially adds stored procedures and type safety to SQLite, compiles you C entry points to your stored procs, and spits out a JSON file with a bunch of metadata about each one. I take the JSON and build Swift structs and wrappers.

@helge @samdeane @ameahim @dimsumthinking Lighter is on my list of resources, but until now I didn't know it was you!

I've got a slightly different slant; I have the Swift code able to call stored procs, and have a struct to hold the 'row’ type for each proc's output (including parent/child joins for nested stuff), but I treat the actual table structure of the db as a black box to Swift -- the Swift code only talks via the stored procedures, forcing all my business logic into sql.