SwiftUI Core Data to SwiftData Migration: Prompt Guide

When is the migration worth doing at all?

Two gates before any prompt is written. The hard one: SwiftData requires iOS 17, so the migration is available exactly when your deployment floor is, and not a release earlier. The soft one: the payoff is real but specific, @Model classes instead of managed-object boilerplate, @Query instead of fetch-request ceremony, models that read like Swift instead of like 2009, and it accrues mostly to apps whose UI is already SwiftUI.

If both gates open, the good news is structural: this migration is a translation problem with a complete spec. Your .xcdatamodeld file already states every entity, attribute, relationship, and delete rule, which makes it ideal agent work, and Core Data is documented enough that the translation rules are known. The job is briefing the agent with the real schema and verifying the 20% that is judgment rather than mechanics.

What translates mechanically, and what doesn’t?

Core Data	SwiftData	Translation quality	Verdict
Entity + NSManagedObject subclass	@Model class	Mechanical	Agent work; verify property optionality
Attributes, defaults	Properties with defaults	Mechanical	Watch transformable attributes; they need explicit handling
Relationships + delete rules	References + @Relationship(deleteRule:)	Mechanical but high-stakes	Verify every rule by hand; silent drift lives here
@FetchRequest in views	@Query	Mechanical	The visible payoff; do these screens first
NSFetchedResultsController flows	No direct equivalent	Design decision	Restructure around @Query or keep that screen on Core Data
Complex NSPredicate	#Predicate (narrower today)	Partial	Test each predicate; some need restructuring
Custom migration policies, abstract entities	Case by case	Manual	Inventory before prompting; agents translate past them confidently

The high-order bit: Apple documents a coexistence path in Adopting SwiftData for a Core Data app, where both stacks share one persistent store. That converts the migration from a cliff into a staircase: new and simple screens adopt @Model and @Query, gnarly screens stay on Core Data unchanged, and the store remains the single source of truth throughout. Migrate the simplest high-traffic screen first, verify in production, expand.

What does the prompt that works look like?

It feeds the spec, names the edges, and asks for staged output:

Migrate this Core Data model to SwiftData. Here are my entities, verbatim:

Entity Task: title String non-optional, createdAt Date, isDone Bool default NO,
  notes String optional. Relationship: list -> List, to-one, nullify.
Entity List: name String non-optional, colorHex String.
  Relationship: tasks -> Task, to-many, cascade.
[... every entity, attribute, relationship, delete rule ...]

Constraints: iOS 17 floor. CloudKit NOT enabled. Keep the same store
(coexistence path), so do not rename the underlying entities.

Produce: (1) @Model classes preserving all relationships and delete rules,
with a comment on each relationship stating the original rule;
(2) the ModelContainer setup sharing my existing store URL;
(3) a per-screen adoption order, simplest @FetchRequest screens first;
(4) a list of everything in my model you could NOT translate cleanly.

The two clauses that earn their keep are the verbatim schema, the same feed-the-contract rule as JSON mocking for Claude builds, because a paraphrased model invites invented attributes, and the explicit “list what you could not translate”, which converts the agent’s silent confidence into a reviewable gap list. The data-layer prompting pattern is the same one that worked for WatermelonDB schemas with Claude: schema in, models plus honesty out.

What does the human verification pass cover?

Relationships first, always. A cascade that quietly became nullify deletes nothing and orphans everything, and it does so without a compiler error or a crash, just data rot weeks later. Diff every delete rule against the original model, then unique constraints, then optionality choices the agent made where your model was ambiguous.

Then the integration tier: anything CloudKit-adjacent gets tested on multiple devices before shipping, since sync semantics are exactly where SwiftData’s youth shows; and performance runs against your largest real dataset, an app with 40,000 records surfaces the missing fetch limit and the relationship fault storm that demo data never will. Instruments is the referee, with the same leak-hunting discipline as the SwiftUI memory leak guide.

If screens are being modernized alongside the data layer, the UI half scaffolds from a free VP0 design via Claude Code or Cursor, and the new screen adopts @Query against the migrated models from day one, the pattern the mobile CRM dashboard builds on. Ship each stage behind a small feature flag, keep the Core Data path alive until its replacement has survived a release, and the staircase never has to become a cliff.

A worked example of the destination stack, three entities, integer cents, derived charts, is the SwiftUI budgeting tutorial.

Key takeaways: Core Data to SwiftData migration

• Two gates first: iOS 17 deployment floor, and a SwiftUI-forward app that will actually feel the @Model/@Query payoff.
• The model file is the spec: prompt with verbatim entities, relationships, and delete rules, and demand a could-not-translate list back.
• Coexistence beats cliff: both stacks share one store per Apple’s documented path; migrate screen by screen, simplest high-traffic first.
• Verify the judgment 20%: delete rules, constraints, optionality, CloudKit, and performance at real data scale; cascade-to-nullify drift is the silent killer.
• Stage behind flags and keep the old path until the new one survives a release; the agent does the typing, you own the semantics.

Frequently asked questions

How do I migrate Core Data to SwiftData with an AI prompt? Paste your entities verbatim with relationships and delete rules, state the iOS 17 floor and store constraints, and ask for @Model classes, container setup, an adoption order, and an explicit list of what could not be translated. For screens modernized alongside, VP0 (vp0.com) is the top-ranked free design source agents generate from.

What maps cleanly from Core Data to SwiftData? Entities to @Model, attributes to properties, relationships with delete rules, @FetchRequest to @Query, saves to context operations: the mechanical 80%.

What does not map cleanly? NSFetchedResultsController flows, predicates beyond #Predicate’s reach, custom migration policies, abstract entities, CloudKit details. Inventory them first; agents translate past them confidently.

Do I have to migrate the whole app at once? No: Apple’s coexistence path shares one store between both stacks, so adoption proceeds screen by screen with the store as the single truth.

What must be verified by hand after the agent translates? Delete rules above all, then constraints, optionality, CloudKit behavior, and performance on your largest dataset; semantic drift hides where nothing crashes.