Classes

A Realm instance (also referred to as a Realm) represents a Realm database.

Realms can either be stored on disk (see init(path:)) or in memory (see Configuration).

Realm instances are cached internally, and constructing equivalent Realm objects (for example, by using the same path or identifier) produces limited overhead.

If you specifically want to ensure a Realm instance is destroyed (for example, if you wish to open a Realm, check some property, and then possibly delete the Realm file and re-open it), place the code which uses the Realm within an autoreleasepool {} and ensure you have no other strong references to it.

LinkingObjects is an auto-updating container type. It represents zero or more objects that are linked to its owning model object through a property relationship.

LinkingObjects can be queried with the same predicates as List<Element> and Results<Element>.

LinkingObjects always reflects the current state of the Realm on the current thread, including during write transactions on the current thread. The one exception to this is when using for...in enumeration, which will always enumerate over the linking objects that were present when the enumeration is begun, even if some of them are deleted or modified to no longer link to the target object during the enumeration.

LinkingObjects can only be used as a property on Object models. Properties of this type must be declared as let and cannot be dynamic.

List is the container type in Realm used to define to-many relationships.

Like Swift’s Array, List is a generic type that is parameterized on the type of Object it stores.

Unlike Swift’s native collections, Lists are reference types, and are only immutable if the Realm that manages them is opened as read-only.

Lists can be filtered and sorted with the same predicates as Results<Element>.

Properties of List type defined on Object subclasses must be declared as let and cannot be dynamic.

Object is a class used to define Realm model objects.

In Realm you define your model classes by subclassing Object and adding properties to be managed. You then instantiate and use your custom subclasses instead of using the Object class directly.

class Dog: Object {
    @objc dynamic var name: String = ""
    @objc dynamic var adopted: Bool = false
    let siblings = List<Dog>()
}

Supported property types

• String, NSString
• Int
• Int8, Int16, Int32, Int64
• Float
• Double
• Bool
• Date, NSDate
• Data, NSData
• RealmOptional<Value> for optional numeric properties
• Object subclasses, to model many-to-one relationships
• List<Element>, to model many-to-many relationships

String, NSString, Date, NSDate, Data, NSData and Object subclass properties can be declared as optional. Int, Int8, Int16, Int32, Int64, Float, Double, Bool, and List properties cannot. To store an optional number, use RealmOptional<Int>, RealmOptional<Float>, RealmOptional<Double>, or RealmOptional<Bool> instead, which wraps an optional numeric value.

All property types except for List and RealmOptional must be declared as @objc dynamic var. List and RealmOptional properties must be declared as non-dynamic let properties. Swift lazy properties are not allowed.

Note that none of the restrictions listed above apply to properties that are configured to be ignored by Realm.

Querying

You can retrieve all objects of a given type from a Realm by calling the objects(_:) instance method.

Relationships

See our Cocoa guide for more details.

A RealmOptional instance represents an optional value for types that can’t be directly declared as @objc in Swift, such as Int, Float, Double, and Bool.

To change the underlying value stored by a RealmOptional instance, mutate the instance’s value property.

A type-erased RealmCollection.

Instances of RealmCollection forward operations to an opaque underlying collection having the same Element type.

Results is an auto-updating container type in Realm returned from object queries.

Results can be queried with the same predicates as List<Element>, and you can chain queries to further filter query results.

Results always reflect the current state of the Realm on the current thread, including during write transactions on the current thread. The one exception to this is when using for...in enumeration, which will always enumerate over the objects which matched the query when the enumeration is begun, even if some of them are deleted or modified to be excluded by the filter during the enumeration.

Results are lazily evaluated the first time they are accessed; they only run queries when the result of the query is requested. This means that chaining several temporary Results to sort and filter your data does not perform any unnecessary work processing the intermediate state.

Once the results have been evaluated or a notification block has been added, the results are eagerly kept up-to-date, with the work done to keep them up-to-date done on a background thread whenever possible.

Results instances cannot be directly instantiated.

SyncSubscription represents a subscription to a set of objects in a synced Realm.

When partial sync is enabled for a synced Realm, the only objects that the server synchronizes to the client are those that match a sync subscription registered by that client. A subscription consists of of a query (represented by a Results) and an optional name.

Changes to the state of the subscription can be observed using SyncSubscription.observe(_:options:_:).

Subscriptions are created using Results.subscribe() or Results.subscribe(named:).

A permission which can be applied to a Realm, Class, or specific Object.

Permissions are applied by adding the permission to the RealmPermission singleton object, the ClassPermission object for the desired class, or to a user-defined List property on a specific Object instance. The meaning of each of the properties of Permission depend on what the permission is applied to, and so are left undocumented here. See RealmPrivileges, ClassPrivileges, and ObjectPrivileges for details about what each of the properties mean when applied to that type.

A Role within the permissions system.

A Role consists of a name for the role and a list of users which are members of the role. Roles are granted privileges on Realms, Classes and Objects, and in turn grant those privileges to all users which are members of the role.

A role named everyone is automatically created in new Realms, and all new users which connect to the Realm are automatically added to it. Any other roles you wish to use are managed as normal Realm objects.

A representation of a sync user within the permissions system.

PermissionUser objects are created automatically for each sync user which connects to a Realm, and can also be created manually if you wish to grant permissions to a user which has not yet connected to this Realm. When creating a PermissionUser manually, you must also manually add it to the everyone Role.

A singleton object which describes Realm-wide permissions.

An object of this type is automatically created in the Realm for you, and more objects cannot be created manually.

See RealmPrivileges for the meaning of permissions applied to a Realm.

An object which describes class-wide permissions.

An instance of this object is automatically created in the Realm for class in your schema, and should not be created manually.

An object intended to be passed between threads containing a thread-safe reference to its thread-confined object.

To resolve a thread-safe reference on a target Realm on a different thread, pass to Realm.resolve(_:).