Here at Firebase, we believe developers play an instrumental role in helping people learn, live better, go places, and grow businesses. That’s why we’re committed to providing you with integrated, easy-to-use, and extensible tools so you can continue to create experiences that billions of people not only rely on, but love.

Millions of apps actively use Firebase every month, created by businesses of all sizes, from startups to global enterprises. Your trust in us is what motivates and inspires us to make Firebase even better. Today, Firebase Summit is returning as a virtual event and we’re excited to unveil updates to our platform that will help you accelerate app development, run your app with confidence, and scale with ease. Read on for more details on what’s new, and don’t forget to check out all of the great content (including technical sessions, demos, pathways, and more) from the summit on our event website!

Jump to a particular section if you’re short on time, or read the entire article below.

Accelerate app development with new building blocks

• New Extensions for adding critical e-commerce features in less time
• Enhanced support for Apple platforms, game engines, and Flutter
• Strengthening app security with App Check
• Detailed documentation for upcoming Google Play Safety policies

Gain actionable insights to run your app with confidence

• New real-time alerts in Performance Monitoring
• Crashlytics adds Application Not Responding (ANR) reports and signals

Scale with ease by using powerful engagement tools

• Unified campaign management for Cloud Messaging and In-App Messaging
• Remote Config core improvements and beta launch of personalization

Accelerate app development with new building blocks

Firebase helps you get your app up and running by providing fully-managed infrastructure, with a streamlined experience, that lets you focus on what matters most.

New Extensions for adding critical e-commerce features in less time

Firebase Extensions are pre-packaged bundles of code that automate common development tasks and let you add functionality to your app in fewer steps. We’ve been partnering with companies you know and trust so you can integrate multiple services without learning new APIs. Our friends at Stripe recently added one-time payments and an SDK to their Run Payments with Stripe extension. Plus, they just launched a new feature that lets you accept over 15 different payment methods including wallets, bank redirects, and "Buy now, Pay later" within your app.

We’re also unveiling new Extensions for adding critical e-commerce features to your app in less time. These Extensions can help you ship and track merchandise with ShipEngine, re-engage users who abandon their shopping carts with SendGrid emails or SMS messages via Twilio, and implement search on Cloud Firestore with Elastic. You can even add a single interface to accept payments from multiple providers through Google Pay - which is especially handy if you’re launching your app internationally. For more details, go to the Firebase Extensions page and install them today! And if you need inspiration to get started, check out the code for our sample app on GitHub that uses over 17 different Extensions and view the deployed version at: https://karas-coffee.web.app/.

These new Extensions, built by our partners in collaboration with Firebase, help you add e-commerce features to your app much faster

Enhanced support for Apple platforms, game engines, and Flutter

We’re excited to announce that Firebase now offers beta level support for tvOS and macOS! This means you can use your favorite Firebase products to build and run apps that are compatible with Apple TVs and Macbooks - from a single codebase - and deliver a great, cross-device experience to users with less hassle. For example, when you add the Crashlytics SDK, you can identify critical crashes and even filter crashes by Apple device type or operating system right from the Firebase Crashlytics console.

With enhanced support for Apple platforms, you can deliver a smooth cross-device experience

If you’re a game developer, you’ll be happy to learn that many of our C++ SDKs now support Apple TV, so you can develop phenomenal Apple Arcade games with Firebase! On top of that, we’re expanding support for game frameworks and engines by making Cloud Firestore available for Unity and C++. This lets you add the power of Cloud Firestore to your game in seconds to store and sync your game data in near real-time, add offline support, and scale your game experience to support thousands of players.

Cloud Firestore is now available for Unity and C++, giving you real-time data synchronization capabilities and offline support

We’ve also made a number of big improvements to Crashlytics’ Unity and NDK SDKs to make it easier to debug your game’s codebase. Now, Crashlytics tracks a wider range of native crash types, and includes IL2CPP support for Unity games to show more symbolicated C++ frames that can be mapped to your C# code.

Finally, with the latest release of Dartpad, Flutter’s online editor, you can use Flutter and Firebase together to develop apps that reach users across platforms with just your browser. Flutter is Google's open source framework for building beautiful, natively compiled, multi-platform apps from a single codebase. It's a natural complement to Firebase's cross-platform backend services. Today, Dartpad supports Cloud Firestore and Firebase Authentication, with other Firebase products coming soon! Go to dartpad.dev and import the Firebase packages to get started. You can also take a look at our sample app.

Dartpad, Flutter’s online editor, now gives you support for Firebase right out of the box

Strengthening app security with App Check

A few months ago, we introduced you to App Check, which provides a powerful layer of security for your backend infrastructure. It does this by attesting that incoming traffic is coming from your app on a legitimate device, and blocking traffic that doesn't have valid credentials. Today, App Check can do even more because we’ve made three major updates.

