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 persisted to Realm in an RLMSchema.

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 +[RLMRealm inMemoryRealmWithIdentifier:]).

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.

Notification token - holds onto the realm and the notification block

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

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