Over the last decade, mobile gaming has evolved from stacking colored blocks on a phone to encompass multidimensional and multiplayer experiences that engulf people in imaginative, high-fidelity worlds. As games have gotten more engaging, they’ve also become more complex to develop and maintain. Here at Firebase, we’re committed to providing game developers with the tools and resources you need to build, release and operate successful games that delight players.
We participated in the Google for Games Developer Summit in March, launched Unity and C++ SDKs for Cloud Firestore into open alpha, shipped improved workflows for Unity developers, debuted some new video tutorials, and wrote some new blogs too - so you can easily add Firebase to your game and get the most out of our platform.
We have more exciting updates to come, driven by your feedback and stories. Recently, we spoke to Gameloft to understand how they’ve been using Firebase.
Gameloft is one of the world’s largest gaming studios, employing 4,600 people across 19 global offices. Their vast portfolio consists of over 190 critically-acclaimed, award-winning games that are played by 80 million people each month. Gameloft develops original franchises, like Dungeon Hunter, and also partners with major entertainment studios like Disney.
With such a broad portfolio and audience, having the ability to monitor the stability of their games in a holistic way, and the agility to respond to issues quickly, is key to their success. However, they were lacking proper information about crashes, having a hard time reproducing crashes, and unforeseen technical issues were taking too long to track and fix, upsetting both their team and their players.
Gameloft realized they needed a robust crash reporting tool that could help them improve game quality in a more streamlined and efficient way, so they turned to Firebase Crashlytics.
Crashlytics aggregates crashes by root cause, highlights the impact on players, and provides contextual information on each issue, which helps Gameloft prioritize the crashes to fix first and speeds up their troubleshooting process. By using Crashlytics, Gameloft achieved a 10% reduction in users experiencing crashes overnight for one of their games (Overdrive City). According to Gameloft, this also led to a bump in the game’s Play Store rating and increased session duration by 16%! Find out what Gameloft did to drive these results with Crashlytics by reading the full case study. And learn more about how Firebase can help you build and grow your game, and see what other game studios are using Firebase.
With our announcement of the Firebase Crashlytics SDK Beta in February, we provided a path to help you remove all Fabric dependencies in your code, and complete your migration to Firebase. Since then, tens of thousands of apps have adopted the Beta SDK, and several hundreds of millions of end-users are using apps that include the SDK. Thank you to the adopters of our Beta SDKs; with your help, we have been able to polish and debug our SDK so we could ship it in its best possible launch state.
We are excited to announce that the Firebase Crashlytics SDK is now publicly available! Whether your app was migrated from Fabric or created in Firebase, we encourage you to upgrade to the official version of the Firebase Crashlytics SDK.
Now that the Firebase Crashlytics SDK is publicly available, we are deprecating the legacy Fabric SDK. The Fabric SDK will continue reporting your app's crashes until November 15, 2020. On this date, the Fabric SDK, and beta versions of the Firebase Crashlytics SDK, will no longer send crashes to your Firebase dashboard. To continue getting crash reports in the Firebase console, make sure your app has the following versions of the Firebase Crashlytics SDK, or newer: 17.0.0+ for Android, 4.0.0+ for iOS, and 6.15.0+ for Unity. Developers new to Crashlytics should begin with our getting started docs.
As always, we’d love to hear your feedback! Let us know what you think through our official support page!
Happy coding!
Update: To show respect for current events, we are postponing the launch of Firebase Live to June 23rd. Please take care of yourselves and your families. We look forward to connecting, sharing and learning together very soon. Stay tuned for updates.
Here at Firebase we are extremely proud of our avid developer community. We love interacting with so many of you at different events throughout the year. Our event plans have changed this year, but one thing that hasn’t changed is our commitment to you and all of the great stuff you build. So we’re trying something new to virtually bring everyone together, and are excited to introduce Firebase Live!
Firebase Live is a new 5-part weekly web series for developers consisting of talks, tips, and technical tutorials to help you increase productivity and collaboration among your team. Every Tuesday at 9:30am PST from June 23 through July 21, we’ll host a new video highlighting best practices and product updates. Everyone can watch the new video together and chat with members of the Firebase team and other developers along the way. After each video, Firebase experts will answer all your burning questions live. The topics include:
We will also be launching a new demo and codelabs with walkthrough videos so you can learn at your own pace and build your skills.
Excited about this weekly web series? Check out our event page and follow us on Twitter to join the conversation.
We may not be able to meet in person right now, but we’re still here to help you build amazing things.
Today we are extremely excited to introduce the Emulator UI to the Firebase community. The Emulator UI is a local web app that allows you to manage local emulators that make up the Firebase Local Emulator Suite.
Last year we released the Emulator Suite to simplify Firebase debugging and development. Until now, the Emulator Suite has only been exposed through the Firebase CLI. Today, the Emulator UI makes it even easier to develop locally with Firebase.
The Emulator UI aims to give you the freedom to develop on Firebase without concerns about billing or breaking a shared environment.
Need to create a function that triggers on the creation of a Firestore document? You can write that code, run it locally, and then create a document in the Emulator UI and see the trigger fire. What's better is that you can even see the logs of the local function to help with any debugging or even just to ensure a successful invocation. The goal is to provide you the safety of developing and testing your code without interfering with shared environments, waiting on deploys, or incurring billing costs.
The Emulator Suite doesn't just help with developer productivity, it also aims to help with team productivity as well. Having a local first environment also allows you to onboard new developers to your team without them needing to manage a cloud-connected Firebase project. Just run a few CLI commands and the Emulator Suite is up and running with local instances of Firebase services.
One of the biggest goals of the Emulator UI is to provide you with a local first workflow. Firebase has always been an online connected service. Most development required managing multiple projects, usually one for production and several others for prototyping, staging and development. The Emulator UI allows you to shift away from needing the online connected project and lets you start your development workflow with local instances.
The Emulator UI is not an exact copy of the online Firebase console. It's tailored for the functionality you need while developing. Here's just a small list of capabilities of the Emulator UI:
...and there's still more to come! We have plenty of features to simplify development planned for the future.
The emulators were designed to run locally. This means it has a looser set of restrictions on managing your data. We want to provide you the freedom to quickly delete and restore data without having to click through a million prompts. But we also don't want you to confuse a local environment with a production one. We took steps to clarify that you are operating in a local environment.
The Emulator UI introduces a new color into the Firebase palette. You'll notice as you navigate around, purple is the new primary color for all buttons, hover and selected states, and other primary actions in UI components. Even the favicon is purple! The online Firebase console uses a blue as the main active state color. With just a quick glance you'll be able to see the difference.
We also moved the navbar to the top for quick navigation. The Overview page displays the local ports of each instance as a reminder as well. We also provide a link to get your production/managed Firebase project, to help establish you are in a local environment versus a production one.
pssst… If you spend enough time in the Emulator UI, you also might find some new features in the Realtime Database data viewer.
Make sure you update the Firebase CLI to version 8.4.0 and run the following command:
firebase init
Select the products you need to initialize. Which means if this is a first time setup, you'll need to set up each Firebase product you need, such as Cloud Functions, Firestore and Realtime Database rules, as well as Hosting sites. Once everything you need is initialized, run the following command:
firebase emulators:start
This will start the Emulator UI on localhost:4000 by default. Open your browser to that URL and you'll see the Emulator UI up and running.
localhost:4000
We are so excited to see the community use the Emulator UI. Our hope is that it boosts your productivity and happiness when working with Firebase. But this is just the first step. We want to know what you are looking for in the Emulator Suite. Send us a tweet! We'd love to hear from you.
We know that Kotlin is the future of Android and that Kotlin developers want clean, idiomatic APIs when they use Firebase in their apps. For the past year, we've been releasing Firebase Kotlin extension (KTX) libraries alongside our Android Java SDKs to give Kotlin developers the best of both worlds.
Today, we're happy to announce that these KTX libraries are out of Beta and recommended for all Firebase developers using Kotlin in their Android apps!
So what does this mean for you?
To get started with our KTX libraries, look for the -ktx suffix in the "Kotlin+KTX" section of our available Android libraries. As an example, let's see what it looks like to set up Remote Config with and without the KTX library.
-ktx
app/build.gradle (before)
implementation 'com.google.firebase:firebase-config:19.1.2'
MainActivity.kt (before)
val remoteConfig = FirebaseRemoteConfig.getInstance() val configSettings = FirebaseRemoteConfigSettings.Builder() .setMinimumFetchIntervalInSeconds(3600) .setFetchTimeoutInSeconds(60) .build() remoteConfig.setConfigSettingsAsync(configSettings)
app/build.gradle (after)
// The -ktx library has a dependency on the firebase-config library implementation 'com.google.firebase:firebase-config-ktx:19.1.2'
MainActivity.kt (after)
// New global "Firebase" class val remoteConfig = Firebase.remoteConfig // New settings builder syntax val configSettings = remoteConfigSettings { minimumFetchIntervalInSeconds = 3600 fetchTimeoutInSeconds = 60 } remoteConfig.setConfigSettingsAsync(configSettings)
And the KTX libraries that we have available today are just the beginning, as we're working hard to add coverage for all Firebase products and add new Kotlin-focused features in the near future!
We wouldn't have been able to release these KTX libraries without the help of all the Kotlin enthusiasts in the Firebase community. We'd like to give a special shout out to Rosário Pereira Fernandes who contributed so much excellent code and documentation to the KTX effort.
If you have feedback or want to contribute, you can find us on GitHub.
Hello, game developers!
Well, this has certainly been a challenging couple of months. We had been looking forward to meeting you in person last week at the Game Developers Conference, sharing some updates, and hearing directly from all of you. But, obviously, plans change, and we're committed to doing whatever it takes to keep everybody safe. Even if it means recording session videos from our kid's bedroom and hoping the cat doesn't wander into the scene.
Still, our teams have been working hard to ensure you have all the tools and resources you need to build great games. This year at our digital Google for Games Developer Summit (which you can find here if you missed it), we announced some new features that will help you spend less time on infrastructure work, and more time on making your game fun and unique. Let's take a look at some of these now, shall we?
Cloud Firestore is our next generation, scalable NoSQL database in the cloud. It offers features that database aficionados love, like multi-region reliability (for five 9s of uptime), atomic transactions, robust offline support, and realtime listeners that let you build some really great gameplay experiences. And we're happy to announce that alpha versions of our SDKs are now available for C++ and Unity developers.
Cloud Firestore can be used in many different situations. You could use it to simply save your users' game state to the cloud. Or save a shared game state to be viewed by several different clients in a multiplayer game. Use it to post daily challenges or user-generated content that can be easily queried and viewed by millions of clients. Or build a sophisticated caching layer on top of your existing game server, so you can share your latest gameplay data from your role-playing game or collectible card game with millions of clients, without having to worry about them hitting your server directly.
Cloud Firestore for C++/Unity is open for anybody to download and use as an open alpha release. This alpha tag means it still has some rough edges here and there. Specifically, the Unity version of the SDK is missing some of the more advanced querying features. And there's a good chance the API will change in the coming months, which means you'll need to change your method names in the future. But we wanted to give you a chance to try it out, see what cool stuff you can build, and let us know how we can make it better.
And none of this is to say that the Realtime Database is going away -- it's still a great option for many situations. In fact, the Google Doodle team just used it to power the Loteria Google Doodle that ran on the Google homepage in December. But if you're a game developer who's been pining away for all the great new features that Cloud Firestore has available, you can stop all that pining and start building.
The Firebase Unity SDKs are now compatible with the Unity Package Manager. This means that in supported versions of Unity, Firebase will be easier to keep up to date and the Firebase plugin will no longer have to be mixed in with the rest of your game’s assets. The process of doing this is automated with an open source tool that used to be known as the Play Services Resolver, but is now known as the External Dependency Manager for Unity, or what we've been calling "EDM4U" around the office.
Note, of course, that using these tools are completely optional. We know that many of you prefer having manual control over all of your libraries, and if you want to keep managing them yourselves, you're more than welcome.
Our friends over at Google Analytics have built a number of new reports that will be of interest to game developers, business analysts, or anybody who wants to grow a successful gaming business.
They've added new dashboards centered around user acquisition, retention, user engagement, and monetization, along with some new reports and visualizations that you've been asking for, like First-time Buyers, Revenue Heartbeat, User Engagement (in game days), and trending DAU / MAU (a good measure of "stickiness").
These new reports are available for all Firebase developers if you've linked your Firebase project to a GA account. You'll just need to head on over to the Google Analytics console to see these reports in detail. For more information, be sure to read the Games reporting article in the Analytics help center.
And what better way to celebrate some new launches than with an updated product page on the Firebase website? Head on over to the new Firebase for Games product page to get a better idea of everything Firebase has to offer to the game developer community.
While we are disappointed that we couldn't spend last week seeing you all in person, we hope that what we've been able to share as part of the online summit has made you a little more interested in adding Firebase into your next new game. We have some documentation and videos to help get you started, and can't wait to see what you build next!
Stay safe, everyone!
This article was cross-posted from the Google Developer Blog. Firebase will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Firebase even more powerful for game developers!
Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.
Google for Games Developer Summit
The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.
Here are some types of sessions to expect:
Sign up to stay informed at g.co/gamedevsummit.
Support for the game developer community
We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.
We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.
We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.
Stability is critical to your app’s success, so we’ve continued to enhance Firebase with tools to help you maintain high quality apps. This includes bringing the best of Fabric’s crash reporting tools to Firebase. Many of you have made the move from Fabric to Firebase yet still have questions like “Why do I still have ‘Fabric’ everywhere in my code?” or “Why does it feel like I am in Firebase, yet still in Fabric?”
We can now lay your questions to rest. We're excited to announce Firebase Crashlytics SDK is in Beta!
With the Firebase Crashlytics SDK, you can remove all Fabric dependencies, such as references to Fabric’s APIs in your code, giving you a much cleaner codebase.
The Firebase Crashlytics SDK is also designed to be intuitive and consistent with all other Firebase SDKs. For example, the Crashlytics SDK has consistent package names, API design, and initialization as other Firebase SDKs.
The Crashlytics SDK also supports Mac Catalyst apps, in addition to iOS, macOS, and tvOS apps. This new feature makes it easier for you to continue building apps for Apple devices.
We’ve also open-sourced the Crashlytics SDK to further increase the extensibility and transparency of our platform.
Combining analytics data and crashes helps you unlock additional insights into your app’s stability. The Firebase Crashlytics SDK works seamlessly with the Google Analytics SDK to provide features such as crash-free statistics, the Latest Release report, and Breadcrumbs. With Breadcrumbs you can see the steps a user took that led to a crash. This insight helps you reproduce and fix issues quickly. Google Analytics replaces Fabric's legacy analytics engine, Answers, so we encourage you to add Google Analytics to your apps.
Try it out!
Ready to begin developing with Firebase Crashlytics SDK? If you are upgrading from the legacy Fabric Crashlytics SDK, read our upgrade guide. Developers new to Crashlytics should begin with our getting started docs. Interested in the Crashlytics source code? View our Android and iOS repositories on GitHub.
We'd love to hear your feedback. As always, you can reach out to us through our official support page. Happy developing!
Did you play the interactive Google Doodle for the Mexican card game “Lotería” last December? If not, you can still check it out here. Lotería is a multiplayer bingo-style game that supports up to five players per room. In the digitized Doodle version, you can play with random people around the world or create a private game with your friends.
The Lotería game was developed in JavaScript primarily by one engineer over a few months, and the game's usage jumped from no players to millions literally overnight. The multiplayer component that supported it all was built entirely with the Firebase Realtime Database, which meant we could spend more time developing a great user experience, and less time worrying about infrastructure. Let's look into how we did it!
/games/{gameId}/deal = {card, time, countDown}
To detect the winner, all players listen to another database location at /games/{gameId}/winner. When a player clicks “Lotería!” and has a valid winning pattern on their board, we write their ID to that location.
/games/{gameId}/winner.
Often, there’s a close tie, so we use Reference.transaction to ensure that only the first player to call, “Lotería!” is declared the winner. We do this by making sure that /games/{gameId}/winner doesn’t already have an existing value before we write anything to that location.
Reference.transaction
/games/{gameId}/winner
To create random public games, we utilized Cloud Functions for Firebase in conjunction with the Realtime Database.
When a player selects “Random Match,” their player ID is written to the location /queue/. A Cloud Function is set up to trigger when a new entry is created, and it checks whether we have enough players to start a game. If so, it creates the game at /games/{gameId}, and writes the gameId to each player's entry, like so: /players/{playerId}/gameId = {gameId}
/queue/
/games/{gameId}
/players/{playerId}/gameId = {gameId}
Players listen to gameId on their own database entries, so they know when to transition to the gameplay screen.
gameId
Since there are a lot of players connecting simultaneously, and the Cloud Function is asynchronous, we once again used a transaction to ensure that players are removed from the queue and placed into games atomically. Making one game at a time atomically could create a bottleneck, so instead we create as many games as possible in one transaction.
Interactive Google Doodles get millions of players, so we needed to make sure that the database could handle the load. To do this, we sharded the database into multiple instances. Each instance can handle a limited amount of traffic, so we estimated how much traffic we expected to have. To do this, we wrote a load testing bot that could be run repeatedly and measured how much load this generated on a single instance. Then, we extrapolated that number to how many players we expected, which then gave us the number of instances we might need.
However, there is a downside to having too many instances: if players are spread too thinly, it might take longer for enough to connect to one instance to start a game. To solve this problem, we created an entry in the default database instance called “shards.” This was a number that could be adjusted from 1 to the maximum number of shards we created. Clients read this value and only used shards in that range. Since the Doodle was only live on the Google homepage for a short time, we updated the shards value manually through the Firebase Console, setting it lower when there was less traffic, and higher when there were spikes. Naturally, this process could be automated for a longer-running application.
Update: On Friday, February 28th, GDC 2020 organizers made the difficult decision to postpone the conference. We understand and support this decision, as we have to prioritize the health and safety of our community. Although we won’t be connecting in-person this year, we’re still excited to share the latest announcements from Firebase with you in a digital experience. Check back soon at g.co/gdc2020 for more details.
Cross-posting from the Google Developer Blog. Firebase will once again be at the Game Developers Conference to meet with you and share how we're making Firebase even more powerful for game developers!
We’re excited to see you at the upcoming Game Developers Conference (GDC) in San Francisco. Join us March 16th-20th, 2020 to learn about new products and solutions from Google that will help developers for all platforms take their game to the next level. If you can’t make it in person, sign up to keep up to date with our announcements and view the livestream.
Everything kicks off with the Google for Games Developer Summit Keynote on Monday, March 16th where product leaders from across Google will share the newest announcements for game developers. After the keynote, join in on two days of developer sessions and learn how to use Google solutions to create great games, connect with more players, and scale your business. Check out the agenda today.
Starting Wednesday, March 18th, visit our booth in the GDC Expo to experience demos and meet one-on-one with Google product experts.
If you can’t attend GDC in-person, watch the Keynote and other Developer Summit sessions via the live stream at g.co/gdc2020.
We’ll be sharing more details about what we have planned at GDC in the coming weeks — be sure to sign up to be among the first to hear the latest updates. On-site events are part of the official Game Developers Conference and require a pass to attend.
See you there!
See the full agenda
It's been over a year since we first announced Firebase In-App Messaging to help you guide app users who are actively using your app by sending them targeted and contextual messages. In-App Messaging allows you to communicate with your most valuable users and deepen their engagement by surfacing relevant offers, information, and tips as they use your app.
We have been actively working on adding more features and expanding on the capabilities of Firebase In-App messaging (such as new message layouts), and we’re excited to highlight another new feature today - the ability to auto-translate your message into multiple languages using Google Translate.
As your app user base expands into more countries and languages, it's important to make sure messages are localized for each recipient to improve engagement, and for that we have added an easy way to translate your message to many languages. To get started is simple.
1. First choose your message style and content.
2. Set your target criteria
Then in the targeting section, when you select your app, Firebase will look at your audience and determine if localizing message content would help, and provide you a helpful nudge to provide localized content:
3. Click on Localize, and you will see the following dialog.
The first section of the dialog contains the default language and strings to be localized. And if you would like to provide alternative translated messages, click on Localize next to the language you would like.
When you click on Localize, you can either enter the localized message yourself, or click on the Translate button and let Google Translate automatically do the translation for you.
4. Save your translations
Once you are done with all the translations, click on Save and continue completing the rest of the steps for your messaging campaign.
Unless you provide localized messages, all your users - irregardless of their locale - will receive the message in the default language. If you provide translations, users who’s locale matches available translations will get the localized message, and everyone else will get the default message.
We have a lot more product updates in the works for this year, and look forward to sharing them with you. If you are not already using Firebase In-App Messaging, then 2020 is the year to start. Get started today by checking out the documentation:
Getting started with Firebase In-App Messaging
Real estate investing is a fantastic way to build a stream of passive income and grow your wealth. Numerous studies have pointed out that real estate investing has created more millionaires throughout history than any other form of investing (like this one and this one). So why don’t more people do it?
I asked myself this very question a few years ago after talking to a group of friends about the success I’ve had with real estate, and listening to their reasons why they think it’s out of their reach.
A common theme among them was that they viewed it as something too difficult to learn and master. There were too many steps, the learning curve was steep and there was a lot of room for mistakes for somebody just starting out, especially when analyzing the financial performance of potential investment properties.
Traditionally, most investors used spreadsheets to do the math - which works only if you know what and how you’re calculating something. But if you don’t know that, it’s very easy to make mistakes and overlook things. And no one wants to make mathematical errors before a huge purchase like an investment property.
Where do I even begin?!
And that’s when I had the idea to build DealCheck – a cloud-based, easy-to-use property analysis tool for real estate investors and agents. I wanted to create a platform that would help new investors learn the ropes and avoid costly mistakes, but at the same time provide the flexibility to perform more advanced analysis with a click of a button.
Making real estate investing easier and more accessible.
I was working as a front-end engineer at the time, so I knew I could build the UI myself, but what about the back-end, data storage, authentication, and a bunch of other things you need for a full-functioning cloud app?
I didn’t know anybody I could bring on as a co-founder, so I set out to research what technologies and platforms I could leverage to help me with the back-end and server infrastructure.
Firebase kept popping up again and again and I began to look at it in more detail. It was then recently acquired by Google and its collection of BaaS (backend-as-a-service) modules seemed to offer the exact solution I needed to build DealCheck.
I was especially impressed with the documentation for each feature and how well all of the different technologies could be tied together to create one unified platform.
It wasn’t long before I signed up and started building the first MVP of the app.
As the only developer on the project, I had limited time and resources to spend on building the back-end, so I set out to use every Firebase feature that was available at the time to my advantage.
My goal was actually to write as little server-side code as possible and instead focus on leveraging the different Firebase modules to solve three specific challenges:
The first one was authentication and user management. DealCheck’s users needed the ability to create their accounts so they can view and analyze properties on any device (more on that later). I wanted to have the ability to sign in with email, Facebook or a Google account.
Firebase Authentication was designed specifically for this purpose and I used it to handle pretty much the entire authentication flow. Out-of-the-box, it has support for all the major social networks, cross-network credential linking and the basic account management operations like email changes, password resets and account deletions.
There was no server-side code required at all – I just needed to build the UI on the front-end.
Email, Facebook and Google sign in powered by Firebase.
And as an added benefit, Firebase Authentication ties directly into the Realtime Database product to create a declarative permissions and access control framework that’s easy to implement and maintain. This helped me make sure user data was protected from unauthorized access, but also facilitate data sharing among users.
Next up was data storage. I knew that I wanted DealCheck’s users to be able to use the app and analyze properties online, on iOS and Android. So I needed a real-time, cloud-based database solution that could sync data across any device.
Syncing data across web and mobile is not easy!
Firebase Realtime Database is a NoSQL, JSON-based database solution that was designed exactly for this purpose, and I was actually surprised how great it worked. I used the official AngularJS bindings for Firebase on the front-end to read and write to it directly from the client.
I had to do some extra work on mobile to implement an offline mode with syncing after reconnections, but all-together the code required to make everything work was minimal.
As I mentioned, Firebase Authentication tied directly to the database to facilitate access control, so I really didn’t need to do anything extra there. And I was able to set up automatic daily backups of all the data with a click of a button.
Up to now, I had written exactly 0 lines of server-side code and everything was handled by the client directly. As DealCheck’s development progressed, however, I knew that I would need a server to handle some operations that could not be done in the client.
I wasn’t very experienced with server maintenance and DevOps, but fortunately the Firebase Cloud Functions product was able to solve all of my needs. Cloud Functions are essentially single-purpose functions that can be triggered (or executed) based on a specific HTTP request or events coming from the Authentication, Realtime Database or other Firebase products.
Each function can be run once based on a specific event trigger to perform its prescribed task. You don’t have to worry about provisioning a server instance or managing load – everything is done automatically for you by Firebase.
What’s even cooler, is that Cloud Functions can access the Realtime Database and Cloud Storage buckets of the same project, performing operations on them server-side, as needed.
This is how DealCheck processes subscription payments through Stripe, validates Apple and Google Play mobile subscription receipts, integrates with third-party APIs and updates database records without user interaction.
Bringing in sales comparable data from third-party providers into DealCheck.
Cloud Functions became the “glue” that tied the entire back-end infrastructure together.
The first version of the DealCheck app was built and launched in less than 5 months with just me on the development team. I definitely don’t think that would have been possible without Firebase powering the back-end infrastructure. Maybe the project wouldn’t have ever launched at all.
While Firebase is awesome for quick MVP development, it’s definitely designed to power production applications at scale as well. As DealCheck grew from a small side-project to one of the most popular real estate apps with over 100k users, all of the Firebase products that we use scaled to support the increasing load.
Moreover, the fantastic interoperability of all Firebase modules allows us to develop and release new features much faster because of the reduced coding requirements and ease of configuration.
So next time you’re looking to build an ambitious project with a small team – take a look at how Firebase can help you reduce development time and provide a suite of powerful tools that scale as your business grows.
This is exactly how DealCheck grew from a simple idea to make property analysis easier and faster, to an app that is helping tens of thousands of people grow their wealth and passive income through real estate investing. It’s a truly awesome and fulfilling experience to see your work positively impact so many people and it wouldn’t have been possible without Firebase.
We know that the web is one of the largest platforms developed on across the globe. We want to meet developers where they are, no matter what platform that may be using.
At I/O earlier this year, we announced Firebase Performance Monitoring for web. It was our next big step in bringing the complete suite of Firebase products to the web. And just a few weeks ago, at the Firebase Summit, we announced support for web apps in Google Analytics, Cloud Messaging and Remote Config! These new features give you insight into your web users, what they are doing inside your app, and help you create personalized experiences for them - just like you already do on native. Let’s take a closer look at all that is new for web developers in Firebase.
At the heart of a successful app and business strategy lies data. Analytics helps you understand how your user base is growing, who these users are, and what actions they are taking in your app. You can then use these insights to build tailored experiences that will delight, engage and retain your users.
If you're already comfortable using Google Analytics for your native apps, the web version of Analytics should look very familiar to you. But if you are new to Firebase, there are a few key components in Analytics we want to highlight:
Analytics also has a feature called audiences, which provides a way to segment users along attributes that are meaningful to you. For example, you can create an audience comprising all the users who performed a specific sequence of events in your app. These audiences now also work for users on the web, and membership can even be evaluated across multiple platforms by setting the user_id in the Analytics SDK.
Let’s take the example of an e-commerce app and a product review feature. One important thing to track in such an app is users who started writing a product review, and then left without completing it. Using audiences, we can create a user segment that represents exactly this group of users.
Example sequence of events “Started session” > “Started review” > “Canceled review”
We can create an audience representing that sequence in the Audience builder shown in the screenshot below:
In the next two sections we will show you how to combine audiences with Remote Config & Cloud Messaging to create personalized experiences for your users.
Remote Config (now works on web) gives you the power to alter your app for any segment of users without requiring you to release a new build. For example, you can segment users by geo and date (like Christmas) and infuse a holiday color palette into your app.
Going back to the product review example, say you want to show a custom message when any user who’s part of the “Abandoned reviewers” audience opens the app. You can now use that audience as the targeting condition for your Remote Config parameters across both your web and native apps. You could even strategically roll out new features to target audiences across web and native, so you can monitor regression and roll it back if you run into any issues.
Cloud Messaging has already been available for web for quite some time. What's new is that FCM for web is now integrated with Google Analytics, which allows you to send targeted notifications to your users based on their behavior in your app. You can do this by leveraging both new web specific signals (like browser type) and Google Analytics’ custom audiences and user properties. It’s another great way for you to personalize your users’ app experiences.
What’s also new is that campaigns can be easily configured in the Firebase console. Additionally, the funnel report that tracks campaign success also now works for web campaigns. All you need to do is specify an Analytics conversion event when setting up your campaign and the report will track success automatically.
Let’s go back to our favorite product review example. Now that we have a way to identify the audience who haven’t completed their reviews, we can re-engage them with tailored notifications for users on the native app as well as users on the web app. Since the audience is already being populated by Google Analytics with these user segments, you now simply have to go to Firebase Cloud Messaging in the Firebase console and create a campaign which sends a message to these audiences on their respective platforms.
Once we’ve started our messaging re-engagement campaign, we can use Google Analytics to create closed funnels to view the performance of the engagement workflow on any specific platform.
To use any of what we just described you, take a look at the instructions for implementing and integrating the web analytics SDK here. One important note is that if you are already using analytics for your native apps, you will first need to upgrade to the full Google Analytics experience in order to access web analytics. The Remote Config SDK for web is currently in Beta and you can access it here. To get started with FCM for web, simply follow the instructions here.
We hope you’re as excited about these new web features as we are. The above example illustrates one way you can use the new web analytics features to improve your web app experience and engage users, but there are many more ways these features can be used together. We can’t wait to hear what use cases you’ve implemented in your own web apps. As always, you can reach out to us on StackOverflow and through our official support page to let us know and give us feedback. Happy Developing!
