SwiftData for Case Management: A Technical Primer for Attorneys
Apple's SwiftData framework is the technology behind on-device-first case management. Here is how it works, why it is inherently more private than cloud-based alternatives, and what attorneys should understand about the architecture that keeps their case data on-device.
Framework vs. whole-app network behavior: Updated to clarify that SwiftData's default configuration is local-only and does not transmit data on its own, but the app as a whole may include separate network code (e.g., analytics, crash reporting, remote configuration). Attorneys should verify each app's full network behavior rather than relying on the persistence framework alone.
Most attorneys do not need to understand the persistence framework underlying their case management tool — any more than they need to understand the internal combustion engine to drive a car. But when the key value proposition of a tool is privacy achieved through on-device data storage, understanding the technology that makes it possible helps an attorney evaluate whether the architecture truly delivers on its promises.
SwiftData is Apple's modern persistence framework for iOS, iPadOS, and macOS applications. Introduced at WWDC 2023 alongside iOS 17, it is the successor to Core Data — Apple's older, more complex object graph management framework. SwiftData uses Swift's macro system to provide a declarative API for defining data models, managing object relationships, and persisting data to a local store. Critically, its default configuration stores data in a local SQLite database within the application's sandboxed container on the device — with no cloud component, no server, and no network dependency.
What SwiftData Does
At its simplest, SwiftData allows a developer to define data models using the @Model macro. A case management app might define a model for legal cases, another for hearing dates, and another for opposing counsel contacts. These models can have relationships — a case can have many hearing dates, for instance — and SwiftData automatically manages the referential integrity, sorting, filtering, and search over the data.
final class LegalCase {
var displayName: String
var caseNumber: String
var courtName: String
var jurisdiction: String
var practiceArea: String
var status: CaseStatus
var clientName: String
var filingDate: Date
var notes: String
@Relationship(deleteRule: .cascade) var hearings: [Hearing]
init(/* ... */) { /* ... */ }
}
The framework handles all persistence automatically. When the app creates, updates, or deletes a LegalCase object, SwiftData writes those changes to the local SQLite store. No network request, no server synchronization, no cloud API call. The data exists on the device and only on the device — unless the developer explicitly configures SwiftData to use a remote store or adds network code to transmit data elsewhere.
Why Local-Only Matters for Privacy
The most important property of SwiftData for privacy-focused case management is that local-only is the default. The framework does not require any network configuration to function. An app built with SwiftData can operate completely offline, with no internet connection, no server, and no cloud account. This is fundamentally different from apps that cache data locally but maintain a server-side authoritative store.
Many "offline-first" or "local-first" apps still require network access for sync, backup, or telemetry. Their local cache is a convenience for offline use, but the authoritative copy of the data remains on the server. SwiftData in its default configuration has no server — the local store is the authoritative store. There is no data to sync because there is nowhere to sync it to. This architectural choice eliminates entire categories of privacy risk for the persistence layer (though attorneys should confirm that the app as a whole does not include separate network code — e.g., for analytics, crash reporting, or remote configuration — that could transmit data):
- No data transmission from the persistence framework: SwiftData in its default configuration does not transmit client data over a network. There is no built-in API endpoint to intercept, no server log to expose, no cloud storage bucket to misconfigure. Any network behavior would require separate, explicit developer code outside the SwiftData framework.
- No third-party access through the persistence layer: Because data is never transmitted to a server by the framework itself, there is no third party with technical access to the SwiftData store. No vendor employees, no infrastructure contractors, no cloud platform operators.
- No subpoena target from the persistence architecture: With no server infrastructure in the persistence layer, there is no third party that could receive legal process for the attorney's case data through the SwiftData component. The data exists only on the attorney's device.
iOS Data Protection and Encryption
SwiftData inherits the iOS Data Protection system, which provides file-level encryption tied to the device passcode. When an iPhone or iPad is locked, the SwiftData store file is encrypted and inaccessible to any process — including malware, forensic tools, or law enforcement equipment. The encryption is transparent to the app and automatic for the user.
iOS Data Protection offers four levels of protection. For case management data, the default level (NSFileProtectionDefault) protects the file when the device is locked but permits access while the device is unlocked and the app is in use. For attorneys handling particularly sensitive matters, the app can request Complete Protection (NSFileProtectionComplete), which ensures the store file is accessible only when the device is unlocked — protecting the data even from background processes.
This encryption is hardware-backed on modern iOS devices. The encryption keys are derived from the user's passcode and stored in the Secure Enclave — a dedicated hardware security coprocessor that is isolated from the main processor and operating system. Even Apple cannot decrypt the device's data without the passcode.
Data at rest: SQLite store encrypted via iOS Data Protection. Automatic — no developer or user configuration required beyond setting a device passcode.
Data in transit: Not applicable — SwiftData in its default configuration does not transmit data over any network.
Access control: Device-level authentication (passcode, Face ID, Touch ID) gates all access to the app and its data.
Backup: Included in standard iOS encrypted backups. Backup encryption is user-managed via iOS Settings.
The "No Accounts" Advantage
Docketloom does not require an account to use. This is a direct consequence of the SwiftData architecture: because data is stored locally on the device, there is no server-side database that needs a user account for data isolation. The attorney opens the app and starts entering case data — no registration, no email verification, no password, no terms-of-service agreement with a remote service.
The absence of accounts eliminates another privacy risk: account-based data leaks. When a cloud service is breached, user account data — email addresses, password hashes, names — is often the first thing stolen. With no accounts, there are no account credentials to leak. The attorney's privacy is protected not by the strength of their password but by the architecture of the application itself.
For attorneys who are evaluating case management tools, the technology stack matters. SwiftData's default local-only architecture means the persistence framework itself does not transmit data — any network behavior would require separate, explicit developer code. Attorneys can be confident that case data managed through SwiftData in its default configuration never leaves the device, but should verify that the app as a whole does not include separate network functionality that transmits data outside the SwiftData framework.
This content is legal information, not legal advice. It does not create an attorney-client relationship and cannot substitute for consultation with a licensed attorney about your specific circumstances.