First, you can now use App Check to protect access to Cloud Firestore (with Firestore Web SDK support coming soon), in addition to Cloud Storage for Firebase, Realtime Database and Cloud Functions for Firebase that we announced previously. Second, we’ve added custom server protections so you can use App Check with any custom backend resources. It even integrates with API Management Platforms like Apigee and CDNs like CloudFlare. Third, we’ve expanded the number of attestation providers App Check supports to now include Apple’s app attestation provider App Attest and reCAPTCHA Enterprise. Register your app with App Check today and start enforcing protections through the Firebase console. To learn more about App Check, check out our documentation.

App Check protects your app and user data

Detailed documentation for upcoming Google Play Safety policies

We’re launching detailed documentation that specifies what data each Firebase product collects and shares to help you comply with Google Play’s upcoming safety policies. Our goal is to build upon Google’s commitment to privacy and transparency, and give you a head start to prepare for Google Play’s new data safety section, which launches to app users next year.

The above image is an example only and subject to change

Gain actionable insights to run your app with confidence

With Firebase, you can monitor your app’s performance and stability, test changes, and get insight on how you can resolve issues to deliver the best experience possible.

New real-time alerts in Performance Monitoring

Firebase Performance Monitoring gathers and presents data about your app’s performance, so you know exactly what’s happening in your app –and when users are experiencing slowness– from their point of view. However, no matter how thoroughly you test your app on your local machine, your app can still run into latency issues because users will access it on different devices, from different countries, and on different network speeds. To keep you informed, we’re releasing a new feature called performance alerts in beta! These new performance alerts will send you an email when your app start time exceeds a given threshold so you can investigate and fix the latency issue as soon as it appears. Performance alerts can be configured from the console and we’ll be adding more alerts for other performance metrics soon.

Performance Monitoring’s new real-time alerts will let you know if your app start time slows down

Crashlytics adds Application Not Responding (ANR) reports and signals

Firebase Crashlytics gives you a complete view into your app’s stability so you can track, prioritize, and resolve bugs before they impact a large number of users. On top of Crashlytics' enhanced support for Apple platforms and game reporting, Crashlytics now reports Application Not Responding (ANRs) errors! According to our research, ANRs account for almost 50% of all unintended application exits on Android, meaning they can be more detrimental to your app’s quality than crashes. To give you a comprehensive view of your app’s stability issues, Crashlytics now reports ANRs and surfaces contextual information about impacted threads so you can pinpoint the cause of the ANR.

Crashlytics now reports Application Not Responding errors, giving you a more comprehensive view of app stability

We’re also unveiling a new concept in Crashlytics called signals. Signals analyze your crashes to uncover interesting commonalities and characteristics that are helpful for troubleshooting. Today, we’re launching with three signals: early crashes, fresh issues, and repetitive issues. Early crashes refer to crashes that users experience near app start. Fresh issues are new issues in the last 7 days, while repetitive issues are issues that users have been encountering over and over again. Signals are available to both Apple and Android app developers. Check them out during your next app release!

Crashlytics signals surface interesting commonalities and characteristics of crashes to improve troubleshooting

Scale with ease by using powerful engagement tools

As your app grows, Firebase offers the control, automation, and flexibility you need to drive the business outcomes you want, such as increasing engagement and revenue.

Unified campaign management for Cloud Messaging and In-App Messaging

Firebase Cloud Messaging makes it easy to send targeted, automated, and customized push notifications across platforms so you can reach users even when they aren’t actively using your app. Firebase In-App Messaging gives you the ability to send contextual messages to users who are actively using your app so you can encourage them to complete key in-app actions. These two products go hand-in-hand in keeping users engaged. That’s why we’re thrilled to reveal a redesigned console experience that brings them together. This unified dashboard gives you a holistic view into all of your messaging campaigns, so you can run sophisticated, multi-touch campaigns for different audiences and see how they perform – from one place. For example, you can send a coupon code to users who are predicted to churn to keep them around because both Cloud Messaging and In-App Messaging work seamlessly with Google Analytics’ new Predictive Audiences. To try the new unified dashboard, visit the console and click the “Preview now” button.

The unified dashboard for Cloud Messaging and In-App Messaging lets you view and manage your campaigns from one place

Remote Config core improvements and beta launch of personalization

Another way to retain and delight users is by personalizing the app experience to suit their needs and preferences. With Firebase Remote Config, you can dynamically control and change the way your app looks and behaves without releasing a new version. Today, we’re excited to launch a new Remote Config feature called personalization into beta! Personalization gives you the ability to automatically optimize individual user experiences to maximize the objectives you care about through the power of machine learning. After a simple setup, personalization will continuously find and apply the right app configuration for each user to produce the best outcome, taking the load off of you.

Halfbrick, the game studio behind titles like Jetpack Joyride, Dan the Man, and the instant-classic Fruit Ninja, has already used personalization to increase revenue by 16% and boost positive app store ratings by 15%! Ahoy Games, another early customer, tried personalization in a number of their games and successfully grew in-app purchases by 12-13% with little to no effort from their team.

