Mega Bundle SALE is ON! Get ALL of our amazing iOS app codebases at 95% OFF discount 🔥

Get Bundle

It’s extremely common for a mobile app to support dynamic features such as user management and user-generated content, like social posts, photo uploads, or private messages. To build this functionality, an iOS developer will need a web backend that acts as a central database and serves data to the iOS client. To choose the best backend for your iOS app there are a few things to consider right from the start. Luckily, in most of the cases, the decision is simple: use Firebase.

Choose a backend system based on your needs

Before jumping into writing any code, be it backend or iOS, you need to take into consideration a set of aspects that might make or break the success of your iOS app. This is a critical decision, so please make sure you think it through.

• Time Investment – How long it’ll take you and your team to develop a brand new backend server from scratch? Is this the most important time investment you can do given you’re just getting started with a new app? If the answer is no, then you should consider leveraging a mobile backend service provider.
• Your skills – Do you know any server programming languages? New startups usually build a REST API, in Node.js or Ruby on Rails. Do you have such competency in your skillset? You’ll also need to architect the client-server communication and this requires a different set of abilities.
• Performance – This is probably the only aspect that might dictate a custom web backend. With service providers such as Firebase, most of the computing work (e.g. joining two tables) happens on the users’ iPhones. If your app has a lot of work to do (pre-computations, heavy computing, etc), it might be a good idea to do it server-side and save your users a lot of resources (battery, network, data, disk space, etc). Luckily, most iOS apps have a relatively low performance need, most of the computing work ending up being just simple CRUD operations.
• Scalability – Assuming your app becomes successful, your backend will need to scale up to hundreds of requests per second. While this is a great problem to have, the solution will be much simpler with a backend service provider, since it’ll only cost money, saving you a lot of time and work, and being a guaranteed success (as opposed to a brand new solution built by your team, which might fail).
• Financial Investment – If you can’t design and build a server yourself, you’ll need to pay money right from the beginning. Backend providers allow app owners to run their iOS apps for free until a certain traffic threshold is met. This is a great way to test out an MVP, without spending any money on backend resources.

What’s the Best Backend for your iOS App

Firebase

Most of you will & should go with this. We highly recommend Firebase. Please don’t reinvent the wheel. You get an incredible set of backend functionalities for free:

• Database
• File Storage (photos, videos, etc).
• Push Notifications
• User Authentication

Firebase provides a Swift iOS SDK, that allows you to query the database, enqueue notifications, sign in and register users, directly from the iOS code. It can scale to unimaginable amounts of traffic, and all you need to do is upgrade your plan. Most of the iOS apps fail though, so why invest a lot of effort in building all these features yourself?

All of our fully-functional iOS templates use Firebase and they leverage all the listed features.

Parse

Parse is a combination of do-it-yourself and using a backend provider. It’s basically a bunch of Github repos that contain the server code, as well as the client code SDK that communicates with the server. Practically, the server code is written already, but you need to run your own server with it. Parse a long history – for context, it used to be a backend service provider, exactly as Firebase, it was acquired by Facebook and then shut down. To alleviate the pain of the mobile community, Facebook open-sourced the code and allowed developers to run their own instance of Parse. In my opinion, don’t use Parse! It feels like you get the worst of both worlds: you need to run a server yourself, but at the same time you have the iOS app doing the heavy computing work.

REST API

This is the classic approach – exposing a bunch of RESTful APIs from the server, that are being queried by the client. You usually end up writing a simple CRUD application (create, insert, update, delete), backed by a SQL relational database, that returns JSON formatted data to the client. Most popular choices are ruby on rails and python. WordPress and WooCommerce have REST APIs, so if your backend is one of these systems, you’ll need to go with this approach.

RESTful APIs have an inherited flaw – keeping the client-server contract in sync is extremely hard, especially in large teams and codebases, since the format is JSON (pure strings, untyped) leading to lots of crashes and unexpected bugs. Updating APIs is extremely hard since you need all the past app version to keep working after the update (so API versioning comes into play). Additionally, adding new features require changes on both server and client (since the server either needs to add a new field to an existing endpoint or add a new endpoint altogether).

GraphQL

To mitigate the limitations of REST APIs outlined above, GraphQL was introduced by Facebook. It represents a query language for APIs and a runtime for fulfilling those queries with existing data. If you end up choosing to build your own server, you should dig into GraphQL first, since it’s a better bet in the long run, but it comes at a greater price short-term, given the complexity of setting it up.

As a final note, I wanted to mention the fact that there used to be more “backend as a service” providers (BaaS) in the market a few years ago (e.g. StackMob, Kinvey, Applicassa), but all of them died out – this only shows how powerful Firebase is – scalable, rich in features and free.