When you’re putting together a new app, especially if it’s your first exposure to iOS development, it can be a confusing experience. Sometimes you’re starting from scratch, and you have a bunch of options available to you, and you just don’t know which one is right for your app. You may have even been “helped” by a PaaS or IaaS platform that has given you a conventional SQL database instance: great for web apps, but how do I connect this to my iOS app? Do I want to?
There are many different ways to provide a database backend for your app. Here are some recommendations for different situations.
CloudKit
If you have no plans to extend it beyond Apple platforms (with an exception for basic web functionality), you have the convenience of CloudKit. CloudKit is the Apple-provided cloud storage backend for iOS and Mac applications, and it is free to develop with, and free for production use within very generous limits.
The disadvantage of CloudKit is that it is a mostly cloud-only storage framework. There are very limited facilities for dealing with the issues of apps being offline, either due to a lack of data connection or a temporary network failure. If your app requires this kind of functionality, this will mean additional coding in order to support keeping parts of the database offline for use when the network is down, synchronizing edits when it is back up, and resolving conflicts.
HTTP Access using REST Endpoints
If you have an existing database to which you need to connect your app, or if you have a requirement to use a conventional SQL database server, such as MySQL or PostgreSQL, this is going to be your primary choice. These servers do not have SDKs or APIs to access them, so creating REST endpoints to access the database is a common solution. REST happens to fit well with the CRUD (create-read-update-delete) operations common to database records.
Let’s talk about the elephant in the room: this is the most work. You will need to write your own REST endpoints. Thankfully, most languages have frameworks which make building these REST endpoints as easy as possible: Rails or Rack or Sinatra for Ruby, Flask for Python, or Express for node.js. Even Swift has a server-side component, called Vapor, if you want to leverage your Swift knowledge on the backend (with this caveat: it may not be ready for production yet).
The advantage is that it is very likely you would need to do this sort of integration in your app anyway, because accessing many third-party APIs to provide functionality for your app require the same sort of interaction over HTTP REST endpoints. Also, because you have control over your own backend, you will be able to write specialized API calls that can perform complicated operations on your data, which may not be easy (or possible) with other cloud database services. An added bonus to this: with some adaptation, this could be adapted to be a public API for your app.
Realm
The Realm Platform is an integrated solution for adding a database backend to your iOS app. Via its SDKs for Swift, Objective-C, Java, JavaScript, and .NET, it will support backends for every major platform, if expanding beyond the Apple ecosystem is important. It also handles many of the complexities of dealing with data between the local device and backend database, including synchronization, offline operations, conflict resolution, and real-time updates.
The disadvantage is that it is not free. The database component is open source, but the strength of this solution really is in the full Platform, which starts at a monthly cost for small quotas, and goes up from there. It also is not owned by a major cloud player (Amazon/Google/Microsoft), so there is always the risk that the company will be acquired and the product will be modified or axed.
Firestore
Cloud Firestore is similar in nature to the Realm Platform, but it organizes the data on the backend as documents which may be organized into collections. This may be more familiar to you if you’ve used something like MongoDB in the past, as opposed to Realm’s relational database model. It provides many of the same features as Realm Platform, so the choice between the two will be heavily motivated by whether your data structures are better suited to the relational model of Realm or the document model of Firestore.
It has some other minor advantages that Realm does not. It is a Google Cloud service, and the next generation version of their Firebase product, so it will likely be around for a while (although some people might disagree with that assessment!). It also has metered billing, so for development it may be a less expensive choice than Realm.
🚫 Core Data
Let’s talk about Core Data. Core Data still shows up in discussions about connecting apps to databases. The truth is: it’s time to put this framework out to pasture.
In current SDKs, it is only good for setting up local databases. The only native integration to cloud-based storage was iCloud Core Data sync. It has been deprecated, and rightfully so, because it never properly worked. Apple finally gave up on making it work, and produced CloudKit.
The only other way to make it work with remote databases is to use third-party synchronization frameworks, which essentially link your Core Data database to… one of the above solutions. It is extra complexity you just don’t need.
I’ve seen statements to the effect that if databases like Realm were acquired by Apple and integrated into their OSes, they would have no use for Core Data anymore. These days, there are so many better database integrations out there, that Core Data is best left as a historical relic.
Comments are closed.