Remote Config personalization uses machine learning to help you optimize user experiences to achieve your goals

We’ve also made several core improvements to Remote Config, including updating the parameter edit flow to make it easier to change targeting conditions and default values, and adding data type support to strengthen data validation and reduce the risk of pushing a bad value to your users. Finally, we’ve revamped the change history so you can clearly see when and how parameters were last changed. This will help you understand which app configuration changes correlate to changes in key metrics. Go to the Remote Config console to check out these updates and try personalization today!

Targeting and data validation improvements in Remote Config

Your partner throughout your app’s journey

From building your app to optimizing it, we are your partner throughout the entire journey. We aim to make app development faster, easier, and streamline your path to success.You can rely on us to help you make your app the best it can be for users and your business. To get more insight into the announcements we shared above, be sure to check out the technical sessions, codelabs, and demos from Firebase Summit! If you want a sneak peek at what we’ll be launching in 2022, join our Alpha program!

Getting feedback on your app's releases before they reach the store is critical. App Distribution makes it easy to share pre-release builds of your Android and iOS apps with your testers. You can distribute your apps to testers using the Firebase console, the Firebase CLI, or the App Distribution plugins for Gradle and fastlane.

We've also heard that you'd like to integrate your own tools directly with App Distribution, or implement custom pre-release testing workflows. That's where the Firebase App Distribution REST API comes in. With this API, you can build custom logic into your team's tools and services to add and remove testers, upload new app binaries, distribute your releases, update release notes, deleting releases, and more.

For example, let's say that your company gives all employees early access to the latest builds of your app. You also have a personnel management tool that automates the employee onboarding and offboarding process. Wouldn't it be nice if employee access was automatically granted and revoked as employees join and leave your company? With the REST API, you can build this functionality directly into your company's workflow.

Let's walk through the process to automatically grant and revoke access.

Authenticate with the API

To access the API, enable the Firebase App Distribution API for your project and choose a way to authenticate your integration. In this scenario, download a service account key and use oath2l to get an access token:

oauth2l fetch \
     --credentials /path/to/service-account.json \
     --scope https://www.googleapis.com/auth/cloud-platform

Make HTTP requests to the API

Next, in hooks that are triggered when an employee joins or leaves the company, use the testers.batchAdd and testers.batchRemove endpoints to add or remove the employee as a tester in App Distribution using an HTTP request to the API. For example, here's how you can add a new tester using curl:

SERVICE=https://firebaseappdistribution.googleapis.com

curl --request POST \
  $SERVICE/v1/projects/[PROJECT_NUMBER]/testers:batchAdd \
  --header 'Authorization: Bearer [ACCESS_TOKEN]' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{"emails":["newemployee@company.com"]}'

Let's say you periodically audit access to your pre-release apps to make sure that only authorized internal testers have access. To automate this audit, you can use the testers.list endpoint to get the list of testers in your Firebase project. You can then write your own logic to compare that to your list of employee email addresses, or check the domains:

curl \
  $SERVICE/v1/projects/[PROJECT_NUMBER]/testers \
  --header 'Authorization: Bearer [ACCESS_TOKEN]' \
  --header 'Accept: application/json'

Build your own custom workflow

Tester access and auditing is just one example of custom functionality you can build using the API. Other examples of functionality that you can build include keeping release notes in sync with your bug tracking system, fetching details about your most recent release, adding testers to releases from third-party tools, deleting releases in bulk, or fetching test certificate info for your Android app bundle releases.

App Distribution helps you gain confidence in your releases, and the REST API empowers you to integrate pre-release testing into your existing workflows. So get started with the API today! To learn more, and to try out the API using the embedded API Explorer, see the Firebase App Distribution API documentation.

Try out the API using the API Explorer in the documentation.

If you’ve visited the Firebase console’s Analytics section recently, you might have noticed something new… an updated Analytics dashboard, a new Realtime view and a few other UI enhancements.

These new changes are part of our effort to improve the Google Analytics experience in Firebase, by providing access to some of the newest Google Analytics 4 innovations directly in the Firebase console.

New Google Analytics 4 features available in the console

The Dashboard

Firebase now shows a curated collection of Analytics cards that provide the same information as the previous dashboard, but presented more intuitively to get to key insights faster. This matches the ‘App Developer - Firebase’ collection in Google Analytics 4 - meaning you no longer need to switch to the Google Analytics interface to see this data. The cards are now organized by surfacing overview metrics first, followed by user engagement and retention cards, then monetization and user demographics.

The dashboard now also contains a lot of explorer cards that allow you to more easily drill-down into specifics for data represented by that card for more details - like the new App Versions card which provides a quick view into the number of users you have per app version, and a jumpoff link to see more data like engagement rates, revenue and conversions per app version as well.

The Publisher card is another example of providing a more natural flow to learn more about how different ad units are performing as well as the revenue they are generating.

