Preview and run real windows

Xcode previews render one view without launching the app. For layout work they cut the feedback loop from a full launch to about a second.

#Preview("Empty") {
  ContentView()
    .environmentObject(NotesModel())
    .frame(width: 700, height: 450)
}

The frame matters on macOS. Without it the preview picks an arbitrary size, and you end up judging a Mac window layout in a phone-shaped canvas.

Add a second preview for realistic content. The trick is a model preloaded with data:

#Preview("With notes") {
  let model = NotesModel()
  model.notes = [
    Note(id: UUID(), title: "Groceries", body: "Milk, eggs, coffee"),
    Note(id: UUID(), title: "Ideas", body: "A long body to check how text wraps in the detail area"),
  ]
  return ContentView()
    .environmentObject(model)
    .frame(width: 700, height: 450)
}

Build a small library of these: empty, populated, one note with a very long title, and a dark mode variant with .preferredColorScheme(.dark). Each preview encodes an assumption about your layout. When one breaks, you find out immediately instead of during a demo.

Then run the actual app, because previews lie by omission. A preview never opens a real window. It does not run your menu commands, does not restore window frames, does not ask for file permissions, and does not load persisted state. Cmd+R exercises all of that.

While the app is running, do a short manual pass. Resize the window down to its smallest useful size and watch what truncates. Open a second window with Cmd+N and change a note — both windows should update, because they share one model. Tab through the controls to check keyboard focus.

The mistake here is treating a green preview as proof the app works. I have seen a layout look perfect in previews and clip its toolbar in a real window, because the preview frame was taller than the window’s restored size. Previews are one tool for one view. The running app is the truth.