The repository's Reading List sample persists JSON, not SwiftData. Use it to study the persistence contract, then treat a SwiftData implementation as a separate storage adapter with its own tests.
- 1View model
- 2Store protocol
- 3SwiftData adapter
- 4Relaunch verification
Work through the example
Test create, edit, delete and reopen against a temporary store. Inject storage rather than letting previews access production data.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
@Model Macro and Schema Definition
import SwiftData
@Model
class Task {
var id: UUID
var title: String
var notes: String
var isCompleted: Bool
var priority: Int
var createdAt: Date
var dueDate: Date?
// Relationship
var category: Category?
var tags: [Tag]
// Transient (not persisted)
@Transient var isSelected = false
// Unique constraint
#Unique<Task>([\.id])
init(title: String, priority: Int = 0) {
self.id = UUID()
self.title = title
self.notes = ""
self.isCompleted = false
self.priority = priority
self.createdAt = Date()
self.tags = []
}
}
@Model
class Category {
var id: UUID
var name: String
var color: String
// Inverse relationship with cascade delete
@Relationship(deleteRule: .cascade, inverse: \Task.category)
var tasks: [Task]
init(name: String, color: String = "blue") {
self.id = UUID()
self.name = name
self.color = color
self.tasks = []
}
}
@Model
class Tag {
var id: UUID
var name: String
@Relationship(inverse: \Task.tags)
var tasks: [Task]
init(name: String) {
self.id = UUID()
self.name = name
self.tasks = []
}
}
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| View model | Confirm the input and environment | Preserve the failure and return to this step |
| Store protocol | Inspect the intermediate artifact | Preserve the failure and return to this step |
| SwiftData adapter | Run the focused check | Preserve the failure and return to this step |
| Relaunch verification | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
The Reading List acceptance suite does not verify a SwiftData migration.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- Five checks for an AI-built SwiftUI app
Use persistence, search and accessible states to make “it works” a testable claim.
- SwiftUI: review state transitions before polishing the screen
Make loading, empty, success and error states part of the implementation brief.
What to do next
Next: Search, filtering and empty states that pass accessibility review