If you are new to the mobile development world you have probably wondered how data is managed and stored in mobile devices, I’m gonna give you an overview about that and how much it costs, also I will talk about the pros and cons for each of the options that we have and which one fits your needs.
Let's begin right away by discussing the most important characteristics that will define your choice in the development phase.
- App purpose ( Companion app for an existing product, Offline App, Sync Functions, etc ..)
- Making The Right balance between Technical and business options.
- Least Amount of Risk and Highest Benefit ( Minimum Risk of an Overkill)
- Demo App? Pick the tech that fits your comfort zone To deliver an MVP (Minimum Viable Product)
Showcasing Options
MySQL
Undoubtedly MySQL is the most popular database out there, traditionally MySQL has been used for web development and powers many websites including the most popular content management system WordPress which is installed on over 16 million websites, however what’s right for web development doesn’t mean that it’s automatically right for app development, for example, you might already have a MySQL database full of data and you’re looking to build an app to serve that data like a membership site where all of the user accounts are stored in a MySQL database and you’re looking to make a companion app for your website or maybe you are already familiar with using MySQL SQL queries and writing web services then go ahead and use it for your app too however if you’re starting a brand new app that is free of any constraints then consider all of your options.
Let's talk about how data is stored in MySQL, it's a database much like how a spreadsheet would be organized for instance you might have a spreadsheet to keep track of all of the employees in your company you name the spreadsheet employees and inside it, you create columns to represent different details of each employee then each row in the spreadsheet would represent one employee, now let’s talk about how much using MySQL will cost in terms of costs, most web hosting plans come with a MySQL database and they can start as low as 4 dollars a month you’ll also need a domain name so that your app has a URL to hit for your web services this costs around 10 to 20 dollars a year, some advantages of using MySQL for app development that a lot of people are familiar with how a MySQL database is structured it’s also tried and tested, MySQL has been around for a while, now one of the cons is that you need to write your own web services that may require you to learn a completely different programming language such as PHP , also with a low cost web hosting plan you probably won’t be getting the right infrastructure to support high load scenarios and you probably won’t have any data redundancy so if your database server goes offline then your app won’t be able to access it.
Cloudkit
Cloudkit is Apple’s back-end solution to store your app's data and user data in the cloud, if this is your first time hearing the term back-end as a service it’s basically all of the back-end infrastructures to enable things like file storage and data storage user management and notifications and more, all this is done for you and available through a single API, it sounds great, right? except that these back-end platforms aren’t free, however most of these platforms have a free tier that allow you to use all of the infrastructure and services for free until you reach the limits of the free tier, the great thing about using one of these back-end platforms is that you get a lot of robust infrastructure for your data storage for example, data redundancy, your data is backed up and synced across multiple data centers so if one goes down the request is routed to one that is online, this prevents the scenario where your app is waiting for a long time for data because of high volume, Cloudkit uses the concept of containers databases and records, your app has one container which contains three different databases a public database where the data is accessible by anyone a private database where the data is accessed by a specific user and a shared database where the data is accessible between a group of users within each database, you store the actual data in what is called a record, each record contains key value pairs, each record is of a certain type, those types can be defined in the Cloudkit dashboard, you can feel that the strcuture is very solid, let's cite an example, you might have an employee record type containing these properties and a manager record type containing other properties then in your database you can create employee and manager records each of these records will contain the key value pairs.
One of the drawbacks of Cloudkit and that is that there’s no official SDK for Android they obviously have an iOS SDK that you can just drop into your Xcode project to work with Cloudkit and they also have a JavaScript SDK but there’s no official Android SDK which means that if you have an Android app you’re gonna have to build a set of web surfaces using the JavaScript SDK and then have your Android app send requests to that set of web services which you built, another thing is, you can store public data on the cloud kit databases however private data is stored on the user’s iCloud account that means if you’re using Cloudkit and you’re gonna be storing private data, your users must have an iCloud account, well this shouldn’t be a problem if you’re building an app that runs on iOS because it is obvious that users have to sign in with an Apple ID or sign up for a new one and that is basically an iCloud account too, if your app is going to be Apple only such as mac OS iPad app or an iPhone app then Cloudkit might be an easy solution for you, let's not forget one of the great pros which is, the generous free tier that you can profit from, you can learn more about on developer.apple.com
Firebase
Using Firebase as a database solution for your mobile application allows you profiting from many benefits that Firebase web platform offer which includes a lot of back-end features such as push notifications setup, user profiles management, file storage, crash reporting and more. The only tough thing about using firebase for data storage is that you have to wrap your head around the way the data is stored, Firebase is a no SQL database if you’re used to writing SQL queries with a traditional database like MySQL or Microsoft sequel server then it’s going to take a bit of practice to get used to using a no SQL database like firebase, in firebase data is stored as a JSON document, to access data you would just need to know the path to the element that you need to add data to, you can add key-value pairs to existing objects or create new nodes, there’s no concept of tables rows or columns that’s why it takes a little time to wrap your head around if you’re coming from the world of traditional databases. In terms of pricing, firebase has a free tier but it’s not based on active users like Cloukit, you should figure out how this fits within your budget and within the plans for your app, in my opinion, it is more important to get the app up and running as quickly as possible rather than worrying about incurring some extra costs, one issue that could be worrying about hitting the limits of this firebase free plan is the file storage limits if you allow your users to upload large files that you might hit that cap pretty quickly , so we can't forget that one of the remarkable pros of firebase that it's owned by Google who is arguably pretty good at handling data and their infrastructure is highly trusted.
Core Data
Now compared to the other database solutions we’ve talked about so far Core Data is very different first of MySQL CloudKit and Firebase are all remote database solutions that means that the data is stored on a remote server somewhere where all your users can access it, Core Data is different because it’s local on the user’s device that means that it’s not the solution for connected scenarios like generating user accounts or having user-generated content, Core data is a solution where you need data persistence on your local device, for instance, your app works with a large offline data set that is stored locally on the device, don't be confused if I tell you that Core Data is not a database, actually, it is an object graph manager and you can think of an object graph as simply a bunch of objects and the relationships between those objects, for example, let’s say that you have an employee class and a manager class , the manager class has a property called managed employees that stores an array of employee object references we create a new manager object and three new employee objects then we assign these three employee objects to the managed employees property of the manager object now this manager object has a reference to these three employee objects now this is an object graph with relationships we could use Core data to save this manager object and then later to get it back. Under the hood, Core data uses an SQLite database that’s something that is hidden from you and not designed for you to peek into, the Core data framework is free to use and you can simply add it to your Xcode project and start using it, some advantages of using Core data are it’s a first-party library it’s created and endorsed by Apple, it’s easier to use now compared with its previous versions, there was a lot of code to do routine tasks with Core data but Apple has now cut down on the amount of code needed so it’s the perfect time to get into it and some cons it’s not for connected scenarios so it really depends on what you’re doing with your app and secondly it might be an overkill if what you need to do in your app is just store some settings or store some offline data that isn’t a huge volume.
Realm
If you visit realm.io you will actually find two products one is called realm platform and the other is realm database and it’s open-source and free to use, the realm platform is their paid offering that provides data synchronization capabilities to your app if you need it, In this article, we are going to focus on the realm database.
In the last section I did focus on Core Data and how it can persist your object graph on the local device, well realm does the same thing at the end of the day they are both used to persist data on the local device so that it can be retrieved later, however, the way they persist data behind the scene is different and also how you implement these two frameworks in your Xcode project is also different, Core Data uses SQLite behind the scenes while realm just stores the data for your app in a file locally on your device this file can be opened to look at the data inside, in fact, they have a free tool called the realm studio that lets you open the data file and browse or edit the data with Core data you learn that in order to persist objects these objects must be from a class that was generated from the data model which you designed in the Xcode data model editor with realm you don’t do any of that you can persist any class you want simply make it a subclass of object which is a realm class that has all of the code to make the magic happen furthermore you dictate which properties of the objects should also be persisted by adding this in front of the object declaration realm database is pretty simple to understand and to get up and running with the realm database is open source and free to use realm studio is also free, some advantages of using realm database are, it’s a lot easier to jump in and use compared to Core data you don’t need to understand as much about the framework and how it works underneath the hood you can just get up and start using it, some of the cons, it’s not for connected scenarios so it really depends what your app is trying to do.
Conclusion
To put a closure to this article, I would say that choosing an option from the options that this article covered really depends on your app architecture, targeted users, app goal and how comfortable you feel with the cited options, sometimes you might feel overwhelmed by a specific technology, due to some uncontrollable conditions that forced you to work with, you feel like you are facing a mountain to get used to it, this should not be an obstacle to prevent you from achieving your goal and there is no excuse to abandon a project because you feel just stuck, doing some research, good reads, interacting with communities, all these practices will benefit you more than you think, instead of just staring at a buggy code and complaining about it, taking an action and addressing the issues in effective ways will save you a big amount of time.
