ios-core-data-architect

iOS Core Data architect for persistent storage, CloudKit sync, schema migrations, and SwiftData migration. Activate on: Core Data, NSManagedObject, CloudKit sync, Core Data migration, NSFetchedResultsController, NSPersistentContainer, SwiftData migration path. NOT for: SwiftUI state management (use swiftui-data-flow-expert), server databases (use data-pipeline-engineer), SQLite direct (use mobile-offline-sync-architect).

Jump to install

Repository: curiositech/windags-skills
Last source activity: March 25, 2026 at 05:03
Detected SKILL.md language: English
Stars: 10
Forks: 2

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

license	Apache-2.0
name	ios-core-data-architect
description	iOS Core Data architect for persistent storage, CloudKit sync, schema migrations, and SwiftData migration. Activate on: Core Data, NSManagedObject, CloudKit sync, Core Data migration, NSFetchedResultsController, NSPersistentContainer, SwiftData migration path. NOT for: SwiftUI state management (use swiftui-data-flow-expert), server databases (use data-pipeline-engineer), SQLite direct (use mobile-offline-sync-architect).
allowed-tools	Read,Write,Edit,Bash(swift:,xcodebuild:)
category	Mobile Development
tags	["core-data","ios","cloudkit","persistence"]
pairs-with	[{"skill":"swiftui-data-flow-expert","reason":"SwiftUI views consume Core Data/SwiftData models"},{"skill":"mobile-offline-sync-architect","reason":"Core Data + CloudKit is an offline sync solution"}]

iOS Core Data Architect

Expert in Core Data persistence, CloudKit synchronization, schema migrations, and migration paths to SwiftData.

Activation Triggers

Activate on: "Core Data", "NSManagedObject", "CloudKit sync", "Core Data migration", "NSFetchedResultsController", "NSPersistentContainer", "SwiftData migration", "lightweight migration", "Core Data performance"

NOT for: SwiftUI state management → swiftui-data-flow-expert | Server databases → data-pipeline-engineer | SQLite direct → mobile-offline-sync-architect

Quick Start

Assess project state — new project? Use SwiftData. Existing Core Data? Evaluate migration vs coexistence.
Design data model — entities, relationships, fetch indexes in the .xcdatamodeld editor
Configure persistent container — NSPersistentCloudKitContainer for CloudKit sync, NSPersistentContainer for local-only
Implement migration plan — lightweight (automatic) or heavyweight (mapping model) depending on schema changes
Optimize fetching — batch size, prefetching, background contexts for heavy operations

Core Capabilities

Domain	Technologies
Persistence	NSPersistentContainer, NSManagedObjectContext, WAL mode
CloudKit	NSPersistentCloudKitContainer, CKRecord zone, conflict resolution
Migrations	Lightweight migration, mapping models, progressive migration
Performance	NSBatchInsertRequest, NSBatchDeleteRequest, faulting, prefetch
SwiftData	Coexistence with Core Data, migration path, @Model from NSManagedObject

Architecture Patterns

Core Data Stack Setup with CloudKit

class PersistenceController {
    static let shared = PersistenceController()

    let container: NSPersistentCloudKitContainer

    (:   ) {
        container  (name: )

          description  container.persistentStoreDescriptions.first  {
            ()
        }

         inMemory {
            description.url  (fileURLWithPath: )
        }

        
        description.cloudKitContainerOptions  (
            containerIdentifier: 
        )

        
        description.setOption(  ,
            forKey: )

        
        description.setOption(  ,
            forKey: )

        container.loadPersistentStores { , error 
              error { () }
        }

        container.viewContext.automaticallyMergesChangesFromParent  
        container.viewContext.mergePolicy  
    }

    
     () ->  {
         context  container.newBackgroundContext()
        context.mergePolicy  
         context
    }
}

Version 1 → Version 2 (add optional column):
  └─ Lightweight migration (automatic)

Version 2 → Version 3 (rename attribute):
  └─ Mapping model required (heavyweight)

Version 3 → Version 4 (split entity):
  └─ Custom migration with NSEntityMigrationPolicy

Strategy: Progressive migration chain
  v1 → v2 → v3 → v4 (each step is a known migration)
  NOT: v1 → v4 directly (complex, error-prone)

Code:
  for migration in migrationChain {
    try coordinator.addPersistentStore(
      ofType: NSSQLiteStoreType,
      configurationName: nil,
      at: storeURL,
      options: [NSMigratePersistentStoresAutomaticallyOption: true,
                NSInferMappingModelAutomaticallyOption: migration.isLightweight]
    )
  }

// Phase 1: Core Data and SwiftData side-by-side
// Share the same SQLite store file
let schema = Schema([NewEntity.self])   // SwiftData models
let config = ModelConfiguration(
    url: existingCoreDataStoreURL       // Same store as Core Data
)
let container = try ModelContainer(for: schema, configurations: [config])

// Phase 2: Gradually move entities from Core Data to SwiftData
// - New entities: @Model (SwiftData)
// - Existing entities: NSManagedObject (Core Data)
// - Read from both, write to SwiftData for new data

// Phase 3: Full migration
// - Convert all NSManagedObject subclasses to @Model
// - Remove .xcdatamodeld file
// - Use ModelContainer exclusively

[ ] Persistent container configured correctly (CloudKit or local)
[ ] viewContext used only for reads; background context for writes
[ ] NSBatchInsertRequest used for bulk operations
[ ] Fetch requests have fetchBatchSize set (typically 20-50)
[ ] Migration plan documented for each model version
[ ] Lightweight migration tested between all adjacent versions
[ ] CloudKit sync tested (if applicable) with conflict resolution
[ ] Persistent history tracking enabled
[ ] NSFetchedResultsController used for table/list data sources
[ ] Background context mergePolicy set explicitly
[ ] Unit tests use in-memory store for speed
[ ] SwiftData migration path documented for future transition