What is Core Data? Core Data & Swift Best Practices Part 1

Ah yes. Core Data. The novice developer’s bane and the senior developer’s headache. Just mention Core Data to a room full of developers and hear the symphony of groans. Nevertheless, to consider oneself a proper iOS Developer she must learn to tame this component of iOS Development. The goal of this series is several fold: (1) Help you understand the architecture of Core Data (2) Ultimately help you understand what is happening “under the hood” of core data and (3) Give you a simple example app written in Swift to get you started with Core Data whilst giving you an idea of best practices.

First, Core Data is a framework. If there’s anything you take away from this write up, it should be the previous sentence. Core data is an object graph management and persistence framework. It allows you to work with data as objects, regardless of how they might be persisted to disk. It’s an abstraction; a layer. Why is this useful to us as developers? I’d argue that Core Data’s greatest strength is that it’s already available for us to use as developers. Apple maintains it, it’s been around for more than a decade, and it’s been battle tested. Additionally, it’s easier to handle pure data as an object in this OOP world of ours.

To actually handle these—-conventionally known as Managed Objects—Core Data conveniently sits between your application and a persistent store. Don’t think too hard about what that means. The persistent store is just what fancy-pants engineers call any form of data that survives—or persists—through a hardware reset. This falls into one of the following categories: a SQLite database, XML File (which, while can be manipulated by iOS systems, can’t be used as a persistent store), and/or a binary store. There’s one last potential—and ironically named—persistent store available and that’s the In-Memory store, but for the sake of length I won’t delve too deeply into that.

When I first started developing in iOS all this confused me. I thought to myself, ‘Okay then, what the heck is Core Data?’ Unfortunately, like many tech terms, Core Data has become a ubiquitous catch all meant to capture a larger, complex system. But think of what the meaning of the words, Core Data mean. It may be tautological but the core definition—pun completely intended—is nothing more than that: data at the core of your system and, subsequently, your application.

The Core Data stack—in its most simplest form—contains four pieces:

(1) The Managed Object (NSManagedObject)

(2) The Managed Object Context (NSManagedObjectContext)

(3) The Persistence Store (NSPersistentStore) and

(4) The Persistence Store Coordinator (NSPersistenceStoreCoordinator)

Our objects—when created—are referred to as Managed Objects. Because they are managed by Core Data they live in a specific context. In this case that is the Managed Object Context. At this point you’re probably asking, ‘Okay Kacheflowe that’s all well and good, but what is the Managed Object Context?’

The managed object context keeps track of its managed objects and all the changes you make to them, i.e. insertions, deletions, and updates. And each managed object knows which context it belongs to. Core Data supports multiple contexts, but let us not get ahead of ourselves: for most simple setups, like the one in this series, we will only use one.

The context connects to a persistent store coordinator. It sits between the persistent store and the managed object context and takes a coordinating role between these two. As with the contexts, you can also use a combination of multiple persistent stores and store coordinators.

This all might sound like a jumble to you so I’ve included a chart to help you visualize. Below you’ll find a good visual overview of Core Data’s architecture:

Screenshot 2015-08-05 23.14.49

Core Data’s greatest achievement perhaps is that it makes relationships between objects very simple. One to many or many to many. You’re essentially just manipulating sets. Without Core Data you’d have to communicate with SQLite directly; if that were the case you’d be forced to create a lookup table to relate your objects. And as anyone who’s bothered with such an endeavor might know, that can be a bit of a pain to maintain (coughs Not that I’d know anything about that).

That’s all for now. I don’t really like delving into code until I feel there’s sufficient understanding of what’s happening under the hood. In Part 2 we’ll actually begin writing the skeleton for our example app.

My Scholarship Essay to CocoaLove

So I just came back from 360iDev and man did I leave inspired. It’s transformed the way I look at my career path and what’s important to me whilst traveling on the road of software development. I left feeling energized and craving for more. I found out about another Cocoa conference happening soon and immediately began scheming a way to get in. Because of the price point I wouldn’t be able to afford to attend but I found out that there’s a scholarship program. Below you’ll find my submission for consideration.

