
Core Data
Ship reliable on-device persistence in a Swift iOS app with correct migrations, concurrency, and multi-target sync before App Store release.
Install
npx skills add https://github.com/dpearson2699/swift-ios-skills --skill core-dataWhat is this skill?
- Triage decision tree for SQLite Core Data vs SwiftData vs UserDefaults vs file storage before you commit to a stack
- Covers lightweight, custom NSMappingModel, and iOS 17+ staged migration with checksum-based NSManagedObjectModelReferenc
- Documents thread confinement, viewContext vs background context queues, and async perform/performAndWait patterns for iO
- 25 named pitfalls including inverse relationship cardinality, unique constraints on CloudKit, and detached-task object p
- Four-phase performance protocol: baseline measurement, instrumentation, targeted fixes, and re-measurement after every c
Adoption & trust: 679 installs on skills.sh; 713 GitHub stars; 3/3 security scanners passed (skills.sh audits).
Recommended Skills
Vercel React Native Skillsvercel-labs/agent-skills
Firebase Basicsfirebase/agent-skills
Building Native Uiexpo/skills
Firebase Ai Logic Basicsfirebase/agent-skills
Native Data Fetchingexpo/skills
Firebase Firestorefirebase/agent-skills
Journey fit
Primary fit
Core Data is implemented while building the product’s local data layer—after validation and before ship-time hardening. Persistence models, stores, contexts, and CloudKit wiring are backend concerns even when they feed SwiftUI views.
Common Questions / FAQ
Is Core Data safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Core Data
{ "skill_name": "core-data", "evals": [ { "id": 1, "prompt": "Review this Core Data staged migration plan for an iOS 26 app: the team creates NSLightweightMigrationStage([\"ModelV1\", \"ModelV2\"]), constructs NSManagedObjectModelReference(named: \"ModelV2\", in: .main), and expects NSStagedMigrationManager to run without wiring it into the persistent store description. Give concise corrected guidance with Swift where useful.", "expected_output": "A review that corrects staged migration checksum usage, NSManagedObjectModelReference initializer requirements, and store-description wiring.", "files": [], "assertions": [ "States that NSLightweightMigrationStage takes version checksums, not human-readable model names.", "Uses NSManagedObjectModelReference(name:in:versionChecksum:) or an equivalent initializer with a versionChecksum.", "Includes source and destination model references for an NSCustomMigrationStage.", "Shows or describes setting NSPersistentStoreStagedMigrationManagerOptionKey before loading the persistent stores." ] }, { "id": 2, "prompt": "Review this Core Data multi-target sync plan: a widget and app share a SQLite store, batch inserts and deletes run on background contexts, the viewContext never merges SQL-level changes, no persistent history token is stored, and objects are passed directly to detached tasks. Explain what to fix.", "expected_output": "A review that fixes batch-operation merging, persistent history tracking, token storage, and object/thread boundaries.", "files": [], "assertions": [ "Explains that batch inserts, updates, and deletes bypass normal managed-object context change tracking and must be merged or consumed through persistent history.", "Recommends enabling NSPersistentHistoryTrackingKey for multi-target or multi-process stores.", "Recommends observing NSPersistentStoreRemoteChange notifications when remote-change delivery is needed.", "States that each target or consumer should persist its own persistent history token.", "States that NSManagedObject instances must not cross context or thread boundaries; pass NSManagedObjectID and re-fetch.", "Mentions that batch delete bypasses validation beyond basic delete rules and is incompatible with the Deny delete rule." ] }, { "id": 3, "prompt": "A team asks for a Core Data plan, but the real request is to run Core Data and SwiftData side by side against the same existing SQLite store and then migrate new screens to @Model. How should the agent route the work and what high-level boundary guidance should it give?", "expected_output": "A boundary answer that identifies Core Data + SwiftData coexistence/migration as SwiftData-owned while giving only high-level handoff guidance.", "files": [], "assertions": [ "States that Core Data + SwiftData coexistence or migration should use the swiftdata skill.", "Avoids turning the Core Data skill into a full SwiftData migration guide.", "Gives high-level boundary guidance such as matching store URL, entity names, property names, and schema.", "Mentions using @Attribute(originalName:) or equivalent rename mapping for renamed properties.", "Preserves standalone Core Data guidance for apps that have not adopted SwiftData." ] } ] } --- name: core-data description: "Build, review, or improve Core Data persistence in apps that have not adopted SwiftData. Use when working with NSManagedObject subclasses, NSFetchedResultsController for list-driven UI, NSBatchInsertRequest / NSBatchDeleteRequest / NSBatchUpdateRequest for bulk operations, NSPersistentHistoryChangeRequest for persistent history tracking and multi-target sync, NSStagedMigrationManager for staged schema migrations (iOS 17+), NSCompositeAttributeDescription for composite attributes (iOS 17+), or when i