Before adding this card to the dashboard, accessing this information would require digging into specific event reports, like the ad_impression event report to get out the ad unit performance or revenue data. Well, no need to go digging through various event reports anymore with this updated flow that should make accessing this information more convenient and intuitive.

Check out this Google Analytics help center article for more information about the differences between the new and older dashboard cards in the “Data cards before and after” section.

Comparisons

One feature that’s been around in Google Analytics 4 for a while but only just making an appearance in the Firebase console is the Comparisons tool, which replaces what was previously ‘Filters’. Similar to the Filters tool, with the Comparisons tool you can create comparison groups based on any custom or pre-defined Analytics dimensions or audiences. The advantage of the Comparisons tool is that you can create up to five comparison groups at once, and view and compare the Analytics data for each of these groups across all cards on the Analytics dashboard. For example, if you recently ran a promotional campaign offering 10% off in-app purchases to your top purchasers using Remote Config, you can check to see the impact of that at a glance on metrics like user engagement and app revenue by comparing the top purchasers audience, your most engaged users audience, and all users by applying Comparisons in the dashboard.

Note to compare events or conversions as you would have done using Filters in the past, you can navigate to the Events or Conversions card from the dashboard to reveal a detailed report that you can then apply comparisons on.

Check out this article or this video that covers how to use the Comparison tool in more detail.

The Realtime view

The Realtime dashboard now shows the same views as in Google Analytics 4 and is great for, well, seeing events come in real-time from around the world. This can be really useful after just releasing a new feature, and seeing new events come in for the first time as it rolls out to your users. The updated dashboard contains new cards and new card capabilities, like the User Acquisition card that can be filtered by source, campaign, medium and platform, as well as the Users card that can now be filtered by audience.

One of the biggest benefits of this new change is the ability to use the Comparisons tool in the Realtime dashboard, too, so you can create and compare different groups over real-time app analytics data.

Google Analytics settings page

As part of this change, the Google Analytics settings page now links out to the Google Analytics console where you can modify any Analytics settings as you would previously in the Firebase > Project Settings > Integration > Google Analytics page. The Analytics Linking card however is still available and can be edited from within the Firebase console.

We invite you to take the updated Analytics dashboard in the Firebase console for a spin, and as always, let us know if you have any feedback or questions.

This article is part of the weekly learning pathways we’re releasing leading up to Firebase Summit. See the full pathway and register for the summit here.

When you send a push notification to your users, things can go wrong in many places: the network might be down, the device might have performance issues or the send request might be invalid. And each platform has its own complexity so the challenges can keep adding up. All of this makes it difficult to know whether your notifications actually got delivered to users.

To get a better understanding of whether your notifications were delivered and where things might have gone wrong, you need one central place to collect all information and then run an analysis. This is where BigQuery can help. BigQuery, Google's solution for building data warehouses, gives you the ability to run queries and build custom dashboards that provide deep insights and actionable information.

With the Firebase Cloud Messaging Android SDK, you can log notification delivery data and export it to BigQuery. We recently expanded the same support for iOS and the web. In this article, we will walk you through the process of setting this up so you can better understand your delivery rate and identify ways to troubleshoot or improve it.

Enable BigQuery Export for your Firebase project

First, you need to enable BigQuery for your Firebase project. You can do this by navigating to the Firebase console > Project Settings > Integrations, and then click Link on the BigQuery card. It's worth noting that, by default, this integration uses the BigQuery sandbox. This lets you explore BigQuery capabilities at no cost, so you can evaluate if it fits your use case. After you link your Firebase project to BigQuery, Firebase will export your data to BigQuery. The initial propagation of data might take up to 48 hours to complete.

Once the data is successfully exported, you should be able to see a data table created under your project’s firebase_messaging tab in the BigQuery console.

To collect Notification Delivery data, you need to enable logging on the client side. In the next step, we're going to set up the iOS client and start logging some data to BigQuery.

iOS Delivery Data Logging

