In the previous episode, we used the NSManagedObject class to represent and interact with records stored in the persistent store. This works fine, but the syntax is verbose, we can't take advantage of Xcode's autocompletion, and type safety is also an issue.

If we want to access the title of the note record, for example, we need to invoke value(forKey:) on the record and cast the result to a String object.

if let title = note.value(forKey: "title") as? String {
    print(title)
}

This isn't pretty and it gets old very quickly. Fortunately, there's a solution, subclassing NSManagedObject.

Code Generation

Prior to Xcode 8, developers needed to manually create subclasses for each entity. This is no longer necessary. As of Xcode 8, there's a much cleaner solution. Revisit the data model and select the Note entity. Open the Data Model Inspector on the right and take a look at the Class section. The Codegen field is the setting we're interested in. As of Xcode 8.1, this is set by default to Class Definition.

The possible options are Manual/None, Class Definition, and Category/Extension.

By setting it to Class Definition, Xcode automatically generates a NSManagedObject subclass for us. These subclasses are stored in the DerivedData folder, not in the project itself. And that's a good thing. We don't want clutter the project with files Xcode automatically generates.

The default setting is Class Definition, which means that we can already access a class named Note without making any changes. Swift adds even more magic to Core Data and NSManagedObject subclasses. Let me show you what that magic looks like.

Convenience Methods

Because the Note class knows what entity it is linked to, the initializer no longer requires an NSEntityDescription instance. We only need to specify the managed object context the managed object is inserted into.

// Initialize Note
let note = Note(context: coreDataManager.managedObjectContext)

Populating the note record is concise, type safe, and we benefit from Xcode's autocompletion. This is a significant improvement.

// Configure Note
note.title = "My Second Note"
note.createdAt = Date()
note.updatedAt = Date()

But notice that the properties of the Note class are optionals. Why is that?

It's important to understand that the optionality of the properties has nothing to do with the Optional checkbox in the Data Model Inspector. These are separate issues.

Why are the properties optionals? When a managed object is created, the value of each property is set to nil. This is only possible if the properties are optionals. It's that simple.

I agree that this is unfortunate, but that's the current state of Core Data. The framework started its life as an Objective-C framework and this is a side effect when it's used in combination with Swift.

In Objective-C, this isn't an issue. In Swift, every property of a class or struct needs to have a valid initial value by the time the instance is created. And that means that the default value of a property of a managed object is nil hence the optionality.

What to Remember

What I want you to remember from this episode is that an NSManagedObject subclass is automatically created for every entity as of Xcode 8.1 and that the optionality of the properties of an NSManagedObject subclass isn't linked to the Optional checkbox in the Data Model Editor.

We now know enough to continue building Notes. In the next episodes, we add the ability to create, read, update, and delete notes.