Core Data — vad är det, datamodell och hur det fungerar

Vad är Core Data och dess roll i iOS

Core Data — är ett ramverk för hantering av objektgrafer och persistens som ingår i Cocoa Touch. I motsats till en vanlig missuppfattning är Core Data inte en databas, utan ett lager för objekthantering som kan använda SQLite som en av lagringsmetoderna. Core Datas huvuduppgift är att spåra ändringar i objekt, hantera deras livscykel och synkronisera tillståndet med disken.

Ramverket tillhandahåller en objektgraf där varje Managed Object övervakas av kontexten för ändringar. När kontexten sparas bekräftas alla ändrade, tillagda och borttagna objekt i den permanenta lagringen i en enda transaktion. Detta befriar utvecklaren från att skriva SQL-frågor och hantera transaktioner manuellt.

Enligt statistik från Swift Developer Survey (2025) används Core Data i 52% av iOS-applikationer som arbetar med lokala data. Trots framväxten av moderna alternativ (SwiftData, Realm) förblir Core Data det huvudsakliga ramverket i befintliga Apple-projekt tack vare sin mognad och djupa integration med systemet.

Använd Core Data för projekt med en datamodell av medelhög komplexitet där relationer mellan objekt, ångring av ändringar och automatisk cachning via faulting-mekanismen behövs.

Arkitekturen för Core Data är byggd kring konceptet Managed Object Context — en arbetsyta som spårar alla ändringar i objekt. Kontexten stöder ångring (undo/redo) via den inbyggda NSUndoManager, vilket möjliggör implementering av utkast och annullering av åtgärder utan manuell sparande av tillståndsögonblicksbilder. När save() anropas bekräftar kontexten alla ändringar i en transaktion i den permanenta lagringen, vilket garanterar atomicitet och datakonsistens.

Datamodell: Entity, Attributes, Relationships

Core Datas datamodell definieras i filen .xcdatamodeld — Xcodes visuella redigerare, där alla Entiteter, deras attribut och relationer beskrivs. Vid kompilering serialiseras modellen till .momd och laddas via NSManagedObjectModel.

Entity och Attributes

Entity — är en beskrivning av en datatyp, analogt med en tabell i SQL. Varje Entity innehåller en uppsättning Attributes — namngivna fält med en datatyp (String, Integer, Date, Boolean, Data). Till skillnad från Room kräver Core Data explicit val av typ för varje attribut via modellredigeraren.

Relationships

Relationship — relation mellan Entiteter, analogt med en främmande nyckel i SQL. Core Data stöder alla typer av relationer: en-till-en, en-till-många och många-till-många. För varje relation konfigureras en Delete Rule (Cascade, Nullify, Deny) — beteendet vid borttagning av det relaterade objektet.

Valet av Delete Rule är avgörande för dataintegriteten: Cascade utan kontroll kan ta bort en tredjedel av databasen, och Deny kan blockera operationen med ett obegripligt fel. I produktionskod rekommenderas Nullify med manuell hantering av föräldralösa poster.

I Xcodes modellredigerare kan utvecklaren inte bara ställa in Entity och attribut, utan även constraints (unikhetsbegränsningar), index för att snabba upp frågor och default values för attribut. Alla modelländringar kompileras till .momd-filen, som laddas vid initiering av NSPersistentContainer. Modellversionering (Model Versioning) gör det möjligt att underhålla flera versioner av schemat och utföra migrering mellan dem.

Core Data-stack: PersistentContainer och Context

NSPersistentContainer — ett enhetligt objekt som hanterar Core Data-stacken sedan iOS 10 och macOS 10.12. Det inkapslar NSManagedObjectModel, NSPersistentStoreCoordinator och NSManagedObjectContext, och automatiserar laddning av modell och konfiguration av lagring. För äldre versioner byggdes stacken manuellt, men detta rekommenderas inte nu.

let container = NSPersistentContainer(name: "DataModel")
container.loadPersistentStores { _, error in
    if let error { fatalError("Core Data load failed: \(error)") }
}
let context = container.viewContext

viewContext — huvudkontexten kopplad till huvudtråden. Alla läsningar och UI-uppdateringar utförs genom den. Dataskrivning för prestanda rekommenderas att utföras i en underordnad kontext med privat kö och efterföljande synkronisering.

NSPersistentStoreCoordinator