With the Firebase Messaging iOS SDK 8.6.0 or higher, you can now enable notification delivery logging in your app that exports to BigQuery by calling a new API we recently added. You will need to log alert and background notifications separately (this is only required for Apple's platforms).

Alert notifications and Notification Service Extension

To log alert notifications delivery, you first need to add a Notification Service Extension to your project in Xcode. The Notification Service Extension lets you customize the content of notifications before they become visible to users. Apple’s developer documentation has more details about how to add a service extension to your project.

After adding the Notification Service Extension to your project, find the NotificationService didReceiveNotificationRequest:withContentHandler: method inside the service extension target. This is where you will add code to enable logging.

In Firebase 8.6.0, We have introduced a new method to the Firebase Messaging API: the delivery data export API FIRMessagingExtensionHelper exportDeliveryMetricsToBigQueryWithMessageInfo:. Logging is disabled by default, so you will need to explicitly enable it by calling this API inside the Notification Service Extension.

 override func didReceive(_ request: UNNotificationRequest,
                           withContentHandler contentHandler: @escaping (UNNotificationContent)
                             -> Void) {
    self.contentHandler = contentHandler
    bestAttemptContent = (request.content.mutableCopy() 
                          as? UNMutableNotificationContent)

    if let bestAttemptContent = bestAttemptContent {
      // Modify the notification content here...
      bestAttemptContent.title = "\(bestAttemptContent.title) 👩🏻‍💻"

      // Log Delivery signals and export to BigQuery.
      Messaging.serviceExtension()
        .exportDeliveryMetricsToBigQuery(withMessageInfo: request.content.userInfo)

      // Add image, call this last to finish with the content handler.
      Messaging.serviceExtension()
        .populateNotificationContent(bestAttemptContent, withContentHandler: contentHandler)
    }
  }

Note that, if you use the Firebase Cloud Messaging SDK to add an image to your notification, you need to make sure to call the deliver data export API before calling Messaging.serviceExtension().populateNotificationContent(_:withContentHandler), as shown in the code snippet above.

The Apple system only passes the notification to the service extension if the notification payload contains the key "mutable-content" :1, so make sure you specify this key if you use the HTTP v1 API. If you use the Firebase console to send notifications, "mutable-content" :1 will be set automatically.

Background notifications

Background notifications are hidden messages that allow your app to wake up and update data in the background. To enable delivery data export for these kinds of notifications, you will need to implement the application:didReceiveRemoteNotification:fetchCompletionHandler: method and call exportDeliveryMetricsToBigQueryWithMessageInfo: method as shown below:

// For background notifications, call the API inside the UIApplicationDelegate method:
  func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any]) {
  Messaging.extensionHelper().exportDeliveryMetricsToBigQuery(withMessageInfo:userInfo)
  }

Make sure to include "content-available":1 to specify it’s a background notification when you use the HTTP v1 API to send the notification.

Web Delivery Data Logging (Alpha)

Notification Delivery Logging is newly available on the web for Firebase JS SDK versions 9.0.0 and newer. To enable delivery data export, all you need to do is to enable the flag on a service worker as shown below. This is handled similarly to Android.

// userConsent holds the decision of the user to give big query export consent.
const userConsent = ...;
const messaging = getMessagingInSw(app);
experimentalSetDeliveryMetricsExportedToBigQueryEnabled(messaging, userConsent)

Android Delivery Data Logging

Notification Delivery Logging has been supported on Android since Firebase SDKs version 20.1.0 or higher. On Android, you can call the delivery data logging API to enable data export for both display and data messages like this:

 FirebaseMessaging.getInstance().setDeliveryMetricsExportToBigQuery(true)

Turning it off again

By default, Notification Delivery Logging is disabled on all three platforms, and will only be activated once you call the API to enable it for the particular platform your app is running on. You can also deactivate the BigQuery export any time by unlinking your project in the Firebase console.

Results on BigQuery

Once you have successfully logged some data you will see this data in the BigQuery console. Keep in mind that the data is regularly pushed from Firebase to BigQuery and the daily propagation might take some time (up to a couple of hours, depending on the amount of data) to complete.

BigQuery data also includes customized analytics labels that help you to create custom queries. Here’s a preview what type of data you can get from the iOS platform:

With the delivery data on BigQuery, you can now run custom queries or build a customized dashboard based on your needs. It provides detailed information about your campaign, including message identifier, message type, SDK platform and timestamp so you can get a lot of useful information helping you identify if the message was sent as expected. You can also segment the data based on your custom analytics labels. And if you are interested in getting additional aggregate information about message delivery on Android, check out this Medium post to find out how to use FCM Aggregation API for advanced data analysis.

Make the most of Firebase

View the full learning pathway on FCM message delivery for additional codelabs, videos and articles. And don’t forget to register for Firebase Summit and join us on November 10th to learn how Firebase can help you accelerate your app development, release with confidence and scale with ease!

This article is part of the weekly learning pathways we’re releasing leading up to Firebase Summit. See the full pathway and register for the summit here.

Apps and games have evolved rapidly in recent years, and user expectations for high performing apps have increased right alongside them. Today’s users don’t just demand speed and performance — they reward it. A 2019 study found that retail sites saw 8% more conversions when they reduced their mobile site load times by one-tenth of a second. And travel sites boosted conversions by just over 10%.

Pinpointing an app’s performance issues can be challenging, especially when the culprit is slow network requests from your dependencies or even your own server.

This is where network analysis from Firebase Performance Monitoring can help. Firebase Performance Monitoring helps you understand your app’s performance from the user’s perspective in near real time. You can analyze the performance of each module of your app by monitoring response times, success rates, and payload sizes of your most critical network requests.

Let’s look at how we were able to spot performance pitfalls in BingoBlast - Firebase's very own demo app.

Automatic aggregation

Out-of-the-box, Firebase Performance Monitoring measures each network request that is sent from your app. To surface the most important trends from the vast number of URLs, Firebase automatically aggregates data for similar network requests to representative URL patterns. Furthermore, this aggregation removes all PII (Personal Identifiable Information) such as home address, username, and password so that developers don't need to worry about leaking user information.

