Technical Differences Between CoreData and Realm Databases

Making the decision on the right database while building a mobile service is more crucial than it sounds.

Comparative analysis of Realm and Core Data characteristics shall reveal specific technical details on given solutions distinctions. Exploring from different angles the databases in question, we’ll examine diverse aspects in detail.

Setting up and Initializing the Databases

Our task is to identify certain procedures of Realm and CoreData initialization, as well as configuration.
The first step is a model file creation to combine various essential schemes with the necessary elements enabling a smooth and productive process of the service developing. Xcode serves exactly to undertake mentioned actions without unnecessary efforts enjoying a specific interface.
One of CoreData’s benefits is the availability of a graphic chart which assists in initiating relationships between given schemes, whether it’s one to one connection, one to many or any other options. Such peculiarity encourages developers to implement CoreData widely considering it as the most trustworthy framework for mobile building.
Unlike CoreData, Realm cannot boast of providing the described opportunities, thus, causing certain difficulties when dealing with massive databases that have numerous linkages between their schemes.
Applying CoreData you’re able to check all interrelations and connections with the aid of graphic charts, which will take several seconds only. And with the Realm platform to see the described above you must read the coding.
One more great news: after the iOS 10 version has been released, the NSPersistentContainer element is now available to build NSManagedObjectModel, NSManagedObjectContext, as well as NSPersistentStoreCoordinator, which significantly facilitated the process.
It’s simple enough to run the persistentContainer = NSPersistentContainer (name: “ModelName”) element in order to manage app data storing and the framework docs and files.
To fully understand what is Realm database, and what CoreData represents we shall proceed to the next point.

Building the model

CoreData

As mentioned earlier, the Core Data model shall be created while the framework initialization. The interrelations of schemes could be established at this stage as well.
After the required configurations are done, it’s time to work on the relevant class for every scheme in the project, which could be attained by means of built-in Codegen.

The 3 methods to build the class:

Manual creation

Following the detailed guidelines for making a class, you’ll end up having 2 classes (ClassName+CoreDataClass, as well as ClassName+CoreDataProperties).

Class Definitions

Being a default method for building Xcode classes, they shall be created automatically. However, being retained in Xcode folder under the name “Derived Data”, you’re unable to see them directly. Remember never to modify automatically-generated documents, since they’re under Xcode total control, thus, they’re being rewritten independently for every next project.

Category & Extensions

Such an approach represents a cross between the above two methods. Being stored in the Derived Data folder, the first-ever ClassName + CoreDataProperties.swift class is created by default, thus, it’s free. And the next ClassName + CoreDataProperties.swift class, in its turn, requires to be paid for.

Realm

The Realm creation of the model is carried out in a traditional way.
Primarily, the task is to insert a new class that would inherit from the Object, meaning, a specific class for model creation. The further step is to insert its characteristics into the model and to mention the characteristics name together with data kind.
Check the table for more detailed information.

Type	Non-optional	Optional
Bool	dynamic var value = false	let value = RealmOptional<Bool>()
Int	dynamic var value = 0	let value = RealmOptional<Int>()
Float	dynamic var value: Float = 0.0	let value = RealmOptional<Float>()
Double	dynamic var value: Double = 0.0	let value = RealmOptional<Double>()
String	dynamic var value = «»	dynamic var value : String? = nil
Data	dynamic var value = Data()	dynamic var value : Data? = nil
Date	dynamic var value = Date()	dynamic var value : Date? = nil
Object	N/a: must be optional	dynamic var value : Class?
List	let value = List<Class>()	N/a: must be non-optional
LinkingObjects	let value = LinkingObjects(fromType: Class.self, property: «property»)	N/a: must be non-optional

Building objects

CoreData

When there’s a need to build and save a new Object, you’ll require persistentContainer. Look at the example:

Database code

And it’s done.
Nonetheless, the process could be performed in a different way, which would be more accurate, allowing produce better outcomes. However, you’ll need to code more.
You could make a particular class called “StoreManager”, for instance, building it by means of the Singleton pattern.

Database code

Then, it’s the right moment to insert a certain approach for saving data into the database.

Database code

Realm

When an object isn’t yet included in the framework, it could be easily applied as other objects in the app. The adding and further changing shall be carried out as part of the transaction through the transactionWithBlock approach or applying one of its analogs, say, beginWriteTransaction or commitWriteTransaction techniques.
For the model description, it’s needed to take a class that would be inherited from the Object, then insert the required characteristics into it.

Database code

Making the object:

Here’s an example of how to make a simple program to add, delete, or retrieve data from an open-source database.

Database code

Enquiries

They could be applied for locating the objects that contain a specific value in the names.

CoreData

To set it all up, you could use NSManagedObjectContext for choosing what Entity to apply for extracting the data. And the next step is database inquiry creation and data retrieval.

Database code

When adding NSPredicate into the inquiry, you’ll set up extra data filtering.

Database code

Realm

We shall apply the StoreManager built earlier, and to supplement it with a method to return all objects.

Database code

And then you insert another method to return the earlier-filtered objects by the name.

Database code

Monitoring modifications

CoreData

Applying the NSFetchedResultsControllerDelegate protocol, CoreData allows monitor the changes on insert/delete/move/update.

Database code

Realm

The framework applies notifications to track any modifications.

Database code

To stop the process, you’ll only have to unsubscribe:
notificationToken.invalidate()

Well, now you would agree that each database discussed has both advantages and disadvantages. The greatest Realm benefit compared to CoreData is the simplified entry procedures and the simplicity in application. Thus, to be satisfied with the final solution you have to decide in every single case what framework will comply with your requirements more effectively.