Firebase is an MBaaS (mobile backend as a service) from Google that provides all the features that most apps would need from an MBaaS, with support for both web and mobile clients. For a highly dynamic app, you would no doubt need a server setup working in conjunction with Firebase, as you would need to write your own server code if you want the data in Firebase to be updated. Thankfully, Firebase has solid support for web technologies. If you have an app that is already using a fully developed web backend, you can still use Firebase for some of the above-mentioned services.

In addition to providing all the features you’d expect from an MBaaS, Firebase delivers additional, value adding features such as remote configuration and dynamic links. Also, with Google’s acquisition of Firebase in late 2014, AdMob was added and is available right from the Firebase dashboard. Basically, you wouldn’t have to find a different service for any particular use unless it’s highly specific.

Though we’ll be focusing on the iOS platform in this review, it’s worth mentioning that Firebase also has SDKs for Android and JavaScript, but not for C#. The lack of C# support means that you do lose the ability to easily do cross-platform development with native development tools such as Xamarin. The JavaScript SDK is available for developing a cross-platform hybrid app using PhoneGap or Cordova, but by Google’s own admission, it does not yet provide all the features that Firebase supports (though they are working on it as of this review).

Firebase offers three plans:

  • Spark, a free tier suited for use during the development phase,
  • Flame, aimed at small apps, and
  • Blaze, for large-scale apps. Blaze is the only tier to allow automatic backups.

For this review, we tested the iOS SDK for Spark.

Review History



Firebase Spark (hereafter Firebase) offers most, if not all, essential and common features we have come to expect from an MBaaS provider, while also delivering value-adding features such as dynamic links and geolocation that help it stand out from the competition. This review will focus primarily on the functionality and quality of the essential and common features, though we’ll also have a look at the additional features.

Essential Features

Authentication and User Management

Firebase supports a ton of logic methods, such as Facebook, Google, Twitter and GitHub. If you want to allow your user to register just with email, though, that’s also possible. However, if you want to integrate using any other third-party identity provider, you’ll have to forego using this feature and use LDAP or a trusted server instead.

The SDK provides easy ways of integrating all the login methods, even generating the UI for login buttons, and enabling browser login re-directs, automatically bringing users back into the app once login is complete.

File Storage

Firebase allows for the upload and download of user-generated content to and from the cloud, essentially replicating Amazon S3 and CloudFront storage and configuration features but without the need for a heavily involved setup. Automatic scaling is also provided for storage needs. Uploaded files are accessible with the Google API engine, meaning the uploaded files do not need to be migrated to the Google Cloud platform once they are uploaded, as this will be done automatically. This means that if you want to post-process uploaded files, it is easier.

The SDK promises to work well under any network conditions. The upload process lets you access the downloadURL for an uploaded file, in case you want to refer to it in the database. The SDK provides various ways to download an image, either by downloading an image in-memory, writing it to a file, or having the URL downloaded by a 3rd party SDK (or by yourself). All in all, there is plenty of flexibility here.

Data Storage

The Dashboard allows you to upload initial data during development using a JSON file, which is helpful. It is also easier to change the structure midway through development since there is no fixed schema; all you have to do is upload a new JSON file with a new structure for the path. You can then configure rules as to who can access the data at various paths. Unfortunately, these rules are terribly convoluted, with difficult to understand relations defining user access and roles. Even the documentation only helps sort things out to an extent. The user access and roles are set using a JSON structure, but it could have been better implemented had Firebase provided options to edit the rules directly on the database JSON tree. You can also test requests, which involves rules using a built-in simulator.

Firebase doesn’t just store data. It also supports real-time updates and persistence. It allows a user to observe changes to data, automatically synced to any devices that are connected. It also allows a user to enable persistent offline data storage (and queries) with a single additional line of code. But it would have been better if they had provided the option to enable persistence only for some of the data paths. Any changes made to the offline data are automatically synced with the Firebase server when the app comes back online. It all works as expected.

The SDK in and of itself doesn’t enforce the use of model classes, nor does it provide a base model class (in the vein of PFObject from Parse). This has its benefits as users will have the flexibility to easily implement the way they want to go. Pagination is straightforward, as only the limit to a query needs to be applied. By default, there is no limit and the SDK will download the whole JSON tree for a path. This allows for flexibility, but if a user isn’t careful about database design, it can result in long load times. Users also need to be careful about entries that may grow in size overtime – these should be handled in the app. It might be a good idea in your project to apply a limit to all requests that are made. For optimal performance, it is crucial that the app follows best practices as prescribed by the Firebase developers.