Firebase displays all URL patterns (including custom URL patterns) and their aggregated data in the Network requests subtab of the traces table, which is the lower half of the Performance dashboard.

BingoBlast Auto Aggregate Data.

By just integrating Firebase Performance Monitoring into your app, you can quickly see the slowest network requests your app is making and how that performance has changed over time.

For BingoBlast, our traces table shows that some network requests have substantial slowdowns in their response time over the past several days, signaling that there might already be issues needing our attention.

Although Firebase does a great job at automatically generating URL patterns, at times the specific pattern you're interested in might be hidden under an automated pattern. In those situations, you can create custom URL patterns to monitor specific URL patterns that Firebase isn't capturing with its derived automatic URL pattern matching.

Custom URL patterns

Custom URL patterns let you specify the patterns that will take precedence over the automatic URL patterns. With custom URL patterns, you can:

• Track a more specific pattern that you're interested in which might normally be aggregated within a broader pattern.
• Aggregate a group of related URL patterns that might not have been aggregated automatically.

A custom URL pattern consists of the hostname followed by path segments. Subdomains and path segments can be replaced with a * to represent matching with any string.

If a request's URL matches more than one custom URL pattern, Firebase Performance Monitoring maps the request to the most specific custom URL pattern based on left-to-right specificity. See the documentation for the full details and syntax available.

For example, suppose you configure two custom URL patterns:

example.com/books/*
example.com/*/dog

