Diagnose SwiftData edits that appear but are not saved

Understand the likely causes

• Tracked model changes can exist only in memory until the context writes them. The view may use an unintended container or storage configuration.
• A context can contain several workflows’ pending changes. Schema mismatch, unsupported migration, or swallowed save errors can be hidden by a UI that reads the same in-memory object.

Record the actual persistence scope

Identify which ModelContainer defines the schema, whether its configuration is in-memory or persistent, and which context the view receives from the environment. Confirm the intended container is attached at the correct hierarchy scope rather than assuming a context lookup proves persistence is configured. Use synthetic identifiers and safe configuration labels in diagnostics. Do not delete or recreate a real store to make a fetch appear clean. A container mismatch and a failed save have different causes, and changing both at once can destroy the original reproduction.

Observe save acceptance instead of only visible mutation

A changed property can update the interface before persistence succeeds. Define the event at which the product announces saved, then observe the explicit save result or the documented autosave policy needed by that workflow. The fragment shows an acceptance boundary on a supplied context; it does not create a database. Let errors reach an owner that can preserve the draft and offer recovery. A try? that discards the save error can make the exact symptom invisible while the interface continues to read unsaved state.

import SwiftData
@MainActor
func confirmPendingSave(_ context: ModelContext) throws {
    guard context.hasChanges else { return }
    try context.save()
}

A save error propagates instead of being converted to confirmed success.

Keep draft cancellation narrower than shared rollback

Inspect whether Cancel calls rollback on a context that also holds edits from another screen. That operation can discard more than the editor intended. Prefer a separate value draft with an explicit commit, or a deliberately scoped persistence transaction design appropriate to the model relationships. Verify the cancellation path with two unrelated pending edits, not only one form. Context-managed models should not be moved freely across actor or context boundaries; pass stable identities or immutable snapshots and resolve them under the intended receiving scope. Do not suppress concurrency diagnostics with unchecked transfer assertions.

Treat schema evolution as recovery work

If the failure begins after a model change, preserve the failing fixture and compare supported schema versions and migration configuration. Distinguish a malformed portable draft from a persistent-store migration failure. A pure envelope migration can be tested without SwiftData, while an isolated in-memory container tests only part of the persistence path. Valuable user work deserves a reviewed recovery policy instead of unconditional store deletion. Keep old-version synthetic fixtures so a future change can prove it preserves meaning, accepted invariants, and relationships rather than merely avoiding an exception.

Keep it from recurring

• Document model/container/context ownership and the product’s save confirmation boundary. Keep cancellation scoped, retain supported schema fixtures, and report in-memory tests separately from persistent restart checks.