Core Data and Swift Best Practices Part 3

Welcome back to another episode of Core Data my young Core Data padawans. Remember how last time I said we were going to write the beginnings of a skeleton app? Well this time we are actually going to do it! But first… A little talk on attribute options. From there we’ll move to managed object subclasses ad finally *drumroll* we’ll begin setting up our stack!

When I last wrote I discussed the importance of Entities and Attributes. But we didn’t have a chance to dive into the additional options attributes possess that we might need to adjust in our demo app. We mark the date attribute as non-optional/indexed, and the color sequence attribute as non-optional.

When dealing with a non-optional attribute, there are a couple of things to take into consideration. First, non optional attributes have to have a valid value assigned to them in order to be able to save the data. marking an attribute as indexed creates an index on your underlying SQL database table (more on this later).

There are pros and cons to using such an index system. Using an index certainly speeds up the process of sorting/finding records by the attribute; but it comes at a cost of performance, particularly when one is inserting new records and some additional storage space. In our case, we’ll display the current status objects sorted by date, making it understandable to index the attribute. If you wanna learn more about indexes and dive deeper into their relationship with performance, comment or tweet at me! Would love to write more about them.

**Managed Object Subclasses **

Now that we’ve created the data model, we have to create a managed object subclass that represents the “Current Status” Entity in the code. The entity is ultimately just a description of the data that belongs to each status. To actually manipulate the data in our code we must create a class that possesses the properties representative of the attributes we defined in the entity.

A quick note about naming. Entities have names which always begin with a capital letter, further it’s best practice to name the classes by what they actually represent rather than what might be intuitive like “StatusEntity.” Our class will simply be called Status. Why such a hard line to the naming? Because an entity is very distinct from your run-of-the-mill class. And because we’re proper software engineers we ensure that are naming is precise and reflects that.

When you finally get to creating the class there’s two ways you can go about it. (1) You can use Xcode’s code generation tool. This works by navigating to the top tab and clicking

 (Editor > Create NSManaged Subclass..)

This is how I went about things at first to minimize the possibility of making mistakes. But upon further reflection I’ve come to the conclusion that one should simply write it by hand. It’s not much code, you only have to type it once, and there’s the advantage of being in full control of of how you write it. It also makes the process much clearer since it forces you to see how all the pieces connect.

Or Status Entity Should like this:

