Hi guys. I was interviewed by an IT Director yesterday, who seemed to be on a minus first level at Swift. He asked whether I worked with SQL, the answer was: " I worked with Core Data and Realm". But he said that his iOS developers only work with SQL. I am wondering how to work with SQL from Xcode. Perhaps, I have to learn that.
May anybody explain whether it's worth it?

I would say it’s worth it to learn, as you will probably run into working on larger legacy code bases. I ran into a similar situation at my current role, I would say look into SQLite without core data


There are some great libraries from the community for working with SQLite directly, for example SQLite.swift.

Whether or not it's "worth it" for any particular project is subjective. I personally prefer SQLite to Core Data, but there are many apps and companies for whom Core Data has been a great solution.

Some of the reasons I've used SQLite directly instead of Core Data:

  • Core Data didn't allow deletions without loading the objects into memory first (i.e. batch delete). On one app I worked on, the performance hit of doing that was too large, so we dropped down to SQLite (e.g. DELETE FROM table WHERE {some condition}).
  • On one project, we had a data set baked into the app that was shared with Android. By using SQLite, we could use the same file on both platforms. We had been using Core Data before, and this required a separate build step to ingest the source data into our Core Data store.

Many iOS developers use Core Data and Realm indeed.

Those who work with SQL often use the embedded database SQLite.

SQLite is a C API that will have you work with both SQL, and... C from Swift.

There exist Swift libraries that wrap the C functions in Swift, so that you don't have to learn C from Swift:

  • GRDB - this is my favourite since I created it - but many other people love it as well. It ships with great support for raw SQL, as well as high-level conveniences apis on top (in case you eventually find that writing SQL is too much ceremony in many cases).
  • SQLite.swift - this one does not want you to write raw SQL, to be honest. But its Swift API mimics SQL, so you may teach yourself some SQL in the end. Very popular as well, but not quite maintained.
  • FMDB - it's an Objective-C library, but you can call it from Swift as well. It only talks SQL. I mention it because this library has been very important in the life of many iOS developers for many years. But frankly if you think it can fit your needs, then directly jump on GRDB because it talks raw SQL just as well if not better.

Learning SQL is also a way to learn the fundamentals of relational databases, database integrity, transactions, isolation levels, normal forms... Why is it useful? Because those are the building blocks of reliable data processing, and who would not want to write programs that:

  • Can not corrupt the user's data. This means that users are happy.
  • Can rely on the database to have a well-defined behavior in multi-threaded contexts, or in multi-processes setups (one database shared by multiple processes). Say goodbye to the multi-threading churn of Core Data and Realm.
  • Can use the database as a single source of truth. To the hell with merge policies, conflicts, and NSObjectInaccessibleException.
  • In the end you also understand "bigger databases" that run on a server, because they share the same fundamental behaviors.

Not only do Core Data and Realm hide too much, they hide the best parts.


Core Data is not really comparable to SQL; Core Data is an object graph framework which offers persistence. It explains so much, the moment when you really understand Core Data is when you realise that those are different things. Not everything is an object graph problem, so not everything needs Core Data.

SQL is probably the most impactful database technology of all time. It's good to know at least the basics of how it works.


Documentation says that Core Data can work with SQLite, I was always sure that it means it can work with SQL perfectlly well :man_facepalming: . I'm a newbie.

GRDB is so well documented. I'll definitely read it. Seems to be a good framework.

1 Like

I didn't mean to make you feel like a newbie. Core Data is an object-graph management framework - every unique version of an entity has a single class instance, and it can be loaded or unloaded from memory as needed (faulted). It can use SQLite as a backend datastore, but you should really think of it as working with object graphs. It lets you write queries against the object graph, which it will (behind the scenes) translate in to SQL queries.

If you understand the basics of how Core Data queries work, you understand the basics of SQL. Just know that SQL only deals in data, not objects. I think there's even a debug flag to print the SQL statements Core Data generates, which you might find helpful.

1 Like

You didn't make me feel like a newbie, even though I am. I got my first offer as a junior IOS developer yesterday.