Classes

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

Unlike an NSArray, RLMArrays hold a single type, specified by the objectClassName property.
This is referred to in these docs as the “type” of the array.

When declaring an RLMArray property, the type must be marked as conforming to a
protocol by the same name as the objects it should contain (see the
RLM_ARRAY_TYPE macro). RLMArray properties can also use Objective‑C generics
if available. For example:

RLMArrays can be queried with the same predicates as RLMObject and RLMResults.

RLMArrays cannot be created directly. RLMArray properties on RLMObjects are
lazily created when accessed, or can be obtained by querying a Realm.

Key-Value Observing

RLMArray supports array key-value observing on RLMArray properties on RLMObject
subclasses, and the invalidated property on RLMArray instances themselves is
key-value observing compliant when the RLMArray is attached to a persisted
RLMObject (RLMArrays on standalone RLMObjects will never become invalidated).

Because RLMArrays are attached to the object which they are a property of, they
do not require using the mutable collection proxy objects from
-mutableArrayValueForKey: or KVC-compatible mutation methods on the containing
object. Instead, you can call the mutation methods on the RLMArray directly.

Declaration

An RLMSortDescriptor stores a property name and a sort order for use with
sortedResultsUsingDescriptors:. It is similar to NSSortDescriptor, but supports
only the subset of functionality which can be efficiently run by the query
engine. RLMSortDescriptor instances are immutable.

Declaration

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

Supported property types

NSNumber<X>, where X is one of RLMInt, RLMFloat, RLMDouble or RLMBool, for optional number properties

RLMObject subclasses, so you can have many-to-one relationships.

RLMArray<X>, where X is an RLMObject subclass, so you can have many-to-many relationships.

Querying

You can query an object directly via the class methods: allObjects, objectsWhere:, and objectsWithPredicate:.
These methods allow you to easily query a custom subclass for instances of this class in the
default Realm. To search in a Realm other than the default Realm use the interface on an RLMRealm instance.

Relationships

Key-Value Observing

All RLMObject properties (including properties you create in subclasses) are
Key-Value Observing compliant,
except for realm and objectSchema. There are several Realm-specific things
to keep in mind when observing Realm objects:

Unlike NSMutableArray properties, RLMArray properties do not require
using the proxy object returned from -mutableArrayValueForKey:, or defining
KVC mutation methods on the containing class. You can simply call methods on
the RLMArray directly and the changes will be observed by the containing
object.

Standalone RLMObjects cannot be added to a Realm while they have any
observed properties.

Modifying persisted RLMObjects in -observeValueForKeyPath:ofObject:change:context:
is problematic. Properties may change when the Realm is not in a write
transaction (for example, when -[RLMRealm refresh] is called after changes
are made on a different thread), and notifications sent prior to the change
being applied (when NSKeyValueObservingOptionPrior is used) may be sent at
times when you cannot begin a write transaction.

Declaration

An RLMRealm instance (also referred to as a realm) represents a Realm
database.

Realms can either be stored on disk (see +[RLMRealm realmWithPath:]) or in
memory (see RLMRealmConfiguration).

RLMRealm instances are cached internally, and constructing equivalent RLMRealm
objects (with the same path or identifier) multiple times on a single thread
within a single iteration of the run loop will normally return the same
RLMRealm object. If you specifically want to ensure a RLMRealm object 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.

Warning

RLMRealm instances are not thread safe and can not be shared across
threads or dispatch queues. You must call this method on each thread you want
to interact with the realm on. For dispatch queues, this means that you must
call it in each block which is dispatched, as a queue is not guaranteed to run
on a consistent thread.

Declaration

A token which is returned from methods which subscribe to changes to a Realm.

Change subscriptions in Realm return an RLMNotificationToken which can be used
to unsubscribe from the changes. You must store a strong reference to the token
for as long as you want to continue to receive notifications. When you wish to
stop, call the -stop method.

Declaration

An RLMRealmConfiguration is used to describe the different options used to
create an RLMRealm instance.

RLMRealmConfiguration instances are just plain NSObjects, and unlike RLMRealm
and RLMObjects can be freely shared between threads as long as you do not
mutate them. Creating configuration objects for class subsets (by setting the
objectClasses property) can be expensive, and so you will normally want to
cache and reuse a single configuration object for each distinct configuration
that you are using rather than creating a new one each time you open a Realm.

Declaration

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

RLMResults can be queried with the same predicates as RLMObject and RLMArray
and you can chain queries to further filter query results.

RLMResults 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 fast 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.

RLMResults are initially lazily evaluated, and only run queries when the result
of the query is requested. This means that chaining several temporary
RLMResults to sort and filter your data does not perform any extra 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.