Computers are incredibly fast, accurate, and stupid. Human beings are incredibly slow, inaccurate, and brilliant. Together they are powerful beyond imagination.
—Albert Einstein
What Have We Learned Till Now?
It was a long journey!
And that’s obvious – Core Data not only is an extensive framework but also represents the data layer , and as a result, it plays a significant role in your app architecture.
This book is built upon three parts – the basics (how to set up an excellent Core Data infrastructure), implementation (performances, predicates, concurrency), and advanced features (custom data stores , SwiftUI, and integrations).
Testing
Swift Package Manager integrations
Data model configurations
Parent entities
These are just a tiny part of what’s left, and the way I see it, it is okay.
As I said in one of the chapters, the book's primary goal is not to be massive documentation or a huge folder of tutorials.
Its goal is to unleash the power of Core Data for those who are afraid to start or were frustrated in the past with how they worked with Core Data.
How to Start?
I think that’s the tricky question.
Understand your needs (is Core Data even relevant for you?).
Design your data model (based on the existing app).
Implement Core Data to an existing project.
Understand Your Needs
Using Core Data is suitable for many projects, but not all of them. You should analyze your requirements from your data layer and conclude your decision.
What types of data are you planning to store?
What amount of data are you planning to hold?
What are the relationships between your entities?
What kinds of queries are you planning to perform?
Do you need to share your database with other platforms?
What is the link between your data and the UI?
The preceding questions can assist you in understanding what your needs are.
For example, if you need to import many objects from the same entities and perform standard search queries, Core Data may not be the best solution for you.
Core Data can perform the task efficiently, but its strengths are laid in different aspects.
For example, relationships between your entities are a big part of Core Data, and in the preceding example, there are no relationships at all.
Also, because the main action is searching, it looks like it’s not going to be in your app data layer but rather a dedicated database to dig in.
Core Data performs best when its role is to be your app data layer and serve the app business logic.
In this case, it is better to use a database like SQLite.
Design Your Data Model
Okay, so this step is not related solely to Core Data.
You should design your data model no matter what data framework you plan to implement.
This is the part where you need to understand your app business but mostly understand how to take an existing app and design your data model.
Sometimes your app is not in a state where your data model is clear.
Sounds weird?
Anything can happen in apps that have existed for a few years and had different iterations that caused their app data model to be a complete mess.
For example, some apps use JSON files to store different data types and SQLite for others.
This situation can happen due to different development teams that worked on the project and decided to “start a refactor” and haven’t finished.
Another aspect of data model issues can be its compatibility with the UI screens.
The main goal of your data model is to serve the UI. At this stage, your current local data structure may not be suitable for your business logic and the UI.
Replicating that problem with Core Data is not a good idea, and you should think about how to take the existing structure and transform it into something more practical.
Implementing Core Data
After you understand your needs and have a basic understanding of your data model , your next move will be to implement Core Data .
That is a scary and sensitive step, and to verify this move is going faultless, you need to build a plan that transfers your app to work with Core Data.
The first step is to ensure you have enough tests covering the significant parts of apps, focusing on integration tests.
You can decide to implement only new entities in Core Data while transferring old entities overtime. This has a lot to do with how your app evolves and how the relationships between your entities are connected.
Migrating all current data to Core Data is probably the fastest way of working, but it is also hazardous. The problem, in this case, is not only migrating a significant amount of data but also changing how your business logic works.
Another option would be building a custom data store . A custom data store preserves the current persistent store you work with, but requires you to change your business logic to work with Core Data. That can be a step toward completing Core Data migration in the future.
The preceding options list can provide you with some ideas for dealing with this complicated mission.
It is also derived from the current state of the project, resources, and time.
Where to Go from Here
It’s a big book, but it’s not the bible. You must always doubt what you are reading.
Explore Core Data further by reading documentation, watching WWDC video sessions, and testing the framework yourself.
Implement Core Data responsibility slowly and consistently according to your needs.
Remember that Core Data is a tool. A great tool! But it is not the goal – your app quality is the goal.
Thanks
It has been a pleasure for me to write this book and to unleash Core Data with you. I hope you had a great reading, and thanks!