RLMArray

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). In addition, the property can be declared using Objective-C
generics for better compile-time type safety.

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 managed
RLMObject (RLMArrays on unmanaged 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.

Return Value

The block will be asynchronously called with the initial array, and then
called again after each write transaction which changes any of the objects in
the array, which objects are in the results, or the order of the objects in the
array.

The changes parameter will be nil the first time the block is called.
For each call after that, it will contain information about
which rows in the array were added, removed or modified. If a write transaction
did not modify any objects in the array, the block is not called at all.
See the RLMCollectionChange documentation for information on how the changes
are reported and an example of updating a UITableView.

If an error occurs the block will be called with nil for the results
parameter and a non-nil error. Currently the only errors that can occur are
when opening the Realm on the background worker thread.

Notifications are delivered via the standard run loop, and so can’t be
delivered while the run loop is blocked by other activity. When
notifications can’t be delivered instantly, multiple notifications may be
coalesced into a single notification. This can include the notification
with the initial results. For example, the following code performs a write
transaction immediately after adding the notification block, so there is no
opportunity for the initial notification to be delivered first. As a
result, the initial notification will reflect the state of the Realm after
the write transaction.