Koordinatorn NSPersistentStoreCoordinator kopplar modellen till den fysiska lagringen på disken. Core Data stöder flera lagringstyper: SQLite (rekommenderad), Binary och In-Memory. SQLite-lagring stöder migrering, inkrementell säkerhetskopiering och feltolerans under skrivprocessen.

NSFetchRequest och arbete med data

NSFetchRequest — ett objekt som beskriver en fråga till Core Data-lagringen. Det innehåller Entity-namn, filtreringspredikat, sortering och hämtainställningar. Frågan körs via context.fetch(), som returnerar en array av NSManagedObject.

let request = NSFetchRequest<User>(entityName: "User")
request.predicate = NSPredicate(format: "age >= %d", 18)
request.sortDescriptors = [NSSortDescriptor(key: "name", ascending: true)]
request.fetchLimit = 50

let results = try context.fetch(request)

NSPredicate stöder komplexa villkor: LIKE, IN, BETWEEN, CONTAINS[c] (skiftlägesokänslig), SUBQUERY för kapslade frågor på relaterade Entiteter. Core Data stöder också NSFetchedResultsController — en klass för reaktiv dataladdning i UITableView, som automatiskt spårar ändringar och uppdaterar tabellen med animerade sektioner.

Core Data i flertrådig miljö

Arbete med Core Data i en flertrådig applikation kräver strikt efterlevnad av regler: NSManagedObject kan inte överföras direkt mellan trådar. Varje tråd (eller kö) måste använda sin egen kontext. Huvudmetoden är att skapa en underordnad NSManagedObjectContext med en privat kö (NSPrivateQueueConcurrencyType) för skrivning och viewContext för läsning.

Den underordnade kontexten sparas till den överordnade, och sedan den överordnade — till lagringen på disken. Detta garanterar att ändringar inte blockerar huvudtråden och att UI alltid ser ett konsekvent tillstånd via mergeChanges eller automatisk uppdatering av viewContext vid sparande.

Core Data använder faulting — en mekanism för fördröjd laddning av relaterade objekt. Vid hämtning av User utan att begära hans addresses laddas inte de relaterade Address förrän de nås via punktnotation. Faulting sparar minne och påskyndar laddning, men kan orsaka oväntade disktillträden på huvudtråden om åtkomst inte kontrolleras i bakgrundskontexter.

För effektiv flertrådning, använd NSBatchInsertRequest och NSBatchDeleteRequest för massinfogning och borttagning utan att ladda objekt i minnet — detta är avgörande för datasynkronisering med servern.

Batch-operationer utförs direkt på NSPersistentStoreCoordinator-nivå och kringgår kontexten och objektgrafen. Detta gör det möjligt att infoga 10 000 poster på några millisekunder utan att skapa 10 000 NSManagedObject-instanser i minnet. Efter körning av batch-frågan måste kontexten uppdateras via mergeChangesFromContextDidSaveNotification så att UI återspeglar de nya data. Apple rekommenderar batch-operationer för initial dataladdning och nattsynkronisering med servern.

För att spåra ändringar i Core Data används NSPersistentHistoryTracking — en mekanism som registrerar varje transaktion (infogning, uppdatering, borttagning) i en separat historik. Aktivering av history tracking möjliggör datasynkronisering mellan olika processer och applikationer som arbetar med samma SQLite-fil, till exempel mellan huvudapplikationen och Notification Service Extension. Aktivering sker via NSPersistentStoreDescription med flaggan persistentHistoryTrackingKey, och läsning via NSPersistentHistoryChangeRequest med filter efter datum och transaktionstyp.

För felsökning och profilering av Core Data-prestanda används verktyget Core Data Profiler från Instruments-sviten i Xcode på macOS. Det visar alla hämtnings-, inmatnings-, borttagnings- och sparningsoperationer med varaktigheten för varje operation och antalet laddade objekt i tabeller och tidslinjediagram. Utvecklaren kan identifiera problemområden: flera hämtningar av samma fråga (brist på cachning), läckage av fault-objekt vid rullning av tabell eller blockering av huvudtråden på grund av synkron laddning av relaterade entiteter. Profilering rekommenderas att utföras på en verklig enhet, inte på simulatorn, eftersom simulatorns prestanda inte återspeglar applikationens verkliga beteende på iPhone eller iPad.