Dear CocoaLove Committee,

My name is Basel and I am an iOS Developer. I’ve shipped four apps. I continue to work on my craft every single day. In my spare time I’m working on an application that aims to help broke, indie bands secure instruments and building my first kernel with OS (fun obvious fact: the latter is no easy task). I’m also the head of the Denver Swift Heads Developer Group. Now that that boring stuff is out of the way, let’s get to the interesting stuff. Namely, why do I want to attend CocoaLove?

CocoaLove is a unique conference in that it is not code focused. When Curtis Herbert initially told me this at 360iDev in Denver, CO I was skeptical. The engineer in me immediately thought, “What else could be important besides the technology?”

Well, it turns out that there’s a lot. An incredible amount. In fact, I might argue that those topics typically covered at a place like CocoaLove—Mike Zornek’s talk on Mentoring, Souroush Khanlou’s talk on Fear and Doubt, and Laura Savino’s talk on productive ways to engage poor coders—are even MORE important than learning things like best practices in Swift for Core Data or learning about the latest and greatest in 2.0. These sorts of “soft” skills; these “soft” topics are what leads to success in learning and building oneself with the hard skills.

And there lies the paradox. How can one develop their hard skills if they feel intimidated by those around them? How can they feel comfortable in the field if they don’t have a mentor? We don’t talk about these things as developers in regular conferences despite their tremendous importance. How are we supposed to include those who are underrepresented (i.e. women and minorities) if they’re terrified by the people who are supposed to be their peers? How can people who are new to field feel welcome if their peers ridicule them for their code—especially in a highly sensitive state where one is learning the massive frameworks of iOS?

These are the questions and issues that CocoaLove—to me—attempt to address. And I love it. It’s an area that is not covered by any other conference. I can learn how to build efficient code via screencasts. But where else could I learn how to better myself as both a developer and a human? At CocoaLove we get to see a side of members of our community that we never get to see: vulnerability.

Imagine that. Vulnerability amongst engineers. It’s almost as if we’re humans and not individuals perched over desks in the depths of some dark, unknown basement. That’s what CocoaLove would give me: A looking glass into the human side of members of our community.

And that’s what excites me about this community. Its capacity for introspection and empathy. There are all these exciting technologies constantly rolling out, and yet we’re able to retain our humanity.

And I want to be part of that process. I want to be, as Janie Clayton said in her interview on the Ray Wenderlich Podcast, “contribute to creating a community that makes our industry a fun, accepting, and accessible place for people to be a part of.” I too want to be an industry thought leader on Core Data, Autolayout, and/or Swift, but honestly, the former is of even greater performance. I want to be the engineer who remembers his humanity. Because that’s what we’re all here for right? To make life better.

Looking forward to hearing from you,

If you’re interested in attending CocoaLove check out their site: http://cocoalove.org/

Why do Developers hate Core Data?

Core Data

If you follow my twitter (@kacheflowe) you probably already know that I’m a Core Data nerd. Why?

Core Data tends to be the bane of most developers’ existence. Talk to any group of iOS Developers and mention the words, ‘Core Data’ and wait for the symphony of groans. Core Data is complex. Complex technology always fascinates me (hence why I’m in the industry that I’m in). But more than anything, I’m interested in breaking down Core Data for other developers. 

The irony of Core Data is that—like most things—it’s not so bad once broken down. Certainly there are a great deal of simultaneously moving parts, but once one sits down and takes the time to understand, it’s no more horrific than OpenGL or assembly code.

I’m wrapping up my article on what’s new in Core Data in iOS 9 so look forward to it!


In most developer’s defense, oftentimes the issue isn’t necessarily core data, it’s core data’s interactions with other technologies. The first thing that comes to mind is iCloud. If you really want to learn about how much of a mess that Core Data interacting with iCloud is, check this podcast out: http://www.imore.com/debug-12-icloud-core-data-sync

It’s not only eye-opening, but groan inducing.