Go to your Xcode project’s “General” settings. Drag Realm.framework from the ios/dynamic/ or osx/ directory to the “Embedded Binaries” section. Make sure Copy items if needed is selected and click Finish.

If using Realm with Swift, drag the file at Swift/RLMSupport.swift into the File Navigator of your Xcode project, checking the Copy items if needed checkbox.

If using Realm in an iOS 8 project, create a new “Run Script Phase” in your app’s target’s “Build Phases” and paste the following snippet in the script text field: bash "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/Realm.framework/strip-frameworks.sh" This step is required to work around an App Store submission bug when archiving universal binaries. N.B.: Dynamic frameworks are only compatible with projects for OS X, or iOS 8 and above.

Realm Browser

We also provide a standalone app to read and edit .realm databases. You can find it in our release zip under browser/.

You can generate a test database with sample data using the menu item Tools > Generate demo database.

If you need help finding your app’s Realm file, check this StackOverflow answer for detailed instructions.

Xcode Plugin

Our Xcode plugin makes it easy to generate new Realm models.

The easiest way to install the Realm Xcode plugin is through Alcatraz under the name “RealmPlugin”. You can also install the plugin manually by opening plugin/RealmPlugin.xcodeproj contained in the release zip and clicking build. You will need to quit and relaunch Xcode to see our plugin. If you use the Xcode menu to create a new file (File > New > File… — or ⌘N) you should see a new option to create a new Realm model.

API Reference

Examples

You can find example applications for both iOS and OS X in our release zip under examples/, demonstrating how to use many features of Realm like migrations, how to use it with UITableViewControllers, encryption, command-line tools and much more.

Sign up for our Community Newsletter to get regular tips, learn about other use-cases and get alerted of blogposts and tutorials about Realm.

Models

Realm data models are defined using traditional Objective‑C classes with properties. Simply subclass RLMObject or an existing model class to create your Realm data model objects. Realm model objects mostly function like any other Objective‑C objects - you can add your own methods and protocols to them and use them like you would any other object. The main restrictions are that you can only use an object on the thread which it was created, and you can’t access its ivars directly for any persisted properties.

If you have installed our Xcode Plugin there will be a nice template to create the interface and implementation files in the “New File…” dialog.

Relationships and nested data structures are modeled simply by including properties of the target type or RLMArrays for typed lists of objects.

Property Types

You can use RLMArray<Object> and RLMObject to model relationships such as to-many and to-one. Subclassing RLMObject is also supported.

Property Attributes

Note that Realm ignores Objective‑C property attributes like nonatomic, atomic, strong, copy, weak, etc. This is done because Realm has its own optimized storage semantics under the hood. So to avoid being misleading, we recommend writing models without any property attributes at all. However, if you do set property attributes, they will be used until an RLMObject is added to a realm. Custom names for getters and setters work normally regardless of whether or not an RLMObject is in a realm.

Customizing Models

Several class methods exist to further specify model information:

