Firebase Spark V3.12 for iOS Review
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.
Firebase offers three plans:
For this review, we tested the iOS SDK for Spark.
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 FeaturesAuthentication 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.
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.
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.
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.
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.
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.
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.
Firebase does not inherently support geolocation. There is an open source add-on called GeoFire, which integrates with Firebase and provides basic functionality.
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.
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.
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 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 TimePerformance 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 – ThroughputWhen 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.
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.
For app versions where the Crash Reporting SDK is enabled, error reports include data from two sources:
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 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 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.
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.