Posted by the Firebase team
The COVID-19 pandemic of 2020 brought changes and challenges for many businesses. During this time, we saw developers use resilience and ingenuity to adapt their apps and business models to these new circumstances. For GameNexa Studios, an app developer and consultancy based in India, one of the biggest challenges they faced this year was to figure out how to evolve their monetization strategy in the face of declining ad revenue. The GameNexa team needed a data-driven approach to diversify their revenue stream across their portfolio so they turned to Firebase.
With 40 apps and games under their belt serving 5 million monthly users, GameNexa Studios had a well-established monetization strategy, but like many of their peers, it was disrupted by the COVID-19 pandemic. Previously, the company earned most of its income from ads in their free-to-download titles. However, when many of their advertisers slashed their budgets, GameNexa’s ad revenue dropped too.
To offset their losses, GameNexa needed to pivot from a one-size-fits-all strategy to a diversified revenue model. But diversifying revenue doesn’t mean bombarding users with more offers and in-app promotions - that could drive people away. The most effective monetization strategies are tailored to user preferences and behavior. So, GameNexa first used Google Analytics and Firebase Predictions to better understand their users and then grouped them into segments based on common characteristics like language, and predicted future behavior, like their propensity to make an in-app purchase.
After gaining insight into their users, GameNexa used Firebase Remote Config and Firebase A/B Testing to test new ad placement, formats, and different in-app promotions on each segment to find which offer resonated with each group. They also worked on improving their user experience with Firebase Crashlytics and Firebase Performance Monitoring.
As a result of these efforts, GameNexa saw a 2.5x increase in revenue from in-app purchases and they were able to bring their ad revenue back up to pre-COVID levels by doubling ad impressions. In addition, by creating customized in-app purchase packs for different audiences, GameNexa increased conversions by 6x. Inspired by their own success, GameNexa now plans on sharing what they’ve learned about the power of data-driven monetization and personalization with other developers through their app consultancy. Read their full story and get more details on how they used Firebase to grow and diversify their revenue in our new case study.
Today we launched TWO new features for the Firebase Realtime Database in beta.
First, we launched a new region for the Realtime Database, in Belgium, in addition to our existing region in the United States. If you would like to store your customer data in Europe, or if you’d like to reduce latency for customers in this part of the world, you can do so today.
Second, we launched a management API for the Realtime Database. With just a REST request you can list, create, update, delete, disable, and re-enable Realtime Database instances.
Once you upgrade your Firebase project to our pay as you go plan, it can contain many Realtime Database instances. You can use multiple database instances to scale beyond the limits of a single database instance, balance load, optimize performance, and more. You can even have a mix of database instances in the United States and Belgium in a single project.
Using the new API, adding another Realtime Database instance to a project is as simple as running curl. You can specify either us-central1 (United States) or europe-west1 (Belgium) for location-id.
curl
us-central1
europe-west1
location-id
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -X POST \ https://firebasedatabase.googleapis.com/v1beta/projects/{project-number}/locations/{location-id}/instances\?database_id\={my-new-database-id}
Let’s list the instances in our project to see if the new database shows up:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://firebasedatabase.googleapis.com/v1beta/projects/{project-number}/locations/{location-id}/instances
We get this response, showing both our default Realtime Database instance (with type DEFAULT_DATABASE) and the new one we just created (type USER_DATABASE)
DEFAULT_DATABASE
USER_DATABASE
{ "instances": [ { "name": "projects/{project-number}/locations/{location-id}/instances/{default-database-id}", "project": "projects/{project-number}", "databaseUrl": "https://{default-database-id}.firebaseio.com", "type": "DEFAULT_DATABASE", "state": "ACTIVE" }, { "name": "projects/{project-number}/locations/{location-id}/instances/{my-new-database-id}", "project": "projects/{project-number}", "databaseUrl": "https://{my-new-database-id}.firebaseio.com", "type": "USER_DATABASE", "state": "ACTIVE" } ] }
You can use similar calls to disable, re-enable, and delete instances. Have a look at the documentation to learn more about the commands.
This API is available now, and we have enabled it on existing Firebase projects that have used the Realtime Database in the past month. If you ever use the Google Cloud console, you’ll see the API listed there as well. The Firebase console will soon let you create databases in Belgium as well.
We’re excited about these big advances for the Realtime Database, and we hope you are too!
Hello Firebase Developers!
Dependency management is probably one of your least favorite aspects when it comes to app development - whether that’s managing dependencies for an app that you’re building or for an open source project that you’re maintaining.
That’s why we’ve been working on improving dependency management and versioning for our Firebase iOS SDKs, and putting the spotlight on our Firebase BoM (“Bill of Materials”) for Android.
For both platforms, our goal is to make it easy to know which SDK versions to pick for the products you want to use without any muss or fuss, and move straight on to developing your app. There are few other really important motivating factors too.
Let’s get into the specifics for each platform.
Previously, each Firebase SDK for each product maintained its own version number - for both the SDK and the CocoaPod itself. Whenever an SDK got updated, both the SDK and CocoaPod version numbers would get updated too.
This approach was helpful in that each product could update independently more easily, but we’ve heard your feedback that it also had some drawbacks:
That’s why we’re moving to a unified versioning model for all our Firebase SDKs moving forward.
Every Firebase product will now use the same unified version number for its iOS SDK. At each release of a major or minor update, this version number will update for all iOS SDKs. That means that you can just select the same Firebase SDK version number across all Firebase products you want to use - they’ll be designed to be compatible with each other. For any patch releases, the affected product will be fully compatible with all other products at the same minor version. You can run `pod update` to install the latest patches for all products.
There are also a few more reasons why we think moving to this unified versioning model will help iOS developers in the long run.
We’ve been making more and more of our iOS SDKs open source, which has been great for community engagement, but contributing to them hasn’t always been easy.
In the previous model, whenever a product had a new release, a new individualized tag was created for that product. When it came to integrating multiple Firebase products together, these individualized tags made it difficult to figure out which product's tags matched with each other - both from the perspective of using Firebase to build an app, or to contribute to the open source libraries.
With the unified versioning model, you can directly map your Firebase SDK integrations to a single tag in GitHub for both CocoaPods and the Swift Package Manager. The new model also makes it easier for contributors to understand our release and versioning strategy, and make contributions going forward.
While our current release strategy still revolves around CocoaPods, the versioning system we’re now using closely mirrors the conventions used in the Swift Package Manager as well.
Getting ready for that versioning system was additional motivation to move to this model. In fact, the Swift Package Manager for Firebase is now in beta if you want to give it a try.
Over in the Android world, we’re leveraging Gradle’s support for Android BoMs (or “Bill of Materials”), which provides a way to manage the versions for all the libraries you use by specifying a single BoM version for your app.
Firebase has its own “Firebase Android BoM” which has been around for a while, but we’re putting it back into the spotlight as it’ll be the recommended way to manage your library dependencies going forward. When using the Firebase BoM, all you need to do is set a single Firebase Android version in your app - the BoM’s version - and the BoM will pull in the versions of the libraries mapped to that specific BoM.
When you use the Firebase BoM, you’ll still need to declare which Firebase libraries you want to use in your app, but you will no longer need to specify which versions of those libraries your app will require. Instead, just specify the BoM version you want to use, and the BoM will manage which library version to use. And all these versions will be cross-compatible with each other!
Here's an example build.gradle file that uses the BoM:
dependencies { // Import the Firebase BoM implementation platform('com.google.firebase:firebase-bom:25.11.0') // When using the BoM, don't specify versions for Firebase dependencies implementation 'com.google.firebase:firebase-analytics' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
If necessary, you can override the library version specified in the BoM by including the desired version in the library's dependency declaration. For example:
dependencies { implementation platform('com.google.firebase:firebase-bom:25.11.0') implementation 'com.google.firebase:firebase-analytics:17.5.0' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
The goal behind using the Firebase BoM, though, is to avoid needing to do this in your project. Each BoM version is curated to include library versions that all play well together.
The improvements mentioned above are a start to further improvements we plan to make in the near future - from better support for the Swift Package Manager, to providing easier getting started journeys in the Firebase Assistant plugin in Android Studio.
Please stay tuned for more, and as always, reach out to us on the GitHub issue trackers for the Firebase iOS SDK and the Firebase Android SDK to let us know what you think about these updates.
It’s hard to believe it’s already been a year since we launched App Distribution to help you with your internal testing on Android and iOS! Based on all your valuable feedback, we’re excited to share a few updates we made to App Distribution since launch.
Most customers automate their releases with App Distribution to quickly send their latest feature branch builds to their QA teams or release candidate builds to their company. This typically means distributing daily or even multiple times per day, which quickly becomes a long list of releases!
To help make this list more manageable, we added release search in the Firebase App Distribution console and tester apps. Now, it’s easy to search by version or release notes to find, manage, and test the exact release you’re looking to get feedback on.
In-app build alerts notify iOS testers when new builds are available to them, making it easier for testers to install the update right from your test app. In-app build alerts are powered through our lightweight open sourced SDK, which you can quickly integrate into your test app.
To increase download speeds for testers around the world using different devices and network connections, we made improvements to our backend systems that handle uploads and downloads. Now testers have a more reliable experience, with some testers experiencing up to 10 times faster downloads.
We recently released version 2.0 of our fastlane plugin, a major rewrite that stripped away the Firebase CLI as a dependency and makes it easier for you to set up your CI. Now, using App Distribution with fastlane is as easy as running `fastlane add_plugin firebase_app_distribution` to get up and running.
`fastlane add_plugin firebase_app_distribution`
All these improvements made to App Distribution wouldn’t be possible without the active Firebase community. With your help, we’ve been able to add more features to our fastlane plugin and it’s possible to use App Distribution in even more ways. Special shout outs to @gunes_dev, who wrote and maintains our Bitrise Step and @ziebawojtek for all of their contributions and support of the App Distribution GitHub Action.
Your feedback has helped shaped our product and our team loves hearing from developers in the #app-distributions Firebase Community Slack channel - come say hi!
There's a lot more in the works with some exciting features launching soon; you can sign up for our Alpha Program to be eligible to try them out. For developers looking to get started with App Distribution, check out our docs.
Posted by Jason Mill, Flamelink
If you read this blog, chances are you’re a fan of Firebase and the power it gives developers to build incredible products. At Flamelink we’ve used it extensively to build websites, apps and other digital platforms for clients of our agency. Firebase helps take your app from proof of concept to production quickly and easily.
While Firebase backend services like Realtime Database and Cloud Firestore are a great experience for developers, we have struggled to hand over full control to some of our less-technical clients. We found they weren’t comfortable editing data directly, so we were inundated with requests to do small content updates.
We tried many different solutions to make it possible for our clients to update their content - from hard-coding content on the frontend, to syncing Firebase with Google Sheets, and everything in between. We even tried coaching our non-developer clients on how to update content in the Firebase console, but the console was just too powerful for their needs.
So we created Flamelink, a headless Content Management System (CMS) built specifically for Firebase which supports both Cloud Firestore and the Realtime Database. Flamelink allows developers to leverage the power of Firebase and the Google Cloud Platform while giving non-developers an intuitive interface to manage their content.
In this tutorial, we’ll show you how to connect Flamelink to your Firebase project, and quickly get started building an app with Angular, Firebase and Flamelink. As with any Firebase project, you’re not limited to JavaScript, you can use any of the languages that Firebase supports.
A special thanks to our friend Erik Slack for providing this repo of example code to help you get started. You can find him on GitHub, LinkedIn or Twitter.
For the purposes of this tutorial, we’ll be creating a Bedtime Stories app, using long and short story examples to help illustrate how Flamelink can help you manage your content. You can clone the repo by running:
git clone https://github.com/erik-slack/Angular-Flamelink-Firebase.git
In this article, we’ll be covering these steps:
Let’s dive in!
If you haven’t already, go to the Firebase console and sign in. Once you’ve done that, you’ll want to select “Add project” and enter a name for your app.
Once you’ve done this, you’ll be asked a few more questions. For the purposes of this tutorial the choices you make won't matter. After you answer those questions your new Firebase project will be ready!
In this step, we’ll be configuring Firebase Authentication and Security Rules. This is to ensure that you can create, read and update content or files via the Flamelink interface.
First, in the Authentication section of the Firebase console, enable your prefered sign-in methods. You’ll need to configure this to log into your Firebase project via the Flamelink interface.
Then, confirm your authorized domains. Be sure to add the app.flamelink.io domain. This step allows your project’s Firebase Authentication to be used directly by Flamelink.
Next we’ll need to configure the Security Rules. In this tutorial, we’ll be using Cloud Firestore, so look for the Firestore section in the side-panel, create a database if necessary, and then select the Rules tab.
We'll start with the following rules. Note that these rules will allow any user to read / write any content in your database so you’ll need to write more secure rules before launching. These rules are not secure and you should not use them in a real application. For information on how to write more secure rules, check out the documentation.
rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if request.auth.uid != null; } } }
We’ll also need to configure the rules for Cloud Storage for Firebase. Go to the Storage section in the left panel and select the Rules tab once again.
Copy the below code snippet into your Storage Rules:
rules_version = '2'; service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if request.auth != null; } match /flamelink/{allPaths=**} { allow read; allow write: if request.auth != null; } } }
Again, these rules are the bare-minimum needed to get a demo working and they are not recommended for production. You must write secure rules before launching your app.
At this point, you'll need to link your Firebase project to a new Flamelink project. You can follow this tutorial video to help you get started.
First, create some schemas. A schema is a form view of your data to easily create your content in a repeatable, structured way. For the bedtime stories example project we used two schemas: shortStory and longStory.
shortStory
longStory
Then, using these schemas, let’s create 5 different Short Stories and 3 Long Stories with whatever filler content you’d like.
Remember, you don’t need to spend too much time on this, just have enough to start building your application. This content is meant to be managed by non-developer content editors and clients.
The sample app in this tutorial was built using nrwl/nx, so there’s a lot going on, but we will only be working with these files.
You’re welcome to explore / modify any other files in the project, get creative!
From the root of the project directory, run either npm install (or yarn install) to install the dependencies.
npm install
yarn install
Because this is an Angular site, we'll use the AngularFire library to quickly and easily add authentication. Let’s create FirebaseService in shared/feature/core. This lets you keep track of auth and allows you to easily sign out. We’ll add FirebaseUI to your login component markup to provide a quick and easy authentication dialog for your users.
FirebaseService
shared/feature/core
<firebase-ui (signInSuccessWithAuthResult)="successCallback($event)" (signInFailure)="errorCallback($event)"> </firebase-ui>
When a use logs in successfully, we want to have it route the logged in user to home.module so add this to your ngOnInit function in the home.component.ts:
home.module
ngOnInit
home.component.ts
this.firebaseService.authState$.subscribe( this.firebaseAuthChangeListener.bind(this));
Next we'll integrate the Flamelink SDK, which is powered by the Firebase SDK, to load content into our app. To do this, create a new service called FlamelinkService in shared/feature/core. This service will be used to subscribe and fetch data when a user is logged in.
Add this to your ngOnInit function in the home.html:
home.html
private firebaseAuthChangeListener(response): void { if (response) { this.loggedIn = true; this.shortStoriesRef = this.flameLinkService.getApp().content .subscribe({ schemaKey: 'shortStory', fields: ['name', 'author', 'text'], callback: (error, data) => { if (error) { return console.error(error); } console.log('data', data); this.shortStories = Object.values(data); this.shortStoriesFacade.loadShortStories(data); } }); this.longStoriesRef = this.flameLinkService.getApp().content .subscribe({ schemaKey: 'longStory', fields: ['name', 'author', 'sections'], callback: (error, data) => { if (error) { return console.error(error); } console.log('data', data); this.longStories = Object.values(data); // this.longStoriesFacade.loadLongStories(data); } }); } else { this.loggedIn = false; if (this.shortStoriesRef) { this.shortStoriesRef(); // unsubscribe from short stories listener } if (this.longStoriesRef) { this.longStoriesRef(); // unsubscribe from long stories listener } } }
Add this to your ngOnInit function in the home.component.ts:
<li *ngFor="let shortStory of shortStories"> <short-story [shortStory]="shortStory" (click)="storyClicked('short', shortStory)"> </short-story> </li>
Remember to update your security rules before launching. This tutorial used insecure security rules to get you up and running as quickly as possible, you will need to update them before releasing your app.
Here are two Flamelink-specific tutorials for writing Security Rules:
We built Flamelink to enhance the Firebase developer experience. Firebase is such a versatile platform, it’s been mind-blowing for us to see how developers are using Firebase and Flamelink to manage content in a diverse range of use cases. We’ve seen Android and iOS apps, PWAs, VR and AR experiences, IoT platforms, websites, blogs, e-commerce/retail platforms, and AI and ML applications that all leverage Firebase and the Google Cloud Platform. So head over to Flamelink.io, sign up for a 14-day free trial and create your first project.
Password-based sign-in remains a popular means of user authentication despite its weaknesses. For example, users frequently forget their passwords, requiring a password reset flow that can create friction for returning users; databases of passwords are routinely shared between bad actors; and, users often reuse insecure passwords across sites, which makes the problem of stolen passwords even worse. On the other hand, the password model of authentication is familiar to users and users expect to see it. For this reason, it's understandable that many developers want to implement some form of password-based sign-in in their apps.
Firebase and Google Cloud Identity Platform provide libraries to make password sign-in easy to implement for your users, but it's important to consider these authentication best practices to enable more secure sign-ins.
Before you launch your app, you should add additional restrictions to your API keys to limit the access they grant. Here are some steps you can take:
Visit our Applying API key restrictions documentation to learn more.
One way to improve security for users who sign in with passwords Is to use password management tools:
If your app deals with sensitive information, the industry best practice, and our recommendation, is to require MFA for user sign-in. This is especially important if your app deals with information such as financial data or medical records. You can add a second factor to most of Firebase Authentication’s sign-in methods, including email address and password, with Google Cloud Identity Platform. To get started, enable Identity Platform in your project, then add MFA to your apps (iOS, Android, Web). Your existing Firebase Authentication code will continue to work after you enable Identity Platform.
If you’re not using MFA, other strong options for user authentication with Firebase are to use one of the social sign-in providers supported by Firebase Authentication such as Google, Facebook, and Apple, or to use email link sign in.
To serve users who don't have or use email addresses, Firebase and Google Cloud Identity Platform provide phone authentication services. This is the best solution for many user bases, but it has its own security caveats: possession of a phone number can be easily transferred between users, and, on devices with multiple user profiles, any user that can receive SMS messages can sign in to an account using the device's phone number. (See the docs for iOS, Android, Web, Unity, C++.)
We recognize the ubiquity of the password model and we will continue working to improve the security of password based sign-in.
Some Firebase Android SDKs depend on Google Play services, which means they will only run on devices and emulators with Google Play services installed. These Firebase SDKs communicate with the Google Play services background service on the device to provide a secure, up-to-date, and lightweight API to your app.
Certain Android devices do not have Google Play services installed. Previously, this meant developers had to make use of work-arounds to be able to be able to use these Firebase SDKs on such devices.
Today, we are pleased to announce that as of version 20.0.0 of the Firebase Authentication Android SDK (which is included in version 26.0.0 of the Firebase Android BoM), Firebase Authentication no longer depends on Google Play services. This means it is now easy to securely access Firebase products like Cloud Firestore, Realtime Database, and Cloud Storage from any Android device.
Firebase handles all of this behind the scenes, so you won't have to make any changes to your code base. All you have to do is to update your Gradle dependencies to the latest version (26.0.0) of the Firebase Android BoM, recompile, and you're good to go.
dependencies { // ... // Import the Firebase BoM implementation platform('com.google.firebase:firebase-bom:26.0.0') // When using the BoM, you don't specify versions in Firebase library dependencies // For example, declare the dependencies for Firebase Authentication and Cloud Firestore implementation 'com.google.firebase:firebase-auth' implementation 'com.google.firebase:firebase-firestore' }
In case you've used a workaround to be able to use Firebase Auth on non-GMS devices, you can now remove this workaround from your app.
In order to remove the dependency on Google Play services without compromising security, the new version of the Firebase Authentication SDK for Android made some changes to Phone Number Authentication. In particular, Firebase must be able to verify that phone number sign-in requests are coming from your app. On devices with Google Play services installed, Firebase will use Android SafetyNet to establish the device as legitimate. If your app makes use of Phone Number Authentication, you should enable the SafetyNet API. In the event that SafetyNet cannot be used (for example, on devices without Google Play services), Firebase will use reCAPTCHA verification to complete the phone sign-in flow.
It is worth noting that the reCAPTCHA flow will only be triggered when SafetyNet is not available or the user's device doesn't pass suspicion checks. Nonetheless, you should ensure that both scenarios are working correctly. For example, you can call FirebaseAuth.getInstance().getFirebaseAuthSettings().forceRecaptchaFlowForTesting(); in your tests to force the reCAPTCHA flow. For more detail about testing, refer to the documentation, which goes into much more detail.
FirebaseAuth.getInstance().getFirebaseAuthSettings().forceRecaptchaFlowForTesting();
For a complete list of Firebase SDKs that require Google Play services, refer to this overview.
If you have feedback or want to contribute, you can find us on GitHub.
Over the past few months, we’ve seen that apps not only improve the way we live, they also enhance our ability to adapt to change. In 2020, more businesses and families have turned to apps to stay connected, productive, and entertained. At the same time, our developer community has stepped up to build and scale the apps people are relying on. Our team, alongside the rest of Google, has strived to be supportive in this moment. Our mission is to help you succeed by making it easy to build and operate apps.
Last year, we shared that 2 million apps actively use Firebase every month. Now, that number has grown to over 2.5 million monthly active apps, which includes global businesses like Gameloft and Alibaba, as well as innovative startups like Classkick. Classkick is a full-spectrum learning platform with a backend powered by our Realtime Database and supported by Google Cloud. When the COVID-19 pandemic forced schools to close, Classkick onboarded thousands of teachers and school administrators to their platform. With Firebase, they were able to scale to meet this new demand so students could continue to learn effectively from home and stay engaged with their teachers and classmates.
Classkick is helping students learn effectively from home
Classkick is just one example from our incredible community of how apps are helping people adapt to their new surroundings. It’s stories like these that inspire us to keep making Firebase better. Every year at Firebase Summit, we share updates on how we can help you accelerate app development, run your app efficiently, and tailor Firebase to suit your needs. Read on to learn what’s new at our digital Firebase Summit 2020, and view the sessions and resources on our summit website.
We’re continuing to invest in tools that speed up your app development so you can deliver value to your users in less time.
Introducing the Authentication emulator for rapid iteration and local development
Last year, we launched the Firebase Emulator Suite to let you run emulated versions of our backend products for a faster and safer development experience. A few months ago, we introduced you to the local emulator UI, which makes it possible to run services locally via a web app with a distinguishable UI, and comes with features like advanced data editing and searching. The Emulator Suite supports Hosting, Realtime Database, Firestore, Cloud Functions, and Cloud Pub/Sub - and now, we’ve added support for Firebase Authentication.
The Emulator Suite now includes support for Authentication
This means you can test the entire user management process - from user creation to Function trigger to sending updates to Firestore, and even fuzzy log searches to debug interactions between the emulators and your application - on your local machine. You can also use the new auth emulator to run integration tests that rely on authentication. The Emulator Suite, now with Firebase Authentication, allows you to shift to a local-first developer workflow so you can experiment and rapidly iterate without touching production data, incurring costs, or worrying that you’ll break something. Check out our documentation to get started.
New Hosting preview channels let you see changes before publishing
Web development can be cumbersome and complicated. With Firebase Hosting, you can deploy secure, fast-loading web apps and landing pages that are backed by a global CDN in less time, and with less hassle. Recently, we added new features that many of you have been asking for, including an integration with Cloud Logging to give you more server-side analytics, support for Brotli compression to boost your site performance, and improved support for localized content.
Our latest update to Firebase Hosting, preview channels, lets you see your changes before publishing them to your site. Now, you can deploy changes to a preview channel in seconds with a single command and generate an obscured unique URL to share with your team. Preview channels not only let you check that your changes look as intended right away, they also make collaboration quicker and easier even if you’re working across a distributed team. Try them out today!
Hosting’s new preview channels let you see changes before publishing
More Extensions for adding features and functionality
At last year’s Firebase Summit, we launched Firebase Extensions; pre-packaged solutions that automate common tasks in your projects and let you add new functionality in fewer steps. Since then, we’ve partnered with Stripe to release the Send Invoices using Stripe and the Run Subscription Payments with Stripe extensions. These extensions let you integrate the Stripe payments platform with Firebase without requiring you to learn Stripe’s API.
Today, we’re sharing a preview of another extension through our Alpha Program, called Detect Online Presence. Detect Online Presence shows you which users or devices are currently online and stores that data in Cloud Firestore. If you’re developing a game or a social app, you can use this extension to let your users know when their friends are online for a friendly match or chat. Join our Alpha Program to try it out!
Detect Online Presence is our newest Firebase Extension, available in Alpha
In addition to accelerating app development, Firebase provides actionable data so you can optimize your app - and ultimately, keep users happy.
Redesigned Performance Monitoring dashboard to help you focus on critical metrics
Any time you release a new version of your app, it’s important to pay attention to stability and performance metrics to ensure your users have a fast, high-quality experience. Firebase Performance Monitoring gathers and presents data about your app’s performance to show you exactly what’s happening in your app - and when users are encountering slowness. But sometimes, there’s so much information, it can be hard to focus on what’s important.
To help you hone in on key insights, we’re excited to unveil the redesigned Performance Monitoring dashboard. This new dashboard makes it crystal clear if one of your critical metrics needs attention so that you can take action, and it’s customizable, allowing you to bring the metrics you care about most to the forefront. We’ve made this dashboard available to everyone - just head on over to the console and add the metrics that matter to you.
The redesigned Performance Monitoring dashboard brings critical metrics to the forefront
New organizational and targeting tools for Remote Config
As people start using your app, you’ll want to delight them with new features, promotions, and personalization so they stick around. With Firebase Remote Config, you can dynamically alter your app, safely test and release new features, and stay in control of the whole experience - without having to publish a new version. However, as your project gets bigger, it might become hard to maintain and navigate through your app config. Over the past few months, we’ve added new features to help you better organize, visualize, and target your parameters so you can manage your app config more efficiently.
First, we added information about experiments into the Remote Config dashboard and launched parameter groups. Then, we made it possible to sort parameters alphabetically and enhanced the search tool. On top of that, we improved version targeting by making it available for iOS and adding support for semantic versioning, so you can use numeric operators like “>=” to target specific app versions without resorting to complicated regular expressions.
Improved version targeting in Remote Config
Most recently, we launched config metrics to give you more visibility into how your app configuration is behaving for users so you can find and fix incorrect configurations quickly. These config metrics include realtime fetch requests, which allow you to monitor rollouts of a new set of values, and fetch percentages, which show you the distribution of parameter values across users. For example, when you see a smaller fetch percentage for a condition than expected, it signals that the wrong users may be exposed to the intended values.
Real-time config metrics for Remote Config
When your app and business grow, your development challenges may become more complex. We’re working to give you automation capabilities, such as Crashlytics BigQuery streaming, and more control and flexibility so you can adapt Firebase to fit your sophisticated needs.
New Google Analytics APIs for better data management
One of the key factors in scaling a successful app is knowing how your users are interacting with it. Our robust integration with Google Analytics helps you understand what actions users are taking inside your app, where they're spending their time, and why they churn -- so you can make smarter decisions. Last year, we announced a significant new upgrade in Google Analytics that gave you a single view of customer engagement across both native apps and web-powered ones. Since then, we’ve added new features like the setDefaultEventParameters and powerful new ecommerce measurement, which you can read about in this blog post.
Today, we're excited to announce three new APIs that give you more control so you can collect, record, and manage your data in a way that suits your growing business. The first one, the Google Analytics 4 Measurement Protocol, lets you log events directly to Google Analytics. This is especially useful for developers who want to augment their client-side data with server-to-server calls to gain new insights. For those of you who want to create your own custom dashboards, the Data API, which is the second new API, gives you programmatic access to your Google Analytics reporting data. Finally, the Admin API gives you the ability to configure your Analytics account and set user permissions.
Google Analytics 4 Measurement Protocol lets you log events directly to Google Analytics
Introducing imported segments for increased targeting flexibility
Over the years, we’ve seen many of you take advantage of our BigQuery integration by exporting data from Firebase, joining it with data from other channels, running sophisticated analysis - and even creating your own custom user segments in BigQuery. Now, we’re giving you the power to bring these custom segments back from BigQuery into Firebase with the launch of imported segments! This means you can target any custom segment with products like Remote Config, Cloud Messaging, and In-App Messaging. For example, if you have an ecommerce app and a physical storefront, you can import data from offline sources - like your store - and send those users an in-app promotion with In-App Messaging.
This feature is available through Firebase's BigQuery integration. To get started, simply create your custom segment and import it into your BigQuery dataset. Then, Firebase will be able to read that data and make those segments available for targeting. We built imported segments to give you more control and flexibility to target your users.
New imported segments let you bring custom segments from BigQuery into Firebase
With these improvements to Firebase, we aim to make app development faster and easier so you can stay focused on creating the amazing app experiences that people need to stay productive, connected, and entertained. People are relying on your apps to adapt and thrive in our changing world. You can rely on us to build, operate, and scale successful apps - in 2020 and beyond.
For more resources and content from Firebase Summit 2020, be sure to check out our summit website, and if you’d like a sneak peek of what’s coming next, join our Alpha program.
We graduated the Firebase Crashlytics SDK to General Availability (GA) back in June, and today we are encouraging you to migrate your apps from the Fabric SDK to the Firebase Crashlytics SDK. On November 15th, we’ll be sunsetting the legacy Fabric SDK, meaning any apps that are still using the Fabric SDK will no longer report crashes.
The Firebase Crashlytics SDK can now upload crashes after an app has closed, allowing you to receive crash data in more real time on Android! We've been tracking how the Firebase Crashlytics SDK performs, and we estimate the new SDK captures ~30% more Android crashes, and twice as many on the actual day of the crash.
Additionally, we streamlined our Crashlytics Gradle Plugin, with a new API in the build.gradle for managing and uploading mapping files and native symbol files. The total size of the plugin has also been reduced from 20+ MB to only 100 KB. In order to reduce build times the new plugin supports task configuration avoidance, and has improved up to date checking for gradle tasks. The new plugin will also support all modern Android Gradle Plugin features, such as cleaner support for disabling mapping file uploads of different flavors or buildtypes, and troubleshooting for 4.1+ versions of Android Studio.
We introduced platform support for Catalyst, App Clips for iOS 14, and community support for watchOS!
We also improved our upload-symbols conversion speed. Customers with large dSYMs should see a significant decrease in the time it takes to upload Crashlytics symbols, going from an average of 12 minutes for a 600 MB dSYM down to ~45 seconds!
We also enabled tvOS and macOS apps to share the same Crashlytics installation as an iOS app. You can now configure apps with the same bundle ID to be part of the same project. Meaning crash reports from every OS will be shown in the same dashboard.
In addition to technical improvements, our new SDK has APIs (e.g., package names, initialization code) designed to be consistent with other Firebase products, while also getting rid of references to the now deprecated fabric.io namespace. For example, we changed the Crashlytics initialization statement to use new methods that are more consistent with how other Firebase services are initialized:Fabric.with([Crashlytics.self])
Fabric.with([Crashlytics.self])
is no longer needed. It is now sufficient to simply call:
FirebaseApp.configure()
To continue getting crash reports, please follow our upgrade guide here. As we mentioned during our SDK GA announcement, November 15th will be the last day to upgrade before the legacy SDK is shutdown.
Lastly, we would like to personally thank all of our users who have been part of this journey from Fabric to Firebase with us. We hope to keep providing an amazing crash reporting experience for you. As always, please let us know your thoughts, and tell us how we can improve Crashlytics.
Happy coding!
Last year we announced that app developers could upgrade their Firebase projects to the next generation of app analytics. Upgrading enables them to view their app analytics data in Analytics and unlocks additional analysis capabilities.
Since then, we’ve expanded more Google Analytics features like automated and custom insights to also include app data so that you can more quickly identify key trends and anomalies from your app reporting. Earlier this year we introduced a gaming-specific Analytics experience to help mobile game developers more easily see how players move through the lifecycle. And to bring predictive insights to your site and app, we rolled out new predictive capabilities in Analytics – not only helping you reach customers most likely to purchase, but also giving you new ways to retain those less likely to return to your app via App campaigns in Google Ads.
We are continuing our investment in the app ecosystem and today, we are introducing new updates to Google Analytics that will help you get the insights you need to be ready for what’s next. Let’s take a look at some new features you can use when you upgrade.
The ability to measure all your revenue sources helps you monetize and grow your apps business. Soon, you’ll be able to view impression-level revenue data in Analytics from AdMob mediated revenue and from other third-party app advertising platforms – giving you a holistic view of your customers' lifetime value.
You can now view revenue from MoPub and ironsource in the new Analytics.
To get started, use the Google Analytics for Firebase SDK to log the ad_impression event whenever users see an ad impression. Be sure to include details such as the ad platform, source, currency and value.
With this revenue data now in Analytics, you can build audiences of high-value users and reach them for re-engagement campaigns. Third-party ad revenue will also soon be available as an experiment objective in A/B testing with Firebase. This way, you can test changes in user experience and see which drive more revenue through third-party platforms like MoPub or ironSource.
In the past, custom parameter reporting in Analytics for Firebase required you to register parameters for each event individually, which is time intensive and quickly uses up your quota. With event-scoped custom dimensions and metrics in the new Analytics, you only need to register each event once at the property level. You can also create and edit custom dimensions and metrics in the “All Events” section for your entire property. Plus, custom parameters you’ve previously created will automatically be upgraded to custom dimensions and metrics.
Create a custom dimension for your entire property.
Let’s say you’re a game app developer and you want your Analytics reports to show the levels at which users are starting, quitting, retrying, and ending your game. Previously, you’d need to register a custom event parameter for every single event. So with four events (starting, quitting, retrying, and ending) you’d have to register a parameter, “level,” four times. With the new Analytics, one single metric, “level,” is applied at the property level across all events — reducing the number of custom metrics your property uses.
When users are signed in on your Android or iOS app, Analytics can help you connect the customer journey across platforms and devices with a special view in your reporting. Now, you can use those signed-in user insights to create relevant audiences and reach them with personalized messages in remarketing campaigns. And with the new Analytics, we’ve provided you with more granular controls for ads personalization so that you can choose when to use your data to optimize ads and when to limit your data use for measurement.
Let’s say you’re a lifestyle retail brand with a conversion rate on your mobile app that surpasses the rate on your website. Taking a closer look, you might notice a cohort of returning customers who visit your website for lifestyle content but never make a purchase. You can group the signed-in visitors into an audience and reach out to them with a marketing promotion, driving them to your app, where they have a higher likelihood to convert. For those who convert within the app, you can understand their complete customer journey across platforms and more effectively analyze the success of your promotion and adjust from there.
The enhanced intelligence of Analytics provides additional revenue data to help improve your advertising strategy, simplified and efficient event measurement, and tailored experiences for increased conversion opportunities. If you aren't already using the new Google Analytics, upgrade to the new Google Analytics from the Firebase console today.
We’re excited to introduce two improvements to Remote Config’s app version targeting functionality - New semantic version number targeting and improved iOS version number targeting.
App version targeting is a powerful tool that helps you customize your app for users on specific versions. Whether it’s releasing a new feature behind a feature flag or running an A/B Test on your latest app version, Remote Config’s app version targeting makes this easy; all without needing to publish app updates. These new updates will help you target exactly the right versions of your Android and iOS apps.
Previously in Remote Config, our iOS version targeting was applied to your app’s
CFBundleVersion, which is commonly known as your app’s “build” number. This understandably generated some confusion! We’ve cleared up this confusion by renaming the previous iOS “version number” conditions to “build number” and introducing a new version condition for iOS, available in Firebase iOS SDK version 6.24.0 or above, that matches against your app’s CFBundleShortVersionString.
As developers, we’re constantly pushing out new versions of our apps. Often, we need to segment users who are on, above, or below a specific version number to enable some feature or fix. Writing regular expressions to target versions greater than or less than a specific version number is challenging and difficult to validate. That’s why we’ve made numeric operators like “greater than” and “less than” available for version number targeting!
Now it’s quick and easy to target versions of your app that came before, after, or exactly equal to a specific version number - no confusing regular expressions required! So for example if you want to target a fix for users between specific versions of your app, like version numbers after 1.2.3 but before 1.3.4, it's as easy as setting these two conditions in the console: Version >= 1.2.3, and Version < 1.3.4.
You can review our full set of targeting conditions here.
We hope you enjoy using the new version number targeting features, and let us know what you think! As always, you can reach out to us on StackOverflow or the official Firebase support site.
