ios swift 4 local database explanation

You can use both SQLite and Core Data. They are both widely used and you will not have any issues using them. If you want to use SQLite I would suggest using FMDB because it will make using the SQLite database easier. Core Data is very performant but you say you will not have a ton of data so it could be overkill and it is a bit verbose to use.

I think SQLite has an advantage if you want your server to be able to send you a straight up SQLite file as a download. SQLite is supported everywhere so it is easy to contruct a database on the server and send it over to the your phone as a file. Core Data is only supported on iOS so you will have to translate the information from your JSON, but you stated that you will already be doing that.

Personally, I think Realm is the easiest local database to get set up for iOS. I was able to add it to some of our code bases surprisingly fast and they have good documentation. They have a pretty big community and it is easy to get help as well as a wealth of tutorials on how to get started. Realm is also cross platform so you could use the same database in your Android app. If you are familiar with database ORM's for Code First database approaches then you will feel at home with Realm.

At the company I work at we use all three in our production apps, so it is merely a question of taste and other requirements outside of you control. All three will do what you want to do.

From the Apple Reference

What is Core Data?

Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence.

From this you can see the essential difference between Core Data and a database, such as sqlite; Core Data deals with objects. Persistence of those objects, while a common use of Core Data, is not compulsory. The Core Data framework can make use of different backing stores and sqlite is one of the most common stores.

When you deal with a database you have to think about tables and rows and you have to handle the conversion between the row data and your in-memory object. With Core Data, your model objects can subclass NSManagedObject and you can persist and restore them directly with Core Data.

With a database you can use foreign keys to relate rows between tables and you typically use a join or another query to obtain the related data. With Core Data you can simply assign the reference to the related object to a property of the first object e.g. employee.manager = someOtherEmployee and Core Data will manage the relationship for you when you persist the data. When you retrieve the data you can refer to employee.manager to get a reference to the manager object without needing to explicitly perform a query/fetch; Core Data will retrieve the object from the backing store automatically if necessary.

Unless you need complex queries or joins, you probably don't need sqlite. There is a bit of a learning curve with Core Data, but the first hurdle is understanding that it isn't a database and you shouldn't treat it like one.

The advantage of using something like sqlite can be portability; a database and queries that you are using in an Android app or website can be used in an iOS app.

To give you an idea of how Core Data could work in your situation;

• Your data is coming as JSON objects, so using Swift 4 Codeable you can easily convert that JSON into a collection of Swift objects.
• Xcode will create the Core Data Entity objects for you based on your Core Data model.
• All you need to do is add extensions to these classes to implement Codeable and then you can persist your JSON data locally with virtually no additional code.