Business Logic

Firebase lacks business logic on stored data, something that is provided by other MBaaS offerings such as Kinvey and Backendless. Firebase has, however, said that while all of the business logic cannot be specified in Firebase’s Rules languages, users can enforce a vast majority of cases.

Push Notifications

Firebase integrates well with iOS push notifications. After submitting the certificate, messages can be sent through the console to different user segments. In addition to predefined segments, custom audiences can be created in the Analytics section. Firebase has gone a step further than competitors like Kinvey and Backendless in how thoroughly users can tailor their audience.




Common Features

Access Control and Security

Firebase used to store passwords using salted bcrypt hashes, but recently converted to scrypt, which puts it even further ahead of its competition as scrypt is about as good as it gets for password storage. Https is used everywhere, from data transport between your app and their servers to their own documentation website.

Firebase’s database rules determine who has read and write access to data structures. The rules have a JavaScript-like syntax and can be set up within the console. The rules are finely grained, but the user interface for creating the rules isn’t optimal. It can become unwieldy when creating complex rules.



In Firebase, many analytics events are automatically captured, while it also integrates with other Firebase features such as crash reporting, notifications and remote configurations and captures those events.

The dashboard is fairly comprehensive, letting users analyze various metrics such as active users, revenue, retention, user engagement, in-app purchases, distributions based on country, app version, demographics, and location. User properties can be set and the audience differentiated, and this can be further used in Attribution and Cohorts.

Attributions let users analyze the effectiveness of ads and engagements, whereas Cohorts display retention rates. If more complex analysis on the data is needed, it can be exported to BigQuery.

One thing to note is that it is not yet possible to export all the raw data in .csv format for input to custom analytics tools – users are stuck with either Google BigQuery or Google Data Studio.

Source: firebase.google.com



Firebase does not inherently support geolocation. There is an open source add-on called GeoFire, which integrates with Firebase and provides basic functionality.

Additional Features

Firebase also includes the following features, which were not tested for this review as they are not essential or common to MBaaS products in general.

Remote Configuration

Firebase remote config is used for A/B testing. It allows users to save certain parameters in the cloud and configure them from the dashboard as well as change the app’s behavior and appearance remotely without submitting an update for your app. The parameters are a list of key-value pairs. The SDK only takes certain primitive data types that are saved, and this causes issues with the way parameters are handled in the code. If there are a lot of parameters, it becomes difficult to maintain that list on the app side and on the dashboard, requiring a lot of structuring. It also doesn’t provide real-time updates; you must request new updates during some stage of your view controller cycle.

Firebase remote config integrates with Firebase analytics so you can see the results of A/B testing on the analytics dashboard. Using remote config, you can configure different user groups under analytics and obtain insights on how A/B testing worked out for those groups.

Dynamic Links

The Dynamic Links feature aims to do the same thing as Android’s new Instant Apps where deep links allow users to open a particular app screen even if the app isn’t installed. It engages mobile users quickly, and allows for easier conversion of web users to mobile app users.

The advantage of dynamic links is that the same link works on both iOS and Android, unlike normal deep links. If the app is not installed and the user does a fresh install of the app, it would still be able to recall the dynamic link information, taking the user directly back to the screen from where he clicked the dynamic link. If the app is not yet installed, the user will be taken to the App store. What happens next, such as forwarding the user to a website, can be customized.

Although the setup is a lengthy process, it could be beneficial if a deep linking behavior that works much better than normal deep links is required. Firebase analytics also integrate with dynamic links, making it easy to track users who are being converted from web to mobile.

Firebase also has a system for invites that works on top of dynamic links. It is a solution for app referrals and sharing via email or SMS.

Crash Reporting

Crash reporting tools are a must have for any app, and Firebase includes quite a decent offering with all the basic collecting and monitoring you would expect. Or at least it used to. Even though the tool is still available, it’s in a deprecated state currently as it will be swapped for Crashlytics following Google’s acquisition of Fabric earlier this year. Crashlytics has been the go-to solution for quite some time now and it should be the tool of choice for new Firebase users. It even says so in the documentation.


