Hallo vrienden, Leo hier. Today we will explore iOS system design with SQLite and Core Data.

Have you ever found yourself in a pickle trying to decide whether to use SQLite or Core Data in your next project?

Well, you’re not alone.

Lately, I’ve been doing a lot of thinking about SQLite and Core Data for iOS development, and I must admit, I was struggling to understand which one to choose. Both technologies have their own unique strengths and weaknesses, and figuring out the best fit for what situation has become quite the challenge.

So, I decided to dive deeper into each of them, exploring their features, use cases, and how they stack up against each other.

In this article, we’ll dive into the world of SQLite and Core Data, exploring what they are, why you might choose one over the other, and even throw in some code samples for good measure.

Did you know that SQLite was invented in 2000? D. Richard Hipp designed SQLite in the spring of 2000 while working for General Dynamics on contract with the United States Navy. Interesting how a well-made foundation technology can stay with us for such a long time. Has been a long time since I started to talk about architecture.

The architecture topic is infinite, you can start reading about that in this article “how to create SPM modularizations in SwiftUI“, where we separate the onboarding into a totally different module of your app. If you are a fan of design patterns you could learn one thing or two on how to implement Memento in a SwiftUI app. The code examples are well-structured and easy to follow, making it easy for readers to apply the pattern in their own projects.

Let’s get started! But first…  


Special Thanks

I want to thank the last blog supporter Reed. I can’t thank you enough for your constant support and enthusiasm for my blog. It’s people like you who make this adventure worthwhile. Your encouragement has been invaluable!

If you enjoy the content here, please consider support the work on buy me a coffee. Thank you all!


Painting of The Day

Today’s artwork is called Nautical Still Life”, it is a 1953 piece from Jean Metzinger.

Jean Dominique Antony Metzinger (1883-1956) was a French painter and writer who was a prominent figure in the development of Cubism. Metzinger’s work was characterized by his innovative use of geometric forms and bold colors to represent objects and scenes in a non-representational way.

He was part of the first wave of Cubist artists, along with Pablo Picasso and Georges Braque, and his work played a key role in the development of the movement. 

I chose this painting for today because dealing with system designs is like adding building blocks to an app.


The Problem

You have to choose between SQLite and Core Data as your persistence provider.

The angle that I want to explore in this article is more a system design point of view than an implementation one. Lately, I was learning a lot about system design in mobile environments.

Some of the main concerns related to system design interviews about iOS development include:

  1. Scalability: The ability of the app to handle increasing amounts of data, traffic, and users over time.
  2. Performance: Ensuring the app is responsive, fast, and doesn’t consume too many device resources like battery, memory, and processing power.
  3. Storage: The systems that you will use to store data. SQLite, Realm, Core Data, File System, User Defaults, etc.
  4. Security: Ensuring user data is protected, encrypted, and not vulnerable to attacks or breaches.
  5. Architecture: Choosing the appropriate software architecture for the app, such as MVC, MVVM, or VIPER, and ensuring it is modular, reusable, and easy to maintain.
  6. APIs and third-party integrations: Designing the app to interact with external APIs and third-party libraries in a secure and efficient manner.
  7. User experience: Ensuring the app is intuitive, easy to use, and accessible to a wide range of users.
  8. Testing: Designing the app with automated testing in mind, to ensure that new features and updates are thoroughly tested before being released to users.


All of these should be taken into consideration when you are designing your new application. The good thing is that we have great tools to cover each one of that concerns and storage is the main topic today.  


What’s SQLite and Why Use It?

SQLite is an open-source, self-contained, serverless, and transactional SQL database engine. It’s lightweight and doesn’t require a separate server process or setup, making it an excellent choice for embedded systems and mobile devices.

In iOS development, SQLite is often used for applications that require a simple and efficient way to store and manage data.  


Reasons to choose SQLite

There are three main reasons to choose SQLite:

  1. Lightweight and minimal setup: SQLite is perfect for small to medium-sized applications that don’t require complex data manipulation or relationships.
  2. Cross-platform compatibility: SQLite is supported on various platforms, including Android and iOS, allowing for easier sharing of data between platforms.
  3. Direct SQL queries: If you’re comfortable with SQL and prefer writing raw queries, SQLite is the way to go.


The next thing to do is to take a look at how a simple insertion query would be in SQLite.  


SQLite Code Example in Swift

Now, let’s check out a code sample to see how you’d work with SQLite in your iOS app:

import SQLite3

