13.6 · Crashes mid-write, integrity, backups and data protection

The app can be killed at any instruction. Persistence is only correct if every write leaves the data valid whenever it stops.

Mental model. Assume power loss between any two lines. Make each change either fully applied or not at all, and never trust what you read back.

Survival

Atomic writes, journaling, backups and file protection.

1. How do you protect data from crashes mid-write, corruption and backups: atomic writes, journaling, exclusion from backup and data protection? 13.6.1 · L5
   A write that is interrupted halfway leaves a torn file: part new, part old, often unreadable. The universal fix is write somewhere else, then swap. For files…

More in Persistence & data

• 13.1 · Where data belongs, and the Keychain
• 13.2 · SQLite fundamentals: transactions, WAL, constraints, indexes and migrations
• 13.3 · The Core Data stack, contexts and faults, concurrency, and migrations
• 13.4 · SwiftData: models, contexts, predicates, actors and schema evolution
• 13.5 · The repository pattern and cache design
• 13.7 · Syncing data across devices: conflicts, tombstones and CloudKit
• 13.8 · UserDefaults surprises and FileManager essentials
• 13.9 · Reading query plans, typing and NULL, WAL locking, savepoints and full-text search
• 13.10 · Merge conflicts, faults and batch requests, delete rules, and the SwiftData context
• 13.11 · Keychain status codes, detecting corruption, an LRU cache and library trade-offs