A common mistake developers new to Core Data make, is not taking the time to learn the basics of the framework. If you don't know what Core Data is, it is very hard to understand the ins and outs that make the framework tick. In this post, I would like to spend a few minutes exploring the nature of Core Data and, more important, finding out what Core Data is and is not.
Core Data is a framework developed and maintained by Apple. It has been around for more than fifteen years and first made its appearance on macOS with the release of macOS Tiger in 2005. In 2009, the company made the framework available on iOS with the release of iOS 3.
Core Data is the M in MVC, the model layer of your application. Even though Core Data can persist data to disk, data persistence is an optional feature. Core Data is first and foremost a framework for managing an object graph.
Core Data is first and foremost a framework for managing an object graph.
You have probably heard and read about Apple's persistence framework before reading this Core Data tutorial. That means you may already know that Core Data is not a database and that it manages your application's object graph. Both statements are true, but what do they mean?
Managing an Object Graph
As I mentioned earlier, Core Data is first and foremost an object graph manager. An object graph is nothing more than a collection of objects that are connected with one another. The Core Data framework excels in managing such an object graph.
The Core Data framework takes care of managing the life cycle of the objects in the object graph. It can optionally persist the object graph to disk and it also offers a powerful interface for searching the object graph it manages.
But Core Data is much more than that. The framework adds a number of compelling features, such as input validation, data model versioning, and change tracking.
Should You Use Core Data?
Even though Core Data is a perfect fit for a wide range of applications, not every application should use Core Data. If you need a lightweight model layer, then Core Data should not be your first choice. There are many lightweight libraries that provide this type of functionality.
If you are looking for a SQLite wrapper, then Core Data is also not what you need. For a lightweight, performant SQLite wrapper, I recommend Gus Mueller's FMDB or SQLite.swift. These robust, mature libraries provide an object-oriented interface for interacting with SQLite.
Core Data is an excellent choice if you want a solution that manages the model layer of your application.
SQLite or Core Data
Developers new to Core Data are often confused by the differences between SQLite and Core Data. If you wonder whether you need SQLite or Core Data, then you are asking the wrong question. Remember that Core Data is not a database.
SQLite is a database and it is an excellent fit for mobile applications. It is lightweight and incredibly performant. Even though SQLite is advertised as a relational database, it is important to realize that the developer is in charge of maintaining the relationships between records stored in the database.
Core Data goes much further. It provides an abstraction that allows developers to interact with the model layer in an object-oriented manner. Every record you interact with is an object. Core Data is responsible for the integrity of the object graph, ensuring the object graph is kept up to date.
Drawbacks
Even though Core Data is a fantastic framework, there are several drawbacks. These drawbacks are directly related to the nature of Core Data. Core Data can only do its magic because it keeps the object graph it manages in memory. This means that it can only operate on records once they are in memory. This is very different from performing a SQL query on a database. If you want to delete thousands of records, Core Data first needs to load each record into memory. Several years ago, Apple added support for batch operations to make some of these tasks easier and much more performant. It goes without saying that this results in performance issues if done incorrectly.
Another important limitation is the threading model of Core Data. The framework expects to be run on a single thread. Fortunately, Core Data has evolved dramatically over the years and the framework has put various solutions in place to make working with Core Data in a multithreaded environment much safer and much easier.
Should You Use Core Data
For applications that need to manage a complex object graph, Core Data is a great fit. If you only need to store a handful of unrelated objects, then you may be better off with a lightweight solution or the user's defaults system.