// Open the database
var db: OpaquePointer?
if sqlite3_open("myDatabase.sqlite", &db) != SQLITE_OK {
    print("Error opening database")

// Create a table
if sqlite3_exec(db, createTableQuery, nil, nil, nil) != SQLITE_OK {
    print("Error creating table")

// Insert data
let insertQuery = "INSERT INTO myTable (name, age) VALUES ('John Doe', 25)"
if sqlite3_exec(db, insertQuery, nil, nil, nil) != SQLITE_OK {
    print("Error inserting data")

// Close the database
This looks like pretty much backend development, right? But if you need something that needs data relationships, you have pretty much what you need here.
In my opinion, the main selling point of using SQLite directly is the capability of being multiplatform. This feature only can be a deal breaker for companies/individuals that want to maintain the same code for the storage layer both in Android and iOS applications.

What’s Core Data and Why Use It?

Core Data is a powerful framework provided by Apple for managing an object graph and persisting data in iOS, macOS, watchOS, and tvOS apps. It’s not a database, but rather an object graph management framework that can use SQLite as one of its persistent store options.
Core Data excels at managing complex object graphs with multiple entities, attributes, and relationships.  

Reasons to choose Core Data

I could think in mostly three big reasons to choose Core Data:
  1. Object-oriented approach: Core Data allows you to work with objects instead of raw SQL, making it more suitable for complex data models and easier to integrate into your app’s code. Everything is an object, the queries, the results, the models, etc.
  2. Advanced features: Core Data comes with built-in support for features like input validation, data model versioning, change tracking, and more.
  3. Seamless integration with Apple’s ecosystem: As an Apple framework, Core Data is fully integrated with Swift and other iOS development tools, offering a more seamless experience.


Let’s check in the code how is to deal with core data.


Using Core Data in The Code

Now let’s review the same example above with the Person that has Name and Age attributes but this time in Core Data.
Here’s a sample to help you understand how Core Data works in iOS development, check the code below:
import CoreData

// Set up the Core Data stack
let appDelegate = UIApplication.shared.delegate as! AppDelegate
let context = appDelegate.persistentContainer.viewContext

// Create a new managed object
let entity = NSEntityDescription.entity(forEntityName: "Person", in: context)!
let person = NSManagedObject(entity: entity, insertInto: context)
person.setValue("John Doe", forKey: "name")
person.setValue(25, forKey: "age")

// Save the changes to
the managed object context
do {
    try context.save()
} catch {
    print("Error saving data")
One thing still remains…

So, Which One Should You Choose?

Now that we’ve explored both SQLite and Core Data, it’s time to decide which one is right for your iOS project. Here are some guidelines to help you make the call:
  • If your app requires a simple, lightweight solution for data storage and management, and you’re comfortable writing raw SQL queries, SQLite is the way to go.
  • If your app deals with complex data models with multiple entities, relationships, and attributes, and you prefer working with an object-oriented approach, Core Data is the better choice.


Ultimately, the decision between SQLite and Core Data comes down to your app’s specific needs, as well as your personal preferences and comfort level with each technology.
Both have their own set of advantages and use cases, so choose the one that best fits your project’s requirements.  

Interview Questions About Core Data and SQLite for iOS

I’ve prepared some interview questions that you could be asked in the context of mobile system design interviews when discussing persistence layers.


What are the main differences between SQLite and Core Data in iOS development?

SQLite is a lightweight, open-source relational database engine, while Core Data is an Apple framework for managing object graphs and persisting data. SQLite is more suitable for simple data storage and direct SQL queries, whereas Core Data is better for managing complex object graphs with multiple entities, relationships, and attributes in an object-oriented way.  


How does Core Data handle data persistence?

For iOS, Core Data can use multiple types of persistent stores, including SQLite, binary, and in-memory stores. It manages the object graph’s life cycle, optionally persists the object graph to disk, and provides a powerful interface for searching and managing the object graph.  


Why would you choose the Binary Persistence type with Core Data?

You might use the binary store if you want store writes to be atomic.  


Is Core Data Secure to add sensitive user data?

No, Core Data doesn’t guarantee safety for persistent stores and can’t detect if files data store files were changed maliciously. The SQLite store is a bit more secure than XML and binary stores, but it’s not completely secure either. Keep in mind that metadata archived data can also be tampered with separately from stored data.  


When should you choose SQLite over Core Data in an iOS project?

You should choose SQLite over Core Data when you need a lightweight, simple data storage solution, prefer writing raw SQL queries, or require cross-platform compatibility. SQLite is great for small to medium-sized applications with basic data storage and manipulation needs.


What are some advantages of using Core Data in iOS development?

Core Data offers an object-oriented approach to data management, built-in features such as input validation, data model versioning, and change tracking, and seamless integration with Apple’s development ecosystem. It is especially useful when dealing with complex data models and relationships between entities.


How does Core Data handle relationships between entities?

Core Data allows you to define relationships between entities using relationship properties in the data model. It manages these relationships as part of the object graph, enabling you to create, update, and delete related objects while maintaining the integrity of the object graph.


Can you use SQLite in combination with Core Data?

Yes, Core Data can use SQLite as one of its persistent store options. When you configure a Core Data stack, you can choose to use an SQLite database as the backend for data persistence. However, it’s important to remember that the database schema used by Core Data is specific to the framework and might change.


What is the learning curve like for SQLite and Core Data in iOS development?

SQLite has a relatively low learning curve for developers familiar with SQL, while Core Data has a steeper learning curve due to its object-oriented approach and integration with Apple’s ecosystem. However, once you understand the basics of Core Data, it becomes a powerful tool for managing complex data models in your iOS projects.


Are there any third-party libraries that can simplify working with SQLite in iOS development?

Yes, there are several third-party libraries that provide an object-oriented wrapper around SQLite for easier integration with iOS projects. One popular example is FMDB, which is written in Objective-C and simplifies working with SQLite databases by providing a more familiar interface for iOS developers.


Is there any alternative persistence framework besides Core Data and SQLite?

Yes, you can use Realm which is a really good alternative to SQLite databases. You will need to be careful if you ever think about migrating those local storages to another stack but that problem you will have with pretty much any solution.  


Conclusion – Wrapping up SQLite and Core Data

In this article, we’ve explored the differences between SQLite and Core Data in iOS development, including their features, use cases, and code samples. And a few possible interview questions related to that subject.
While SQLite is a lightweight and versatile database engine perfect for simple data storage, Core Data is a powerful framework for managing complex object graphs and persisting data in Apple’s ecosystem.
Now that you have a better understanding of both technologies, you can make an informed decision about which one to use in your next iOS project.

Fellow Apple Developers, that’s all.

I hope you liked reading this article as much as I enjoyed writing it. If you want to support this blog you can Buy Me a Coffee or say hello on Twitter. I’m available on LinkedIn or send me an e-mail through the contact page.

You can likewise sponsor this blog so I can get my blog free of ad networks.

Thanks for the reading and… That’s all folks.

Image credit: Featured Painting