Adding an app in the Firebase dashboard is extremely easy. The installation process guides users through a series of steps on how to set up the SDK in Xcode, and we found no need to go through the documentation at that stage. Installation is simple and can be done using CocoaPods. They even provide a .plist file that the SDK can use, containing all the relevant keys and IDs so that users don’t have to add them into their code, thus reducing the initialization code to a large extent.

The dashboard can be confusing at the beginning if you come from a relational database background, as data is represented as JSON trees. Relational database design doesn’t apply here as it’s a NoSQL database, so you need to be very careful during the design. Fortunately, Firebase has some really good articles on its site, and even a YouTube channel for those so inclined to watch tutorial videos instead.


Performance – Response Time

Performance was tested by trying to ascertain how quickly the database can process and respond with information to complete the request.

We gauged Firebase’s response time by retrieving 150 data items using 100 concurrent users. In comparing its performance with some other MBaaS solutions, Firebase’s average response time (779 ms) for data downloads was better than both Backendless Cloud (1077 ms) and Kinvey Developer Edition (1309 ms) but lagged behind Oracle Mobile Cloud Service (570 ms), though comparing to the enterprise-level performance of Oracle’s solution isn’t a fair comparison.

Performance – Throughput

When multiple users connect to a single server, they share the same bandwidth for downloading content. In measuring throughput to help us understand the rate at which data is transferred, we had 200 concurrent users download a 1 MB image.

In a direct comparison with other MBaaS solutions, Firebase (50 MB/s) lagged just slightly behind Kinvey, Developer Edition (59.2 MB/s) and Backendless Cloud (58.4 MB/s) while none of these MBaaS offerings were able to keep pace with enterprise-focused performance of Oracle MCS (73.6 MB/s). We look forward to getting the chance to test Firebase’s enterprise-level solution to see how significantly the performance increases from Spark


Testability, defined by applying the concepts of observability and controllability, allows the Quality Assurance team to identify areas to test and, for each feature, tests can be performed and how to perform those tests. If the testability of the SDK is high, then the probability of finding faults in the system by means of testing is greater. This also helps testers to gauge which tests provide the most confidence and correctness.

Firebase consistently has a fast responsive time on the console when user is trying to navigate around. Console layout is also user friendly that makes it easy to test and evaluate most features instead of navigating around and trying to figure out the appropriate place or having to wait long for everything to load.

Authentication and User Management

Testers can sign up as new users through the Firebase console, REST API, and/or demo app with an email/password option or by using their Gmail, Facebook, Twitter or GitHub accounts after selecting the preferred Sign-in method from the console. Since there are multiple ways to login, it makes testing more time consuming.


With Firebase Realtime Database, data is stored as JSON and synchronized in real time to every connected device within few milliseconds. Testers can conveniently add, delete, modify, retrieve data from the Firebase console, REST API as well as demo app. This makes testing easy.

By default, database rules require Firebase authentication and grant full Read/Write permissions only to authenticated users. The default rules (Read/Write) ensure the database isn’t accessible by just anyone before they’ve configured it. Once a tester has configured the database, they can customize these rules according to their needs.


Testers can upload and download files directly from the Firebase console to Cloud Storage. If the network connection is poor, the user can retry the operation exactly where they left off, saving time and bandwidth. This is great help for testers and makes testing more convenient. With Cloud Storage, a user’s files are stored in a Google Cloud Storage bucket. Hence, a tester can access the files either through Firebase or Google Cloud.

User permissions can be set and tested by updating ‘Rules’ in Cloud Storage. This makes testing easy because the tester can then test all the different user permissions by changing the Read/Write rules from the console.

Push Notifications

Firebase notifications can be configured from the Firebase web console that is easy to use and tested on the demo app. This makes testing this feature easy as there’s no need for a third party app.

Crash Reporting

For app versions where the Crash Reporting SDK is enabled, error reports include data from two sources:

  • Analytics events provide insights into user behaviors and are automatically imported from Firebase Analytics.
  • Custom logs provide insights into the behavior of your app and are collected by logging calls to the Crash Reporting SDK.

By using data from both sources to collect all non-trivial user and app behaviors, testers can gain useful insights into the conditions that precede errors or handled exceptions in the app. This helps to quickly analyze those errors and exceptions. Developer or tester can configure to receive an email alert on the console when a new or regression issue occurs.

Dynamic Links

Dynamic links can let users share and open application content faster and work on multiple platforms whether or not the application is already installed.

