We just pushed a Realm Objective-C update to this website and to CocoaPods. Here’s what’s new!

Sharing Realms Between Processes

The big news for this release is that we now support seamlessly sharing Realm files between multiple processes, which is necessary for most iOS 8 App Extensions including Apple Watch Extensions. Just put the Realm file in your app group container (on iOS or in sandboxed OS X applications) and everything works exactly the same as when you open a Realm file on multiple threads.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Get the shared directory for the application group
    NSURL *container = [[NSFileManager defaultManager]
                        containerURLForSecurityApplicationGroupIdentifier:@"group.com.example.my-app"];

    // Set the default realm path to a location in the shared container
    // You can also pass a path in the container to +[RLMRealm realmWithPath:], of course
    NSURL *realmURL = [containerURL URLByAppendingPathComponent:@"default.realm"];
    [RLMRealm setDefaultRealmPath:realmURL.path];

    // Just use the Realm as usual
    ConfigurationObject *config = [[ConfigurationObject allObjects] firstObject];
    ...

    return YES;
}

There are a few limitations at the moment:

• Encrypted Realms cannot be shared between processes.
• All processes must be running on a single machine, and must be the same architecture (so no sharing Realm files on a network drive, and opening a Realm in both an iOS simulator and an OS X application requires using a 64-bit simulator).
• All processes must be using the same version of Realm Cocoa, and must have identical object schemas.

Indexed Properties

We’ve changed how you declare indexed properties. Rather than overriding attributesForProperty:, you now just override indexedProperties and return an array with the names of the properties which should be indexed:

@interface MyModel : RLMObject
@property NSString *indexedProperty;
@property int otherProperty;
@end

@implementation MyModel
+ (NSArray *)indexedProperties {
    return @[@"indexedProperty"];
}

Encryption

This release has a lot of fixes for our encryption functionality. The biggest change is that we now support using encrypted Realms with a debugger attached to the process, and we now play nicely with most third-party crash reporters. The only caveat there are that you need to install the crash reporter before you first open an encrypted Realm, or you may get spurious reports of errors when the app didn’t actually crash.

We’ve also fixed a number of bugs with encrypted Realms, including crashes on ARM64, -writeCopyToPath:encryptionKey:error: sometimes not actually writing the entire file, and a crash after large commits.

The changes to support using encrypted Realms with a debugger attached also made it possible for us to run our entire test suite using encrypted Realms, which should greatly reduce future problems with them.

Improved Error Checking

We now throw exceptions in the following scenarios rather than crashing or behaving in confusing ways:

• Calling -beginWriteTransaction within a notification block which was triggered by another call to -beginWriteTransaction.
• Calling setEncryptionKey:forRealmsAtPath:, setSchemaVersion:forRealmAtPath:withMigrationBlock:, and migrateRealmAtPath: when a Realm at the given path is already open.
• Calling -[RLMRealm deleteObject:] or -[RLMRealm deleteObjects:] on objects which are not persisted in the Realm.
• Having RLMObject * or RLMArray<RLMObject> * properties on an RLMObject subclass, rather than pointers to the appropriate RLMObject subclass.
• Nesting RLMObject subclasses within functions in Swift.

Other Improvements

• The browser will no longer show objects that have no persisted properties.
• RLMSchema, RLMObjectSchema, and RLMProperty now have more useful descriptions.
• RLMArray now exposes an isInvalidated property to indicate if it can no longer be accessed due to the containing object being invalidated.
• Fixed a crash when calling createOrUpdate:inRealm: with linked objects that are not already persisted in the destination Realm.

We shipped a bunch of point releases with bug fixes between 0.90.0 and 0.91, so here’s a quick rundown of things fixed in those versions:

• Fixed incorrect results when using aggregate functions on sorted RLMResults.
• Fixed some assorted assertion failures.
• Fixed columns sometimes being dropped and recreated during migrations.
• Fixed incorrect column type assertions when the first Realm file opened is a read-only file that is missing tables.
• Made calling createInDefaultRealmWithObject:, createInRealm:withObject:, createOrUpdateInDefaultRealmWithObject: or createOrUpdateInRealm:withObject: a no-op if the argument is an RLMObject of the same type as the receiver and is already backed by the target realm.
• Throw an exception when adding an invalidated or deleted object as a link rather than just crashing.
• Throw an exception when calling createOrUpdateInRealm:withObject: when the receiver has no primary key defined.
• Fixed the browser treating RLMObject as a model object class.
• Fixed a crash when calling objectsWhere: with grouping in the query on allObjects.

Thanks for reading. Now go forth and build amazing apps with Realm! As always, we’re around on the mailing list, Stack Overflow, GitHub, or Twitter.