Avi Tsadok - Unleash Core Data: Fetching Data, Migrating, and Maintaining Persistent Stores

This Apress imprint is published by the registered company APress Media, LLC, part of Springer Nature.

The registered company address is: 1 New York Plaza, New York, NY 10004, U.S.A.

Nothing has ever been achieved by the person who says, It cant be done.

Eleanor Roosevelt

Years ago, when I made my first steps in iOS development, I remember how I bumped into Core Data for the first time.

I also remember how immature iOS development was. No ARC, Auto Layout wasnt out yet, and Xcode was still a multiple-window IDE with iOS SDK version 3 as the most recent deployment version.

But I still remember the feeling I had. I was fascinated by how simple it was to use Core Data.

No SQL queries. No complicated setup or looping the SELECT results.

Core Data felt like magic, as if the data was just there when I needed it and in the format I needed.

But after a while, issues came up.

Weird crashes, concurrency issues, performance, migrations, and complicated predicates.

What I didnt know was that these issues werent only my problem.

Stack Overflow and Apple Developer Forums were full of complaints and frustrated users.

After years of development, I understood something about Core Data its one of the most sophisticated, intelligent, and essential frameworks in iOS SDK. And while Core Data looks simple at first glance, it hides many secrets underneath we need to unleash to use it right.

Thats why I called my book Unleash Core Data.

Why did I choose to devote a whole book just to talking about managing a data store?

There are a couple of reasons.

A standard application has three primary layers UI, business logic, and data layer.

In most cases, our data structure is a refined representation of our app business.

Think about it our data structure defines not only the main entities our app deals with but also their relationships with each other.

Also, the data structure is often optimized for our UI usage.

So you can derive from what Im saying that your data layer is the foundation of your app. UI is important, but it is nothing without the data underneath.

And dealing with your data layer is like touching the core of your business. Its a fascinating world!

Your local data store is the soul of your app. When you think of your app architecture, your data layer is the only one that isnt static and gets filled as your app usage grows.

It looks different from one user to another and holds the user's most private data.

Music apps contain the user library. To-do apps have the user's personal tasks, and word processing apps include the user's personal documents.

And because of that reason, the data layer is so important. A problem with the UI layer may cause a weird experience on the screen. But a problem with the data layer can be devastating.

Many mobile apps that use a local store eventually sync their data to a backend server.

So the data isnt just the structure of your business. Its also what we need to send out from the app and keep in the cloud.

The structure and behavior of our store need to consider a backend server at the end of the road, and thats another dynamic dimension of what Core Data is.

As a layer that is bound to the UI on one side and linked to your back end on the other side, Core Data plays a crucial role in your app architecture.

Starting to talk about Core Data is like starting from the end. First, we need to understand the problem Core Data was trying to solve, and in doing that, we need to go back to the beginning, back then in the early 1990s. (Yes! 30 years ago.)

Object-oriented programming has existed for decades, but only in the early 1990s has it become the dominant programming paradigm for most developers.