To set up Dynamic Links, a developer or tester has to create the dynamic link either from the Firebase console or Rest API or manually construct the link. Once setup is complete, users can open the link from the browser on the device even if the application is not installed. If the application is not installed, user will be prompted to install the application. If it is installed, users will be taken to the specific content in the application. The more dynamic links an app supports, testing time increases considerably but this is an optional feature.

This is the same with most other MBaaS solutions. Due to the optional nature and adherence to the standard, we will not say that this is either easy or difficult to test.


Firebase makes deployment very easy. In fact, as there is no real deployment, you can have multiple versions and name these versions QA, Production, or Development, and migrate data as required. Alternatively, you can have just one version and rename it once the app is in production. With Export JSON and Import JSON features in the database, testers can easily save a copy of the previous version and restore it later if something goes wrong.

Firebase Hosting makes it simple to set up and deploy to various environments by creating different projects for different environments. Running firebase deploy will deploy the app to that environment. One-click rollbacks in Firebase Hosting allow users to safely go back to the last working version.




Firebase documentation is generally clear and helpful, allowing you to get started quickly. Each feature has its own samples and API references. Any standard task that you want to do with Firebase can be performed just by referencing the appropriate guide. If you want to perform complex tasks, you will need to go through the API reference. Each sample is present in both Objective-C and Swift, which helps developers who are new to Swift. If you still require a tutorial to get you started, they have an excellent YouTube channel with how-to guides, tutorials, and dev summit videos.

Firebase blogs do a good job of showcasing the power of Firebase, with articles for people of all technical backgrounds to learn the architecture, understand best practices, and help deal with tricky situations. Their developer evangelism team keeps the blog up to date with anything new that’s happening with Firebase. In places where Firebase’s architecture is a bit esoteric or obscure, the documentation helps, but it’ll probably be better to turn to the community when you get hopelessly stuck. Interestingly enough, Firebase also has a Slack community where you can find help.

During development, if you find issues with Firebase, you can submit bugs or get one-on-one mail troubleshooting help. Firebase’s service status dashboard, as shown below, is a tremendous resource for observing service outages and helping with troubleshooting service-related issues.

Overall, Firebase does a great job when it comes to providing helpful material for developers.


Cost Benefit

Firebase’s Spark plan is sufficient during the development of an app and for performing simple deployments while Flame is more readily suited for production apps with small number of users. When the Flame plan becomes inadequate, the next step up is Blaze, a “pay for what you use” plan.

So, having in mind that Spark is the first step on an app’s road to multitudes of connected users, it is a good plan to get started. There’s no additional overhead when compared to the paid plans and transition is seamless as you’re basically just paying for more and more storage and hosting capability, not additional features unlike some competitors who unlock more features at the higher tiers or have convoluted pricing plans that nickel and dime you.

For those considering moving up from Spark, Firebase provides a cost calculator for the paid plans, though it is not sophisticated.




The Final Word

Firebase is more robust and well-rounded than its competitors, and provides a wealth of support to get users going and helping them along the way. Basically, you don’t need to find a different service for any particular use unless it’s highly specific.

While it offers a scalable pricing similar to its competitors, Firebase’s pricing model is the easiest to understand from the SDKs we have tested.

If you just need a fast, reliable database, user authentication and usage tracking without any business logic, Firebase is a great way to go, but the lack of business logic may run you into trouble if you’re building an app with complex back-end business rules. Having said this, Firebase is intended mainly to be a content delivery network, which is why it does not support business logic.

The following is our rating scorecard for Firebase:




Backendless Cloud iOS SDK

iOS App Development

Read More


Android App Development, iOS App Development, mobile strategy

Read More


Android App Development, iOS App Development, Mobile Testing, mobile UX

Read More

Oracle MCS iOS SDK

iOS App Development

Read More


Android App Development, iOS App Development, Mobile Testing

Read More

Kinvey Developer Edition iOS SDK

iOS App Development

Read More


Android App Development, iOS App Development

Read More
  • Vancouver Head Office

    800 West Pender Street, Suite 800 Vancouver, BC V6C 2V6, Canada

  • Contacts

    778-372-2813 (Sales)
    778-372-2800 (Main)
    778-372-2800 (Fax)

  • Bangalore Office

    WeWork, 13th Floor Salarpuria Magnificia, Old Madras Road, Mahadevapura, Bengaluru-16 India

Drop Us A line


Let’s Discuss Your Project
  • This field is for validation purposes and should be left unchanged.