Watch this episode for free — or access the full course as a Professional Subscriber. Learn more here
Core Data: Fundamentals
Part 1: The Core Data Stack Managed Object Model
— iOS & Swift

Lesson Complete

Play Next Lesson

Managed Object Model

Understand how Core Data represents an app’s data model using managed objects


When you use the RocketLaunches app, you need a way to model the concept of a launch. You could create a Swift type using a struct or a class

This is how you would normally do it, but creating instances of this class isn’t sufficient to store or persist the data permanently.

One way you could handle this is to write the instances of this type to a file on the disk when the you call the save method.

You could have the type adopt the Codable protocol and whenever you want to save, you could use a PropertyListEncoder to encode the data as a plist.

Unfortunately this approach would only take you so far. When retrieving the launches from the plist file, you would have to fetch them all at once. This is because there’s no way for you to easily decode partial documents. You would also have to figure how to search this file and update entries.

Even worse, creating relationships between types would be quite difficult. Imagine that you want to add launches to specific lists. You could create a List type that stores a reference to each launch as an array of ids, but how do you easily and quickly fetch launches that only belong to a particular list?

At this point you want to figure out how and where to store this particular data instead of focusing on your app’s logic which is far more important.

With Core Data you don’t use plain Swift types to model your data - instead you use a managed object. A managed object looks and feels like a Swift class but you should think of it more as a representation of the data held in the persistent store.

Instead of being a specific type, a managed object is a subclass of NSManagedObject and is more like a generic container that we can store our data in - much like a dictionary.

When creating managed objects you can specify what kind of shape you want the data to take and Core Data provides a programmatic interface to interact with the underlying generic container. What does that mean?

Instead of creating objects directly in code, Core Data provides a visual interface to define the types that you’ll use to represent your data. Core Data refers to these types as Entities. So for example, you could use this visual editor to create the Book entity.

Under the hood Core Data doesn’t actually create an actual type - just a generic container that uses keys and values to store data. It would be a pain though if that’s how you had to interact with the object, not to mention very error prone. Instead Core Data provides an interface for you that restricts access to the underlying data using properties on the subclass.

In this way it feels like you’re working with a Book, Author or RocketLaunch type. Core Data deals with the mechanics around saving those types under the hood.

Since these are generic containers, how does Core Data know which table in the underlying store maps to which type? When creating an instance of these types you use an entity description which specifies an entity’s name, properties and the class that represents it. This object is then used to keep the convenience code that Core Data has created for you and the underlying stores in sync. You won’t worry about this part too much though because you won’t be interacting with the entity descriptions directly.

Let’s look at the hypothetical example introduced earlier - an app to record the books you’re reading. In this particular case you would have a separate entity to represent a Book, Author and Genre. All the managed objects together comprise the managed object model and is the object graph manager aspect of Core Data.

Defining the managed object model is the first part of working with a Core Data stack, and the better you define your managed object model, the easier it is to work with these objects, as Core Data can provide some rich support.

So that’s the first part of the stack - the object graph layer, represented here as the managed object model. In the next episode, let’s talk about the managed object context.