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:

RLM_ARRAY_TYPE(ObjectType)
...
@property RLMArray<ObjectType *><ObjectType> *arrayOfObjectTypes;

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.

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.

RLMMigration is the object passed into a user defined RLMMigrationBlock when updating the version of an RLMRealm instance.

This object provides access to the RLMSchema current to this migration.

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.

// Dog.h
@interface Dog : RLMObject
@property NSString *name;
@property BOOL      adopted;
@end

// Dog.m
@implementation Dog
@end //none needed

Supported property types

• NSString
• NSInteger, int, long, float, and double
• BOOL or bool
• NSDate
• NSData
• 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

See our Cocoa guide for more details.

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:

1. 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.
2. Standalone RLMObjects cannot be added to a Realm while they have any observed properties.
3. 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.

This class represents Realm model object schemas.

When using Realm, RLMObjectSchema objects allow performing migrations and introspecting the database’s schema.

Object schemas map to tables in the core database.

This class models properties persisted to Realm in an RLMObjectSchema.

When using Realm, RLMProperty objects allow performing migrations and introspecting the database’s schema.

These properties map to columns in the core database.

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.

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.

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.

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.

RLMResults cannot be created directly.

This class represents the collection of model object schemas persisted to Realm.

When using Realm, RLMSchema objects allow performing migrations and introspecting the database’s schema.

Schemas map to collections of tables in the core database.