A request to example.com/books/dog will match against example.com/books/* because book is more specific than *.

Tracking a more specific pattern

To show how custom URL patterns can be helpful, let's look closer at the data from BingoBlast. Let's say that we're worried that an important configuration API request (api.redhotlabs.com/1.2/config.get) might be causing issues in BingoBlast. But, we're unable to find it in our list of automatic network URL patterns. In this case, Firebase Performance Monitoring has aggregated the configuration API request along with a few other API requests into the api.redhotlabs.com/1.2/* URL pattern.

To get better insight into any performance issues this API call might be causing, let's use a custom URL pattern for this specific request.

To do this, we just click the Create custom URL pattern button in the traces table, then enter api.redhotlabs.com/1.2/config.get into the dialog. After the new pattern is created, the traces table will start displaying the new custom URL pattern based on new data.

Creating a new custom URL pattern.

Since this is an important API request and we want to track our improvements to it over time, we can add metrics (like response time) for this new custom URL pattern to our metrics board at the top of the Performance dashboard page. These metrics cards are a great way to provide a quick overview of your most important metrics.

Pin your most important metrics to the top of your dashboard.

With api.redhotlabs.com/1.2/config.get extracted as its own URL pattern, it's easier to monitor for any unwanted changes in the performance of these requests. We can then take action, like removing the request from the app's critical path or recommending improvements for the backend implementation.

Newly added api.redhotlabs.com/1.2/config.get custom URL pattern.

Grouping related URL patterns

On the other hand, we sometimes want to group related URLs into a single URL pattern. In BingoBlast, we have included a library that plays a short video. However, we noticed that our traces table is showing many separate URL patterns to different googlevideo.com subdomains.

Overly precise automated URL patterns for googlevideo.com subdomains.

Since we're more concerned about the overall performance of the video requests, as opposed to which specific subdomain they're from, we can create a custom URL pattern *.googlevideo.com/** to aggregate all these URLs into one pattern. This makes it easy to understand the performance for the video and, as a bonus, makes our traces table more tidy!

Newly aggregated data for the custom URL pattern for googlevideo.com subdomains.

Firebase Performance Monitoring provides a wealth of data on how your users experience your app. By leveraging Firebase’s out-of-the-box automatic URL patterns and tailoring your dashboard with custom URL patterns you’re most interested in, you can easily pinpoint slow performance areas in your apps and quickly boost your app’s responsiveness.

Make the most of Firebase

View the full learning pathway for additional codelabs, videos and articles on creating fast and stable apps. And don’t forget to register for Firebase Summit, happening November 10th to learn how Firebase can help you accelerate your app development, release with confidence, and scale with ease!

This article is part of the weekly learning pathways we’re releasing leading up to Firebase Summit. See the full pathway and register for the summit here.

Earlier this year at Google I/O, we announced Firebase App Check, Firebase's new platform for protecting your Firebase APIs from abuse. Not only can App Check protect hosted APIs (such as Cloud Storage for Firebase, Firebase Realtime Database, and others), it can also be used to protect your own backend resources, whether they are run in a managed environment such as Cloud Run or hosted on your own infrastructure.

To prevent abuse, your public APIs should verify that the calling application is authorized to make requests, regardless of whether a user credential is present or not. Imagine you run a backend which provides the API for a free mobile app; your app might be funded with ads, so you should ensure that all requests originate from your app—and not someone else's app!

To protect your backend with App Check, your apps should send an App Check token with every request. Apps built with Firebase SDKs and with App Check functionalities properly configured will automatically obtain and refresh App Check tokens for you. They will also automatically send those tokens along with every request to supported Firebase services such as Cloud Storage for Firebase, Cloud Functions for Firebase, and Firebase Realtime Database. These services will also automatically verify those tokens for you.

On the other hand, if you run your services on your own infrastructure, you are responsible for making sure that:

• Your apps send an App Check token with every request to your services. Learn how to do this for your Android, iOS, and web apps.
• Your services validate App Check tokens in your backend code. In this blog post, we're going to show you how to do this in several different contexts.

Verifying App Check tokens in a Node.js backend

In Node.js backends running in trusted environments, such as Cloud Run, Cloud Functions, or your own server, it is common practice to use middleware modules to integrate cross-cutting concerns like this. Here's a code snippet that defines an Express.js middleware layer that verifies the App Check token using the Firebase Admin SDK:

const express = require('express');
const firebaseAdmin = require('firebase-admin');

const app = express();
firebaseAdmin.initializeApp();

const appCheckVerification = async (req, res, next) => {
  const appCheckClaims =
    await verifyAppCheckToken(req.header('X-Firebase-AppCheck'));
  if (!appCheckClaims) {
    res.status(401);
    return next('Unauthorized');
  }
  next();
};

const verifyAppCheckToken = async (appCheckToken) => {
  if (!appCheckToken) {
    return null;
  }
  try {
    return firebaseAdmin.appCheck().verifyToken(appCheckToken);
  } catch (err) {
    return null;
  }
};

app.get('/yourApiEndpoint', [appCheckVerification], (req, res) => {
  // Handle request.
});

For more details, check out our documentation.

Verifying App Check tokens in other backend resources

App Check tokens are implemented as JSON Web Tokens (JWT) as specified by RFC 7519. This means they are signed JSON objects. To assert that an App Check token is legitimate, you must perform the following steps:

1. Obtain the Firebase App Check public JSON Web Key (JWK) Set (as specified by RFC 7517) from our JWKS endpoint (https://firebaseappcheck.googleapis.com/v1beta/jwks).
2. Verify the App Check token's signature to ensure it is legitimate.
3. Ensure that the token's header uses the algorithm RS256.
4. Ensure that the token's header has type JWT.
5. Ensure that the token is issued by Firebase App Check under your project.
6. Ensure that the token has not expired.
7. Ensure that the token's audience matches your project.
8. If desired, you can also check that the token's subject matches your app's App ID.

The following example performs the necessary steps in Ruby using the jwt gem as a Rack middleware layer. Many languages have similar JSON Object Signing and Encryption (JOSE) libraries that you can use for this purpose.

require 'json'
require 'jwt'
require 'net/http'
require 'uri'

class AppCheckVerification
  def initialize(app, options = {})
    @app = app
    @project_number = options[:project_number]
  end

  def call(env)
    app_id = verify(env['HTTP_X_FIREBASE_APPCHECK'])
    return [401, { 'Content-Type' => 'text/plain' }, ['Unauthenticated']] unless app_id
    env['firebase.app'] = app_id
    @app.call(env)
  end

  def verify(token) 
    return unless token

    # 1. Obtain the Firebase App Check Public Keys
    # Note: It is not recommended to hard code these keys as they rotate, 
    # but you should cache them for up to 6 hours.
    uri = URI('https://firebaseappcheck.googleapis.com/v1beta/jwks')
    jwks = JSON(Net::HTTP.get(uri))

    # 2. Verify the signature on the App Check token
    payload, header = JWT.decode(token, nil, true, jwks: jwks, algorithms: 'RS256')

    # 3. Ensure the token's header uses the algorithm RS256
    return unless header['alg'] == 'RS256'

    # 4. Ensure the token's header has type JWT
    return unless header['typ'] == 'JWT'

    # 5. Ensure the token is issued by App Check
    return unless payload['iss'] == "https://firebaseappcheck.googleapis.com/#{@project_number}"

    # 6. Ensure the token is not expired
    return unless payload['exp'] > Time.new.to_i

    # 7. Ensure the token's audience matches your project
    return unless payload['aud'].include? "projects/#{@project_number}"

    # 8. The token's subject will be the app ID, you may optionally filter against 
    # an allow list
    payload['sub']
  rescue
  end
end

class Application
 def call(env)
    [200, { 'Content-Type' => 'text/plain' }, ["Hello app #{env['firebase.app']}"]]
  end
end

use AppCheckVerification, project_number: 1234567890
run Application.new

Verifying App Check tokens at the edge

If your application uses content delivery networks (CDNs) to cache content closer to your users, you can use App Check to filter out abusive traffic at the edge. Since the Firebase Admin SDK's App Check functionalities are currently only available in Node.js and not all CDN providers support the Node.js runtime, you may need to verify App Check tokens in another runtime supported by the CDN. For this use case, you can adapt the following example for CloudFlare workers:

import { JWK, JWS } from "node-jose";

// Specify your project number to ensure only your apps make requests to your CDN
const PROJECT_NUMBER = 1234567890;

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request))
});

async function handleRequest(request) {
  const appCheckToken = request.headers.get('X-Firebase-AppCheck');
  const appId = await verifyAppCheckToken(appCheckToken);
  if (!appId) {
    return new Response("Unauthorized", { status: 401 });
  }


  return new Response(`Hello app ${appId}`, {
    headers: { "content-type": "text/plain" }
  });
}

async function verifyAppCheckToken(encodedToken) {
  if (!encodedToken) {
    return null;
  }

  // 1. Obtain the Firebase App Check Public Keys
  // Note: It is not recommended to hard code these keys as they rotate, 
  // but you should cache them for up to 6 hours. 
  const jwks = await fetch("https://firebaseappcheck.googleapis.com/v1beta/jwks", {
    headers: {
      "content-type": "application/json;charset=UTF-8",
    }
  });

  // 2. Verify the signature on the App Check token
  const keystore = await JWK.asKeyStore(await jwks.json());
  const token = await JWS.createVerify(keystore).verify(encodedToken);

  // 3. Ensure the token's header uses the algorithm RS256
  if (token.header["alg"] !== "RS256") {
    return null;
  }

  // 4. Ensure the token's header has type JWT
  if (token.header["typ"] !== "JWT") {
    return null;
  }

  const payload = JSON.parse(token.payload.toString());

  // 5. Ensure the token is issued by App Check
  if (payload["iss"] !== `https://firebaseappcheck.googleapis.com/${PROJECT_NUMBER}`) {
    return null;
  }

  // 6. Ensure the token is not expired
  if (Date.now() > payload["exp"] * 1000) {
    return null;
  }

  // 7. Ensure the token's audience matches your project
  if (!payload["aud"].includes(`projects/${PROJECT_NUMBER}`)) {
    return null;
  }

  // 8. The token's subject will be the app ID, you may optionally filter against 
  // an allow list
  return payload["sub"];
}

Verifying App Check tokens in Apigee

Apigee is Google Cloud's comprehensive API management platform for your APIs. In Apigee, you can easily implement a policy for your API Proxy that checks for the presence and validity of Firebase App Check tokens for all your incoming requests.

In the following example, we will check for the presence of the Firebase App Check token in the request header X-Firebase-AppCheck, ensure that it is valid, and verify that it was issued by the correct project.

First, in your API Proxy, add a Verify JWT policy; you can enter any Display Name.

Similar to the examples we have seen so far, you will need to perform all of the following steps in this policy:

• Extract the Firebase App Check token from the client request; we highly recommend passing it as a header, such as X-Firebase-AppCheck, and use request.headers.X-Firebase-AppCheck as the <Source>.
• Provide our Public JWKS (as specified by RFC 7517) endpoint: https://firebaseappcheck.googleapis.com/v1beta/jwks.
• Ensure that the <Algorithm> is set to RS256.
• Ensure that the <Audience> contains projects/{project_number}. Here, the {project_number} is the project number of your Firebase project that issued the Firebase App Check token (without the braces).
• Ensure that the <Issuer> is equal to https://firebaseappcheck.googleapis.com/{project_number}; again, ensure that the {project_number} is the Firebase project that issued the Firebase App Check token (without the braces).
• If desired, you can also check that the <Subject> matches your app's App ID.

Following these steps, your configuration should look like the following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyJWT continueOnError="false" enabled="true"
        name="Firebase-App-Check-Token-Verification">
    <DisplayName>Firebase App Check Token Verification</DisplayName>
    <Algorithm>RS256</Algorithm>
    <Source>request.headers.X-Firebase-AppCheck</Source>
    <PublicKey>
       <JWKS uri="https://firebaseappcheck.googleapis.com/v1beta/jwks"/>
    </PublicKey>
    <!-- Be sure to use your real project number in <Issuer> and <Audience>. -->
    <Issuer>https://firebaseappcheck.googleapis.com/123456789</Issuer>
    <Audience>projects/123456789</Audience>
    <!-- You can also optionally check that the Subject matches your app's App Id. -->
    <Subject><!-- Insert your app's App ID here. --></Subject>
</VerifyJWT>

Finally, add this policy to your Proxy Endpoint's pre-flow, and save this configuration as a new revision. Once you re-deploy the proxy at this revision, any request that arrives at the proxy must have a valid Firebase App Check token in the X-Firebase-AppCheck header, or the request will be rejected.

Conclusion

Securing your app and your resources is critical. Using Firebase Authentication and Firebase Security Rules helps protect access to user data, and using Firebase App Check helps mitigate fraud and secure access to your backend resources—whether those are Firebase resources or your own. View the full learning pathway on protecting your app from abuse for additional resources.

And don’t forget to register for Firebase Summit and join us on November 10th to learn how Firebase can help you accelerate your app development, release with confidence and scale with ease!