public final class Status: ManagedObjectModel {
@NSManaged public private(set) var date: NSDate
@NSManaged public private(set) var color: (UIColor)

The Superclass, ManagedObject, is simply an empty subclass of NSManagedObject:

public class ManagedObject: NSManagedObject{

Let’s explain what’s going on up here. We need the above because of the way generic type constraints work in Swift. There’s no need to delve too deep into this so for now you can just consider it to be equivalent to NSManagedObject.

The @NSManaged attributes on the properties in our class tell the compiler, “Hey, these properties are backed up by the Core Data attributes.” The `private(set)` access control modifiers signal that both properties are publicly readable, but not writeable. Core Data actually isn’t picky about such things, but if we explicitly note this in our class definition, the compiler will.

So why are our access control modifiers set to ensure that our properties are only readable? Because there’s no need to expose our attributes as writable to the world. We want to protect our data and only allow the helper methods we will later create to to insert new statuses with specific values upon creation. In short, only expose what you really need to expose.

**Catches Breath** Man that was a lot. Look for the next phase where we’ll set up our stack later this afternoon on the blog.

No Update Last Week — Will Update this Week

You may have noticed that I didn’t update last week. There’s a reason for that. Besides having to go through a flurry of interviews for a new job, I had a very close friend end their life. I was devastated. And so I didn’t feel like writing much.

I’ve got a lot coming down the pipeline so stay tuned! Oh and take care of your loved ones.

1 (800) 273-8255

Seriously. I know how it feels. I’ve been there. I’ve felt numb to it all too. But please, please, please believe me when I say it gets better. I don’t know you, but I care about you. I really do.

If you’re out there in cyberspace and ever need someone to talk to, please hit me up at Know that you always have an ear with me.

Core Data and Swift Best Practices Part 2

Welcome back to another exciting edition of, drumroll Core Data! We last left off with the an explanation of Core Data and an overview of its architecture. This time we’re going to actually begin writing the skeleton for a very simple app. Accompanying this skeleton will be a continued explanation of Core Data.

The last time I wrote I mentioned the possibility of multiple persistence stores and store coordinators. More often than not you’re not going to need that.

But since I last wrote I left an explanation of the precise role of the persistence store and persistence store coordinator rather opaque. This was intentional. This is because the persistence store family itself are rather opaque objects! Nevertheless it’s a very important piece that we’ll look into more detail later.

The last piece of the puzzle that we need to cover before embarking on our skeleton app is a more through explanation of the persistence store. An instance of the NSPersistanceStore

Data Modeling

Quick question. What is the role of core data? Don’t look it up! Try to recall what I discussed in the last entry: core data stores structures data. In order to use Store Data we need to create a model—or what backend developers commonly refer to as a schema.

There are two ways you can define this scheme. One can either define the data model via code. OR they may use Xcode’s native model editor. I would argue for use of the latter tool as it’s much easier to visualize; especially if you’re a Core Data newbie. Compound that with great tools such as MOGenerator, and you have a powerful way of quickly creating and deploying your data models.

To get started is easy. Create a empty Xcode template for an iOS or an OS X App, (for the purposes of this tutorial it won’t matter what) and create your data model by going to File > New and choose “Data Model” from the Core Data Section. If, however, you clicked on the “Use Core Data” checkbox when first creating the project an empty data model will have already been generated for you.

Of course, you don’t need to check this box. Actually for the purpose of this tutorial I suggest you don’t as I want you to create the generated boilerplate code from scratch anyways.

Once you select the data model, Xcode’s data model editor opens up and we can start doing the dirty work…

Entities and Attributes

Entities are the core lego blocks of our data model. Because they are so fundamental to our model we should think of entities as representing a piece of data that’s meaningful to the app. For example, in our case, we are going to create an entity called Current Status which has two attributes: one for a color representing a stage in your workflow, and one for the date of the snapshot. By convention, entity names start with uppercase letters; just like class names.

The best part of Core Data is that it supports a great deal of different data types right out of the box! Numeric types, strings, booleans, dates, binary data and even transformable types that store any object conforming to NSCoding standards, or any object you might have created a custom value transformer for.

For our Current Status entity we want to create two attributes: pne of type Date (named date), and one of type Transformable (workflow colors). Attribute names are typically represented with lowercase letters a la a class or a struct. The colors attribute holds an array of UIColor objects. Since NSArray and UIColor are both NSCoding compliant we can store such an array directly into a transformable entity (woo hoo!)

That’s all for now. Remember when I said last time that we would delve into some Swift code? Turns out there’s a lot more concepts we have to dive into before I can set you guys off with that. Stay tuned though. I plan to throughly flesh out the guide and release this week.

The Simple Programmer and the Quest to Market Oneself

Marketing is a dirty word in the tech industry.

We developers can be a proud bunch. We tend to believe–despite all evidence to the contrary–that the best idea should and always win. It can be frustrating to communicate this dissonance to my fellow developers, particularly when the truth of the matter is so obvious to me. So what’s a young developer to do? Give up and resign themselves to the status quo? Or maybe–just maybe–they should try to attack the problem in another way. Maybe they should demonstrate the importance of self promotion to their fellow devs by reaping its benefits firsthand. In the end that’s the path I chose.

Enter John Sonmez of the SimpleProgrammer.

I’ve never actually met John in person. Instead I heard his name while I was getting ready to submit an audition for the PluralSight series. After speaking with PluralSight Editor, Stephanie Evans, and exploring the PluralSight website his name came up:

I asked, “Hey Steph, who’s this guy with a million courses?”

She slowly smiled. “Oh him? That’s John Sonmez. …He’s actually a millionaire.”

My jaw dropped. ‘A millionaire dev who isn’t working for any member of the Big 4?’ I thought to myself. But how?

After doggishly stalking John’s blog for days it quickly became apparent why he was able to reach the level that he’s at. When the man isn’t coding and keeping up with technology he’s making use of all his non-work hours to promote himself and his business.

And he doesn’t just promote for himself, he teaches other devs how to reach the milestones that he’s reached. He does it through his website and through his free email series. I love this. Most successful people tend to hide how they’ve achieved success behind a series of paywalls and smoke and mirrors.

And that’s what I love about John. He doesn’t hide all the information he’s aggregated behind some sort of paywall (although he does have a training series that he sells). One can still reap a wealth’s worth of knowledge from the free content that is all available on the SimpleProgrammer. Truth be told I will purchase his books anyways because I’ve already benefited from the free material he has posted on his website.

I took his free email series on blogging and have already implemented many of his suggestions. I am now blogging once a week (and more when I get the chance). I’ve narrowed my focus to mobile development with a sprinkle of soft skills. I have a schedule of topics I’ll be writing on for the next few months.

For those of you who hesitate to write a blog because of fear for lack of topics, let me assure you from personal experience that this is the least of your worries. Once I sat down and decided on what I wanted to write I quickly realized I had too many things to write about and the actual battle would be finding time and remaining consistent. Something John comments on as well, coincidently.

Just implementing the few steps above has increased traffic to my site dramatically. I went from only about a few views a month to 300. In just one month!

I know, I know. You’re thinking, ‘I’m not some poser Kacheflowe. I care about my tech skills. How does blogging help me?’ To you I say, look at those developers most prolific and most well known in your community. Would you say that these developers lack the technical chops to tackle the problems we devs encounter everyday? Of course not! More often then not these are the same people you reference when trying out a new technology. So blogging consistently can increase your technical proficiency and credibility.

That’s all for now. I implore you to check out John’s site and think more about promoting yourself as a developer. This stuff matters.

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:

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:

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