+indexedProperties can be overriden to set which properties should be indexed. ```objc @interface Book : RLMObject @property float price; @property NSString *title; @end

+defaultPropertyValues can be overriden to provide default values every time an object is created. Since Swift already provides a way to define default property values inline with the property definitions, you should use that approach instead of defaultPropertyValues().

Writes

All changes to an object (addition, modification and deletion) must be done within a write transaction.

Realm objects can be instantiated and used as standalone just like regular Objective‑C objects. To share objects between threads or re-use them between app launches you must persist them to a Realm, an operation which must be done within a write transaction.

Adding objects

You can add an object to a Realm like so:

// Create object
Person*author=[[Personalloc]init];author.name=@"David Foster Wallace";// Get the default Realm
RLMRealm*realm=[RLMRealmdefaultRealm];// You only need to do this once (per thread)
// Add to Realm with transaction
[realmbeginWriteTransaction];[realmaddObject:author];[realmcommitWriteTransaction];

After you have added the object to the Realm you can continue using it, and all changes you make to it will be persisted (and must be made within a write transaction). Any changes are made available to other threads that use the same Realm when the write transaction is committed.

Please note that writes block each other, and will block the thread they are made on if multiple writes are in progress. This is similar to other persistence solutions and we recommend that you use the usual best-practices for this situation, namely offloading your writes to a separate thread.

Due to Realm’s MVCC architecture, reads are not blocked while a write transaction is open. Unless you need to make simultaneous writes from many threads at once, you should favor larger write transactions that do more work over many fine-grained write transactions.

// Creating a book with the same primary key as a previously saved book
Book*cheeseBook=[[Bookalloc]init];cheeseBook.title=@"Cheese recipes";cheeseBook.price=@9000;cheeseBook.id=@1;// Updating book with id = 1
[realmbeginWriteTransaction];[BookcreateOrUpdateInRealm:realmwithValue:cheeseBook];[realmcommitWriteTransaction];

If a book with a primary key id of 1 was not in the database, this would create a new book instead.

Deleting objects

Book*cheeseBook=...// Book stored in Realm
// Delete an object with a transaction
[realmbeginWriteTransaction];[realmdeleteObject:cheeseBook];[realmcommitWriteTransaction];

You can also delete all objects stored in a Realm. Note the Realm file will maintain its size on disk to efficiently reuse that space for future objects.

// Delete all objects from the realm
[realmbeginWriteTransaction];[realmdeleteAllObjects];[realmcommitWriteTransaction];

Queries

Queries return an RLMResults instance, which contains a collection of RLMObjects. RLMResults have an interface very similar to NSArray and objects contained in a RLMResults can be accessed using indexed subscripting. Unlike NSArrays, RLMResults are typed and only hold RLMObjects of a single subclass type.

All queries (including queries and property access) are lazy in Realm. Data is only read when the properties are accessed.

Results to a query are not copies of your data: modifying the results of a query (within a write transaction) will modify the data on disk directly. Similarly, you can traverse your graph of relationships directly from the RLMObjects contained in a RLMResults.

Retrieving Objects by Type

The most basic method for retrieving objects from a Realm is +[RLMObject allObjects], which returns a RLMResults of all RLMObject instances of the subclass type being queried the default Realm.

Querying with Predicates

If you’re familiar with NSPredicate, then you already know how to query in Realm. RLMObjects, RLMRealm, RLMArray, and RLMResults all provide methods that allow you to query for specific RLMObject instances by simply passing in an NSPredicate instance, predicate string, or predicate format string just as you would when querying an NSArray.

For example, the following would extend our earlier example by calling [RLMObject objectsWhere:] to retrieve all dogs with the color tan and names beginning with ‘B’ from the default Realm:

// Query using a predicate string
RLMResults*tanDogs=[DogobjectsWhere:@"color = 'tan' AND name BEGINSWITH 'B'"];// Query using an NSPredicate
NSPredicate*pred=[NSPredicatepredicateWithFormat:@"color = %@ AND name BEGINSWITH %@",@"tan",@"B"];tanDogs=[DogobjectsWithPredicate:pred];

Ordering Results

RLMResults allows you to specify a sort criteria and order based on a single or multiple properties. For example, the following calls sorts the returned dogs from the example above alphabetically by name:

// Sort tan dogs with names starting with "B" by name
RLMResults*sortedDogs=[[DogobjectsWhere:@"color = 'tan' AND name BEGINSWITH 'B'"]sortedResultsUsingProperty:@"name"ascending:YES];

Chaining Queries

One unique property of Realm’s query engine is the ability to chain queries with very little transactional overhead when compared to traditional databases that require a separate trip to the database server for each successive query.

For example, if we wanted a result set for just the tan colored dogs, and the tan colored dogs whose names also started with ‘B’, you might chain two queries like this:

Realms

The Default Realm

You may have noticed so far that we have often initialized access to our realm variable by calling [RLMRealm defaultRealm]. That method returns an RLMRealm object that maps to a file called “default.realm” under the Documents folder of your app.

Please note that if a custom path is used to initialize a Realm, it must be in a location with write permissions. The most common location to store writable Realm files is the “Documents” directory on iOS and the “Application Support” directory on OS X. Please respect Apple’s iOS Data Storage Guidelines, which recommend that documents that can be regenerated be stored in the <Application_Home>/Library/Caches directory.

In-memory Realms do not save data across app launches, but all other features of Realm will work as expected, including querying, relationships and thread-safety. This is a useful option if you need flexible data access without the overhead of disk persistence.

Notice: When all in-memory Realm instances with a particular identifier go out of scope with no references, all data is freed for that Realm. It is recommended that you hold onto a strong reference to any created in-memory Realms for the duration of your app.

Using a Realm Across Threads

To access the same Realm file from different threads, you must initialize a new Realm to get a different instance for every thread of your app. As long as you specify the same path, all Realm instances will map to the same file on disk.

Sharing Realm instances across threads is not supported. Realm instances accessing the same realm file must also all use the same readOnly value (either all readwrite, or all readonly).

Realm can be very efficient when writing large amounts of data by batching together multiple writes within a single transaction. Transactions can also be performed in the background using Grand Central Dispatch to avoid blocking the main thread. RLMRealm objects are not thread safe and cannot be shared across threads, so you must get a Realm instance in each thread/dispatch_queue in which you want to read or write. Here’s an example of inserting a million objects in a background queue:

dispatch_async(queue,^{@autoreleasepool{// Get realm and table instances for this thread
RLMRealm*realm=[RLMRealmdefaultRealm];// Break up the writing blocks into smaller portions
// by starting a new transaction
for(NSIntegeridx1=0;idx1<1000;idx1++){[realmbeginWriteTransaction];// Add row via dictionary. Property order is ignored.
for(NSIntegeridx2=0;idx2<1000;idx2++){[PersoncreateInRealm:realmwithValue:@{@"name":[selfrandomString],@"birthdate":[selfrandomDate]}];}// Commit the write transaction
// to make this data available to other threads
[realmcommitWriteTransaction];}}});

Copying Objects Between Realms

Copying Realm objects to other Realms is as simple as passing in the original object to +[RLMObject createInRealm:withValue:]. For example, [MyRLMObjectSubclass createInRealm:otherRealm withValue:originalObjectInstance].

Finding a Realm File

If you need help finding your app’s Realm file, check this StackOverflow answer for detailed instructions.

Bundling a Realm with an App

It’s common to seed an app with initial data, making it available to your users immediately on first launch. Here’s how to do this:

First, populate the realm. You should use the same data model as your final, shipping app to create a realm and populate it with the data you wish to bundle with your app. Since realm files are cross-platform, you can use an OS X app (see our JSONImport example) or your iOS app running in the simulator.

In the code where you’re generating this realm file, you should finish by making a compacted copy of the file (see -[RLMRealm writeCopyToPath:error:]). This will reduce the Realm’s file size, making your final app lighter to download for your users.

Drag the new compacted copy of your realm file to your final app’s Xcode Project Navigator.

Relationships

RLMObjects can be linked to each other by using RLMObject and RLMArray properties. RLMArrays have an interface very similar to NSArray and objects contained in a RLMArray can be accessed using indexed subscripting. Unlike NSArrays, RLMArrays are typed and only hold RLMObjects of a single subclass type. For more details see RLMArray.

When using RLMObject properties, you can access nested properties using normal property syntax. For example rex.owner.address.country will traverse the object graph and automatically fetch each object from Realm as needed.

To-Many

You can define a to-many relationship using RLMArray properties. RLMArrays contain other RLMObjects of a single type and have an interface very similar to NSMutableArray.

To add a “dogs” property on our Person model that links to multiple dogs, we must first define an RLMArray<Dog> type. This is done via a macro at the bottom of the corresponding model interface:

// Jim is owner of Rex and all dogs named "Fido"
RLMArray*someDogs=[DogobjectsWhere:@"name contains 'Fido'"];[jim.dogsaddObjects:someDogs];[jim.dogsaddObject:rex];

Inverse Relationships

With inverse relationships (also known as backlinks), you can obtain all objects linking to a given object through a specific property. For example, calling -linkingObjectsOfClass:forProperty: on a Dog instance will return all objects of the specified class linking to the calling instance with the specified property. It’s possible to simplify this pattern by defining a read-only (computed) owners property on Dog:

@interfaceDog:RLMObject@propertyNSString*name;@propertyNSIntegerage;@property(readonly)NSArray*owners;// Realm doesn't persist this property because it is readonly
@end@implementationDog// Define "owners" as the inverse relationship to Person.dogs
-(NSArray*)owners{return[selflinkingObjectsOfClass:@"Person"forProperty:@"dogs"];}@end

Notifications

Realm instances send out notifications to other instances on other threads every time a write transaction is committed. These notifications can be observed by registering a block:

The notification stays active as long as a reference is held to the returned notification token. You should hold onto a strong reference to this token on the class registering for updates, as notifications are automatically un-registered when the notification token is deallocated.

Migrations

When working with any database, it is likely your data model will change over time. Since data models in Realm are defined as standard Objective‑C interfaces, making model changes is as easy as changing any other Objective‑C interface. For example, suppose we have the following Person model:

At this point if you had saved any data with the previous model version, there will be a mismatch between what Realm sees defined in code and the data Realm sees on disk. When this occurs, an exception will be thrown unless you run a migration.

For example, suppose we want to migrate the Person model declared earlier. The minimal necessary migration block would be the following:

// Inside your [AppDelegate didFinishLaunchingWithOptions:]
// Notice setSchemaVersion is set to 1, this is always set manually. It must be
// higher than the previous version (oldSchemaVersion) or an RLMException is thrown
[RLMRealmsetSchemaVersion:1forRealmAtPath:[RLMRealmdefaultRealmPath]withMigrationBlock:^(RLMMigration*migration,NSUIntegeroldSchemaVersion){// We haven’t migrated anything yet, so oldSchemaVersion == 0
if(oldSchemaVersion<1){// Nothing to do!
// Realm will automatically detect new properties and removed properties
// And will update the schema on disk automatically
}}];// now that we have called `setSchemaVersion:withMigrationBlock:`, opening an outdated
// Realm will automatically perform the migration and opening the Realm will succeed
[RLMRealmdefaultRealm];

At the very minimum all we need to do is to update the version with an empty block to indicate the that the schema has been upgraded (automatically) by Realm.

While this is the minimum acceptable migration, we probably want to use this block to populate any new properties (in this case fullName) with something meaningful. Within the migration block we can call [RLMMigration enumerateObjects:block:] to enumerate each RLMObject of a certain type, and apply any necessary migration logic. Notice how for each enumeration the existing RLMObject instance is accessed via an oldObject variable and the updated instance is accessed via newObject:

// Inside your [AppDelegate didFinishLaunchingWithOptions:]
[RLMRealmsetSchemaVersion:1forRealmAtPath:[RLMRealmdefaultRealmPath]withMigrationBlock:^(RLMMigration*migration,NSUIntegeroldSchemaVersion){// We haven’t migrated anything yet, so oldSchemaVersion == 0
if(oldSchemaVersion<1){// The enumerateObjects:block: method iterates
// over every 'Person' object stored in the Realm file
[migrationenumerateObjects:Person.classNameblock:^(RLMObject*oldObject,RLMObject*newObject){// combine name fields into a single field
newObject[@"fullName"]=[NSStringstringWithFormat:@"%@ %@",oldObject[@"firstName"],oldObject[@"lastName"]];}];}}];

Once the migration is successfully completed, the Realm and all of its objects can be accessed as usual by your app.

[RLMRealmsetSchemaVersion:2forRealmAtPath:[RLMRealmdefaultRealmPath]withMigrationBlock:^(RLMMigration*migration,NSUIntegeroldSchemaVersion){// The enumerateObjects:block: method iterates
// over every 'Person' object stored in the Realm file
[migrationenumerateObjects:Person.classNameblock:^(RLMObject*oldObject,RLMObject*newObject){// Add the 'fullName' property only to Realms with a schema version of 0
if(oldSchemaVersion<1){newObject[@"fullName"]=[NSStringstringWithFormat:@"%@ %@",oldObject[@"firstName"],oldObject[@"lastName"]];}// Add the 'email' property to Realms with a schema version of 0 or 1
if(oldSchemaVersion<2){newObject[@"email"]=@"";}}];}];// now that we have called `setSchemaVersion:withMigrationBlock:`, opening an outdated
// Realm will automatically perform the migration and opening the Realm will succeed
[RLMRealmdefaultRealm];

For a more complete look at the implementation of a data schema migration, check out our migration sample app.

Linear Migrations

Suppose we have two users for our app: JP and Tim. JP updates the app very often, but Tim happens to skip a few versions. It’s likely that JP has seen every new version of our app, and every schema upgrade in sequence: he downloaded a version of the app that took him from v0 to v1, another update that took him from v1 to v2. In contrast, it’s possible that Tim will download an update of the app that would need to take him from v0 to v2 immediately. Structuring your migration blocks with non-nestedif (oldSchemaVersion < X) calls ensures that they will see all necessary upgrades, no matter which schema version they start from.

Another scenario may arise in the case of users who skipped versions of your app. If you delete a property email at version 2 and re-introduce it at version 3, and a user jumps from version 1 to version 3, Realm will not be able to automatically detect the deletion of the email property, as there will be no mismatch between the schema on disk and the schema in the code for that property. This will lead to Tim’s Person object having a v3 address property that has the contents of the v1 address property. This may not be a problem, unless you changed the internal storage representation of that property between v1 and v3 (say, went from an ISO address representation to a custom one). To avoid this, we recommend you nil out the email property on the if (oldSchemaVersion < 3) statement, guaranteeing that all realms upgraded to version 3 will have a correct dataset.

Encryption

Please take note of the Export Compliance section of our LICENSE, as it places restrictions against the usage of Realm if you are located in countries with an export restriction or embargo from the United States.

On iOS, it’s possible to encrypt Realm files with very little performance overhead by using NSFileProtection APIs. There are two main caveats to this approach: 1) the Realm file won’t be portable to other platforms (NSFileProtection is iOS-only) and 2) the Realm file won’t be encrypted on iOS devices that aren’t password-protected. To avoid these restrictions (or if you’re building an OS X app), then you should use Realm-level encryption.

Realm supports encrypting the database file on disk with AES-256+SHA2 by supplying a 64-byte encryption key when creating a Realm.

// Generate a random encryption key
NSMutableData*key=[NSMutableDatadataWithLength:64];SecRandomCopyBytes(kSecRandomDefault,key.length,(uint8_t*)key.mutableBytes);// Open the encrypted Realm file
NSError*error;RLMRealm*realm=[RLMRealmrealmWithPath:RLMRealm.defaultRealmPathkey:keyreadOnly:NOerror:&error];if(!realm){// If the encryption key is wrong, `error` will say that it's an invalid database
NSLog(@"Error opening realm: %@",error);return;}// Use the Realm as normal
RLMResults*dogs=[[DogobjectsInRealm:realmwhere:@"name contains 'Fido'"]];

This makes it so that all of the data stored on disk is transparently encrypted and decrypted with AES-256 as needed, and verified with a SHA-2 HMAC. The same encryption key must be supplied every time you obtain a Realm instance. You can also have Realm store an encryption key in memory to use automatically whenever opening a Realm at a given path. For example, to set the key for the default Realm (letting you use the convenience methods):

// Generate a random encryption key
NSMutableData*key=[NSMutableDatadataWithLength:64];SecRandomCopyBytes(kSecRandomDefault,key.length,(uint8_t*)key.mutableBytes);// Set the encryption key for the default Realm
[RLMRealmsetEncryptionKey:keyforRealmsAtPath:RLMRealm.defaultRealmPath];// Use the Realm as normal
RLMResults*dogs=[[DogobjectsWhere:@"name contains 'Fido'"]];

See our encryption sample app for an end-to-end app that generates an encryption key, stores it securely in the keychain, and uses it to encrypt a Realm.

There is a small performance hit (typically less than 10% slower) when using encrypted Realms.

Note that third party crash reporters (Crashlytics, PLCrashReporter etc.) should be registered before you first open an encrypted Realm, or you may get spurious reports of errors when the app didn’t actually crash.

Debugging

Debugging your Realm apps is easy, with LLDB support and the ability to view your app’s data in the Realm Studio.

Our Xcode Plugin comes with a LLDB script which adds support for inspecting persisted RLMObjects, RLMResults and RLMArrays objects in Xcode’s UI, rather than just displaying every property as nil or 0:

N.B.: The script currently only supports Objective‑C. Swift support is in progress.

Debugging Encrypted Realms

Attaching an LLDB session to a process using an encrypted Realm is not currently supported. You may work around this by disabling encryption when debugging your application by launching it with REALM_DISABLE_ENCRYPTION=YES set in your environment. This will cause a request for an encrypted Realm to be treated as a request for an unencrypted Realm.

Injecting Realm Instances

Another way to test realm-related code is to have all the methods you’d like to test accept a RLMRealm instance as an argument, so that you can pass in different realm when running the app and when testing it. For example, suppose your app has a method to GET a user profile from a JSON API and you’d like to test that the local profile is properly created:

Avoid Linking Realm and Tested Code in Test Targets

If you’re using Realm as a dynamic framework, you’ll need to make sure your unit test target can find Realm. You can do this by adding the parent path to Realm.framework to your unit test’s “Framework Search Paths”.

If your tests fail with an exception message "Object type '...' not persisted in Realm", it’s likely because you’ve linked the Realm framework directly to your test target, which should not be done. Unlinking Realm from your test target should address that.

You should also make sure to only link your model class files to your application or framework targets; never your unit test targets. Otherwise, those classes will be duplicated when testing, which can lead to difficult to debug issues (see https://github.com/realm/realm-cocoa/issues/1350 for details).

You’ll need to make sure all the code you need to test is exposed to your unit test targets (use the public ACL in Swift).

Resetting State Between Tests

It’s generally useful for unit tests to be isolated from each other. For that reason, we recommend that you delete the persisted realm files from disk and reset Realm’s internal state between every test. This can be done in the setUp and tearDown methods when using XCTest:

Testing Realm

Realm has a comprehensive test suite that runs on every commit, so your application’s tests shouldn’t test Realm itself, but rather your app’s usage of Realm.

Since Realm is open-source, we gladly accept contributions to the binding, tests and documentation.

REST APIs

Realm easily integrates with REST APIs and provides several advantages as oppposed to using REST APIs without local persistance:

Caching your data in Realm allows you to provide an offline experience, as opposed to REST APIs where connectivity is always required.

By caching your entire data set in Realm, you can execute queries locally and provide a better search and browsing experience than wouldn’t be possible with REST alone.

Storing your data in Realm can reduce server-side load by only fetching new or changed data.

Best Practices

Asynchronous Requests — Network requests and other blocking operations should be performed on a background thread to avoid blocking the user interface. For the same reason it is recommended that inserting or changing a large number of objects in a Realm are made on a background thread. You can use Notifications to respond to changes made in the background.

Caching large datasets — We recommend you pre-fetch data when possible and store it locally in a Realm. This allows you to perform queries over your entire dataset locally.

Insert-or-update — If your dataset has a unique identifier, such as a primary key, you can use it to easily implement insert-or-update logic using +[RLMObject createOrUpdateInRealm:withValue:]: when receiving a response from a REST API. These methods automatically check if each record already exist and apply updates to existing records while creating new records.

Example

The following is a simple example of how you can use Realm with a REST API. In this example, we’ll retrieve a JSON-formatted data set from the foursquare API, then save it as Realm Objects in the default Realm.

For a realtime example of a similar use case in action, check out our video demo.

First we create an instance of the default Realm to persist the data to, and fetch our data set from the API. For simplicity in this example we use [NSData initWithContentsOfURL].

There are several ways we may want to import this JSON into our Realm. You could read the NSDictionary and map the properties to a single RLMObject manually via a custom insert function. For the sake of this example, we will instead directly insert the NSDictionary in the Realm and have it automatically be mapped to a hierarchy of RLMObjects that will be created on the fly for us. For this to work, we need an RLMObject structure whose properties will match all the keys in the JSON exactly. JSON keys not matched by an RLMObject property will be ignored on insert. The following RLMObject declarations would work:

Since the result set is given to us as an array we have to create an object for each element by calling [Venue createInDefaultRealmWithValue:]. This creates Venue and its child objects from a JSON representation and adds the newly created obejcts to the default Realm:

//Extract the array of venues from the response
NSArray*venues=json[@"venues"];RLMRealm*realm=[RLMRealmdefaultRealm];[realmbeginWriteTransaction];// Save one Venue object (and dependents) for each element of the array
for(NSDictionary*venueinvenues){[VenuecreateOrUpdateInDefaultRealmWithValue:venue];}[realmcommitWriteTransaction];

Next Steps

You can look at our examples to see Realm used in practice in an app. (We’re getting more samples ready!)

Happy hacking! You can always talk to a live human developer on realm-cocoa.

Current Limitations

Realm is currently in beta and we are continuously adding features and fixing issues while working towards a 1.0 release. Until then, we’ve compiled a list of our most commonly hit limitations.

Please refer to our GitHub issues for a more comprehensive list of known issues.

General Limits

Realm aims to strike a balance between flexibility and performance. In order to accomplish this goal, realistic limits are imposed on various aspects of storing information in a realm. For example:

Class names must be between 0 and 63 bytes in length. UTF8 characters are supported. An exception will be thrown at your app’s initialization if this limit is exceeded.

Property names must be between 0 and 63 bytes in length. UTF8 characters are supported. An exception will be thrown at your app’s initialization if this limit is exceeded.

NSData properties cannot hold data exceeding 16MB in size. To store larger amounts of data, either break it up into 16MB chunks or store it directly on the file system, storing paths to these files in the realm. An exception will be thrown at runtime if your app attempts to store more than 16MB in a single property.

NSDate properties can only persist date information down to one second. It also cannot represent +[NSDate distantFuture] or +[NSDate distantPast]. Refer to the NSDate entry in Current Limitations below for more information.

Any single Realm file cannot be larger than the amount of memory your application would be allowed to map in iOS — this changes per device, and depends on how fragmented the memory space is at that point in time (there is a radar open about this issue: rdar://17119975). If you need to store more data, you can map it over multiple Realm files.

Fine-grained notifications are not yet supported

While it is possible to receive notifications when a realm changes (see Notifications), it is not currently possible to determine what was added/removed/moved/updated from that notification. We will be adding this feature in the near future.

NSDate is truncated to the second

Persisting an NSDate with a fractional number of seconds will truncate the date to the second. A fix for this is in progress. See GitHub issue #875 for more details. In the mean time, you can store NSTimeInterval properties with no loss in precision.

Realm Object Setters & Getters cannot be overriden

Since Realm overrides setters and getters to back properties directly by the underlying database, you cannot override them on your objects. A simple workaround is to create new, realm-ignored properties, whose accessors can be overriden, and can call other setters/getters.

KVO is not supported

Realm doe not support KVO yet but has its own notification mechanism (see Notifications). We are working to add KVO support at the moment: see GitHub issue #601.

File size & tracking of intermediate versions

You should expect a Realm database to take less space on disk than an equivalent SQLite database. If your Realm file is much larger than you expect, it may be because you have a RLMRealm that is referring to an older version of the data in the database.

In order to give you a consistent view of your data, Realm only updates the active version accessed at the start of a run loop iteration. This means that if you read some data from the Realm and then block the thread on a long-running operation while writing to the Realm on other threads, the version is never updated and Realm has to hold on to intermediate versions of the data which you may not actually need, resulting in the file size growing with each write. The extra space will eventually be reused by future writes, or may be compacted — for example by calling writeCopyToPath:error:.

To avoid this issue you, may call invalidate to tell Realm that you no longer need any of the objects that you’ve read from the Realm so far, which frees us from tracking intermediate versions of those objects. The Realm will update to the latest version the next time it is accessed.

You may also see this problem when accessing Realm using Grand Central Dispatch. This can happen when a Realm ends up in a dispatch queue’s autorelease pool as those pools may not be drained for some time after executing your code. The intermediate versions of data in the Realm file cannot be reused until the RLMRealm object is deallocated. To avoid this issue, you should use an explicit autorelease pool when accessing a Realm from a dispatch queue.

FAQ

How big is the Realm library?

Once your app is built for release, Realm should only add around 1MB to its size. The releases we distribute are significantly larger (~37MB for iOS & ~2.4MB for OS X) because they include support for more architectures (ARM, ARM64, x86 for the simulator) and some debug symbols, which will all be stripped by Xcode automatically when you build your app.

Should I use Realm in production applications?

Realm has been used in production in commercial products since 2012.

You should expect our Objective‑C & Swift APIs to change as we evolve the product from community feedback — and you should expect more features & bugfixes to come along as well.

Do I have to pay to use Realm?

No, Realm is entirely free to use, even in commercial projects.

How do you all plan on making money?

We’re actually already generating revenue selling enterprise products and services around our technology. If you need more than what is currently in our releases or in realm-cocoa, we’re always happy to chat by email. Otherwise, we are committed to developing realm-cocoa in the open, and to keep it free and open-source under the Apache 2.0 license.

I see references to “tightdb” or a “core” in the code, what is that?

TightDB is the old name of our core C++ storage engine. The core is not currently open-source but we do plan on open-sourcing it, also under the Apache 2.0 license, once we’ve had a chance to clean it, rename it, and finalize major features inside of it. In the meantime, its binary releases are made available under the Realm Core (TightDB) Binary License.