Realm Database

Why it exists

Core Data solves mobile persistence but comes with a steep learning curve around its object graph, contexts, merge policies and thread confinement rules, and raw SQLite means writing and maintaining SQL by hand plus a manual mapping layer to your model types. Realm exists to offer object persistence that feels like working with plain Swift objects, backed by a purpose built mobile database engine, without needing to hand write SQL or manage Core Data's context machinery.

The mental model

Think of a normal database as a filing cabinet: you ask a clerk to fetch a folder, get a photocopy, and if the original changes later your photocopy is now stale. A Realm object is more like a live window into the actual folder in the cabinet: what you are looking at updates itself the instant something else changes that same folder, because you are not holding a copy, you are holding a reference straight into Realm's underlying storage.

How it works

You define a model by subclassing Object and declaring its properties, then write with realm.write inside a closure, which wraps your changes in an ACID transaction and commits them atomically. Fetching with realm.objects(Type.self) returns a Results collection that is lazily loaded and stays live, meaning as the underlying data changes, previously fetched objects and result collections update automatically and can push out change notifications you subscribe to. Under the hood, Realm uses a zero copy architecture, memory mapping database pages directly rather than deserializing full objects into memory, and multiversion concurrency control lets many threads read a consistent snapshot while a write happens elsewhere, though a Realm instance stays confined to the thread that created it.

When it matters

Realm matters when a mobile app needs fast local persistence with a lot of reactive UI, like a chat or feed app where new local data should appear instantly without manual refresh logic. The footgun is thread confinement: passing a Realm object across threads directly crashes or corrupts state, so you pass primary keys or thread safe references between threads and refetch the object on the receiving thread's own Realm instance.

A concrete example

A note taking app fetches a Results collection of all Note objects sorted by date and binds it to a SwiftUI list. When a background sync task inserts a new note fetched from the server inside a write transaction, the already displayed Results collection updates itself, and the SwiftUI list re-renders with the new note in place, with no explicit refetch call anywhere in the view code.