I recently got into the position of leading the technical interview when my client was searching for a new senior iOS developer.
It's a challenging task to evaluate the skills and knowledge of another developer. So in this post, I want to share my results of the most useful iOS and Swift questions and answers with you. I categorised the questions into different topics:
This post covers questions and answers on persistence & databases.
The purpose of these interview questions is to get to know the developers general knowledge of database concepts. And also to check his specific knowledge on persistence in iOS.
So let's get started.
Depending on the case and the amount of data, there are different ways to store data. Examples are User Defaults, saving Files, Keychain, Core Data. There are also third party libraries like Realm.
UserDefaults is a great way to save a small amount of data. You can store basic types such as
String etc., and also more complex types like arrays and dictionaries.
Keychain is a good choice, if you want to save highly sensitive and secure data like passwords, keys etc. When using Keychain, it automatically takes care of data encryption before it is stored in the file system.
Core Data or Realm Database are often used on iOS to deal with a large amount of data.
Core Data is Apple’s native solution for persistence. Through Core Data’s model editor, you define your data’s types and relationships, and generate corresponding class definitions.
Realm Database is a highly supported open source library that is also available for Android. It is popular because it is easy to use and really fast.
These are not the only options of course. For example, you could also use a SQL database, there are some SQL libraries around, like
Data migration is often necessary when you need to make changes to the data model. So every time when the data model needs a change, e.g. for a new feature request, you’ll need to create a new version of the data model and provide a migration path.
An alternative to migration is simply deleting and rebuilding the data store. But this is only an option, if the stored user data can fully be restored, e.g. from a backend api.