It's amazing to see you using Crashlytics on so many different Apple products – and even wanting to expand that usage! We have always focused on making Crashlytics the best crash reporter on iOS, from our user-friendly onboarding process, to our lightweight SDK. So we’ve made some updates to ensure you can run the Crashlytics SDK seamlessly on all Apple consumer hardware.
In December 2020, we released full support for Apple Silicon Macs running iOS or macOS apps. This means any of the following configurations running on Apple Silicon will work with Crashlytics:
To make it easier to see crashes on these platforms, we added support for filtering in the Firebase console, using the Device filter. We're already working on improving this experience, so stay tuned!
With the introduction of iOS 14, the number of system libraries and libraries used by apps has increased. These libraries can increase startup time as Crashlytics lists the libraries loaded into the app for symbolicating crash reports. In version 7.5.0 of the Crashlytics SDK, we shipped a change to remove this bottleneck, significantly improving the customer experience. For apps with this version of the SDK, we’ve observed a median startup time of about 14 milliseconds, a 75% reduction!
In addition, we’ve improved the speed of our client-side build tools, especially for apps with large binary and dSYM files. This tool processes dSYMs on your build machine before upload to ensure it matches your build environment and Xcode version as closely as possible. We observed the symbol conversion time for a 600 MB dSYM improved from about 12 minutes to 45 seconds. This will help speed up CI builds for your apps and make it possible to rapidly test crashes locally.
We’ve also invested in making sure we fully support App Clips. Crashlytics continues to be a lightweight crash reporter in terms of binary size, so you shouldn’t have to commit much of your App Clip’s 10 MB limit to the Crashlytics installation.
Recently, the community pitched in to get the Crashlytics SDK running on watchOS, adding support for common crashes and non-fatals. Since watchOS is continuing to build out better support for responding to crashes, we’re always happy to accept contributions to improve this!
Open sourcing the Crashlytics SDK as part of the move to Firebase has brought huge benefits. The community has been integral in determining the popularity of various features, and we want to thank folks who have reached out on GitHub, Firebase Support, and other channels to outline their use cases for Crashlytics. We want to especially thank members of the community who have made code changes to improve the SDK directly.
We are continually investing in support for Apple apps, and there’s more coming to help developers diagnose stability issues with their apps. We’re proud of the investments we’ve made here and are excited to continue supporting the Apple app ecosystem.
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.
One of the biggest challenges game developers face is figuring out how to improve monetization without compromising their game experience. Many game developers embed ads into their titles, which enables them to offer their games for free and remove the cost barrier of adoption for players - while still generating revenue. In-app advertising can be lucrative, when done effectively and in moderation.
But how do you know what types of ads are best-suited for your game? How do you ensure ads won’t drive away players? These are the exact questions Pomelo Games had. For answers, they turned to Firebase.
Pomelo Games is one of the top game studios in Uruguay. They pride themselves on developing unique and polished games that capture players’ imaginations. Their recent release, Once Upon a Tower, “is an easy-to-pick-up, hard-to-put-down, free-to-play game,” says co-founder Jonás Mora. A Play Store Editors’ Choice, the game is beloved for its high-fidelity graphics, as well as the “fairness of its free-to-play mechanics,” says Jonás.
So when the team needed to improve the game’s monetization, they were unsure how to proceed. They were looking for a way to increase revenue without sacrificing the affordability and game quality their players loved.
Pomelo Games used Firebase Remote Config and Firebase A/B Testing to test a new ad format: interstitials. They also used Google Analytics to monitor revenue and Firebase Crashlytics to keep an eye on stability.
Although initially opposed to the idea, Jonás and his team discovered that showing interstitial ads to their entire player base led to an average 25% increase in AdMob revenue, and surprisingly, a 35% increase in in-app purchases as well. In both cases, there was almost no negative impact on retention or game stability. Firebase gave Pomelo Games the confidence to try new approaches to grow revenue without driving players away. Read Pomelo Games’ full story and get details on their success with Firebase in our new case study. And learn more about how Firebase can help you build and grow your game, and see what other game studios are using Firebase.
Over the last decade, mobile gaming has evolved from stacking colored blocks on a phone to encompass multidimensional and multiplayer experiences that engulf people in imaginative, high-fidelity worlds. As games have gotten more engaging, they’ve also become more complex to develop and maintain. Here at Firebase, we’re committed to providing game developers with the tools and resources you need to build, release and operate successful games that delight players.
We participated in the Google for Games Developer Summit in March, launched Unity and C++ SDKs for Cloud Firestore into open alpha, shipped improved workflows for Unity developers, debuted some new video tutorials, and wrote some new blogs too - so you can easily add Firebase to your game and get the most out of our platform.
We have more exciting updates to come, driven by your feedback and stories. Recently, we spoke to Gameloft to understand how they’ve been using Firebase.
Gameloft is one of the world’s largest gaming studios, employing 4,600 people across 19 global offices. Their vast portfolio consists of over 190 critically-acclaimed, award-winning games that are played by 80 million people each month. Gameloft develops original franchises, like Dungeon Hunter, and also partners with major entertainment studios like Disney.
With such a broad portfolio and audience, having the ability to monitor the stability of their games in a holistic way, and the agility to respond to issues quickly, is key to their success. However, they were lacking proper information about crashes, having a hard time reproducing crashes, and unforeseen technical issues were taking too long to track and fix, upsetting both their team and their players.
Gameloft realized they needed a robust crash reporting tool that could help them improve game quality in a more streamlined and efficient way, so they turned to Firebase Crashlytics.
Crashlytics aggregates crashes by root cause, highlights the impact on players, and provides contextual information on each issue, which helps Gameloft prioritize the crashes to fix first and speeds up their troubleshooting process. By using Crashlytics, Gameloft achieved a 10% reduction in users experiencing crashes overnight for one of their games (Overdrive City). According to Gameloft, this also led to a bump in the game’s Play Store rating and increased session duration by 16%! Find out what Gameloft did to drive these results with Crashlytics by reading the full case study. And learn more about how Firebase can help you build and grow your game, and see what other game studios are using Firebase.
With our announcement of the Firebase Crashlytics SDK Beta in February, we provided a path to help you remove all Fabric dependencies in your code, and complete your migration to Firebase. Since then, tens of thousands of apps have adopted the Beta SDK, and several hundreds of millions of end-users are using apps that include the SDK. Thank you to the adopters of our Beta SDKs; with your help, we have been able to polish and debug our SDK so we could ship it in its best possible launch state.
We are excited to announce that the Firebase Crashlytics SDK is now publicly available! Whether your app was migrated from Fabric or created in Firebase, we encourage you to upgrade to the official version of the Firebase Crashlytics SDK.
Now that the Firebase Crashlytics SDK is publicly available, we are deprecating the legacy Fabric SDK. The Fabric SDK will continue reporting your app's crashes until November 15, 2020. On this date, the Fabric SDK, and beta versions of the Firebase Crashlytics SDK, will no longer send crashes to your Firebase dashboard. To continue getting crash reports in the Firebase console, make sure your app has the following versions of the Firebase Crashlytics SDK, or newer: 17.0.0+ for Android, 4.0.0+ for iOS, and 6.15.0+ for Unity. Developers new to Crashlytics should begin with our getting started docs.
As always, we’d love to hear your feedback! Let us know what you think through our official support page!
Happy coding!
Stability is critical to your app’s success, so we’ve continued to enhance Firebase with tools to help you maintain high quality apps. This includes bringing the best of Fabric’s crash reporting tools to Firebase. Many of you have made the move from Fabric to Firebase yet still have questions like “Why do I still have ‘Fabric’ everywhere in my code?” or “Why does it feel like I am in Firebase, yet still in Fabric?”
We can now lay your questions to rest. We're excited to announce Firebase Crashlytics SDK is in Beta!
With the Firebase Crashlytics SDK, you can remove all Fabric dependencies, such as references to Fabric’s APIs in your code, giving you a much cleaner codebase.
The Firebase Crashlytics SDK is also designed to be intuitive and consistent with all other Firebase SDKs. For example, the Crashlytics SDK has consistent package names, API design, and initialization as other Firebase SDKs.
The Crashlytics SDK also supports Mac Catalyst apps, in addition to iOS, macOS, and tvOS apps. This new feature makes it easier for you to continue building apps for Apple devices.
We’ve also open-sourced the Crashlytics SDK to further increase the extensibility and transparency of our platform.
Combining analytics data and crashes helps you unlock additional insights into your app’s stability. The Firebase Crashlytics SDK works seamlessly with the Google Analytics SDK to provide features such as crash-free statistics, the Latest Release report, and Breadcrumbs. With Breadcrumbs you can see the steps a user took that led to a crash. This insight helps you reproduce and fix issues quickly. Google Analytics replaces Fabric's legacy analytics engine, Answers, so we encourage you to add Google Analytics to your apps.
Try it out!
Ready to begin developing with Firebase Crashlytics SDK? If you are upgrading from the legacy Fabric Crashlytics SDK, read our upgrade guide. Developers new to Crashlytics should begin with our getting started docs. Interested in the Crashlytics source code? View our Android and iOS repositories on GitHub.
We'd love to hear your feedback. As always, you can reach out to us through our official support page. Happy developing!
Keeping an eye out for issues that affect your app’s stability is crucial, but we also know that you can’t spend your entire day staring at the Firebase Crashlytics console.
From the beginning, Crashlytics has given developers the ability to turn on stability alerts so they can be notified when issues increase in impact and severity. Developers have the power to customize these notifications so they're delivered at the right time and channel for maximum visibility - channels where developers already spend their time.
In this blog post, we'll review the types of alerts Crashlytics provides and our recommendations on how to configure them based on observations from customers.
Let’s start by reviewing the different types of alerts Crashlytics sends. Currently, Crashlytics sends five alerts: new fatal issue, new non-fatal issue, trending issues, regression, and velocity alerts.
New issue alerts let you know the first time a new crash has occurred. We filter out the noise of repeated crashes, but give you the full stream of unique crashes by stack trace grouping. These alerts are turned off by default to avoid over inundating you, because as your app grows, you could get tons of alerts for every new version. We recommend turning these on for teams interested in knowing about every new type of crash, and for QA teams chasing down crashes found in testing versions of their apps.
Regression detection alerts you when a previously closed issue re-occurs in a new app version, which is a signal that something else may be awry and you should pay close attention to it.
Trending issues digest is sent out to developers in two instances 1) When Crashlytics detects a new crash is beginning to gain momentum (called emerging issues) 2) When Crashlytics detects new top crashes that have climbed to close to the top of your issue list recently (called trending issues). This daily email is on by default, and is a great way to keep track of emerging issues in your app.
One of the most important alerts within Crashlytics is the velocity alert, which notifies you when an issue suddenly increases in severity and impacts a significant percentage of your users. However, we recognize that every app is unique and the one-size-fits-all alerting threshold might not be what’s best for you and your business. That’s why you can now customize velocity alerts and determine how often and when you want to be alerted about changes to your app’s stability.
You can learn more about customizing velocity alerts here.
Now that you know the different notification types in Crashlytics, you can begin to build your alerting plan.
Firebase Crashlytics offers several channels to receive the above alerts. The first two channels are email and in-console alerts.
To setup these alerts:
Next, you can set up notifications through Slack, Jira or PagerDuty. To set up these alerts, you need to do two things: integrate Slack / Jira / PagerDuty with your Firebase project, and then choose your triggers.
For Slack:
There are two ways to create Jira issues from Crashlytics issues:
Here’s how you enable the Jira integration:
Our PagerDuty integration is setup similarly.
We find that a lot of our users get different utility out of each channel. In Slack, teams frequently set up a channel to show a real-time feed of all new issues, as a way to loosely monitor new issues coming up. Developers with an interest in specific pieces of code can then click through to get more detail on the issues they’re interested in. This is a pattern that seems to work well for most teams.
In Jira, we see developers using the manual integration option to create issues when they know their team is ready to take on that work. In addition, teams also setup automatic triggers for velocity alerts and regressions as those are known higher priority issues to look into.
And for PagerDuty, most teams focus on velocity alerts, which provide insight into the most critical situations your users are experiencing. For teams with even more custom use cases, we recommend developers integrate Crashlytics with Cloud Functions.
By setting up alerting in Crashlytics, you can rest assured that you’ll be alerted when critical issues occur in your app and be ready to take action when needed. For more about Crashlytics check out our docs here.
In Firebase Crashlytics, you can view crashes and non-fatals by versions. Several of our customers take advantage of this filtering, especially to focus on their latest releases.
But sometimes too many versions can be a bad thing. Firebase Crashlytics - by default - shows you the last 100 versions we have seen. If you have a lot of debug versions created by developers, and by continuous Integration and deployment pipeline, you might soon start to not see the versions that really matter e.g., production builds.
So how do you make sure that this does not happen? Disabling Crash reporting initialization for debug builds is the simplest way of achieving this. Let's explore how to do this on iOS and Android.
For iOS apps, first check if you are manually initializing Crashlytics (this happens for Fabric apps that were linked to a Firebase app).
If you use Swift, search for the line Fabric.with([Crashlytics.self]) in AppDelegate.swift. If this line is present, then you are manually initializing Crashlytics, otherwise you are using automatic initialization.
Fabric.with([Crashlytics.self])
If you use ObjectiveC, search for the line [Fabric with:@[[Crashlytics class]]]; in AppDelegate.m. If this line is present, then you are manually initializing Crashlytics, otherwise you are using automatic initialization.
[Fabric with:@[[Crashlytics class]]];
For apps that are using manual initialization, you can just not initialize Crashlytics for DEBUG versions.
For Swift
#if !DEBUG Fabric.with([Crashlytics.self]) #endif
For ObjectiveC
#if !DEBUG [Fabric with:@[[Crashlytics class]]]; #endif
Firebase Crashlytics apps are automatically initialized by Firebase. You can turn off automatic collection with a new key to your Info.plist file:
Info.plist
firebase_crashlytics_collection_enabled
no
Then you can initialize it as shown in the examples above for Swift and ObjectiveC
For Android apps, first check if you are manually initializing Crashlytics (this happens for Fabric apps that were linked to a Firebase app). Search for Fabric.with in your project. If this line is present, then you are manually initializing Crashlytics. Otherwise, Crashlytics is being automatically initialized through Firebase.
Fabric.with
To disable Crashlytics in debug builds, you can make use of the BuildConfig.DEBUG flag. Edit the Fabric.with statement you found previously, adding a check for the DEBUG flag:.
BuildConfig.DEBUG
if (!BuildConfig.DEBUG) { Fabric.with(this, new Crashlytics()); }
Turn off Crashlytics initialization in your debug builds by creating a debug folder in your src directory and creating an AndroidManifest.xml with this snippet:
debug
src
<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <application> <meta-data android:name="firebase_crashlytics_collection_enabled" android:value="no" /> </application> </manifest>
This snippet will be merged into the manifest of all of your debug variants, and will disable Crashlytics in those builds. If you'd prefer finer-grained control, you can use this approach for any variants you'd like to exclude.
As we build Crashlytics and talk to our developers, we've found that the way they use our dashboards is often nuanced and specific to their team. We've done our best to incorporate the themes we hear most often into the dashboard you see in the Firebase console, but one dashboard solution simply isn't enough.
That's why we launched the Crashlytics integration with BigQuery, giving you the freedom to deeply explore your data. And, using Data Studio (a free tool that sits on top of BigQuery), you can make custom dashboards from your Crashlytics data that fit the unique way your team works. Data Studio allows your team members who aren't comfortable with SQL to easily work with the BigQuery data set. Data Studio dashboards are also easy to collaborate on and share, so your team can work more efficiently.
Today, we're launching a Data Studio template that gives you a preview of what's possible with Crashlytics and BigQuery. Let's take a closer look at the template.
The overview section of our template provides an overview of which OS versions crash the most, which devices crash the most, and how it's trending over time. You can customize each section to display the results of the exact queries you want and display how you need based on your business logic. If you want to keep an eye on the deprecation of an old operating system you can change or filter directly in the queries that back the dashboard.
Up until now, exploring your crash reports by custom metadata like Experiment ID or an Analytics breadcrumb has been limited, making it tough to identify which variant in an experiment is least stable or which level in a game has the most crashes. Now, when you export your data to BigQuery, it's easy to run any deep analysis you want, and then visualize your report with Data Studio or any other business system you use.
As an example, say that you set up your Android game so that you log what level a crash occurs with:
Crashlytics.setInt("current_level", 3);
Now you can filter by the presence of a key and its values. We've created a sample dashboard for filtering these in our Data Studio template.
We know our largest apps have different teams that specialize in specific areas of the code. For that, we've made it easy to filter by specific files in our Data Studio template.
Our data studio template is totally customizable, meaning if you'd rather filter on a different part of our scheme or make more advanced tools, you can easily adapt based on your needs. You can adjust the template using the Data Studio UI or you can edit the backing BigQuery queries.
Your team can all work together by sharing the dashboard in DataStudio. This means team members don't need to learn SQL to get the benefits of the Crashlytics integration with BigQuery.
You'll also be able to select date ranges longer than 90 days, if you set up retention in BigQuery. The Crashlytics dashboard currently retains data for 90 days. With BigQuery you own the retention and deletion policies, making it much simpler for your team to track year-over-year trends in stability data. This means you'll be able to customize your dashboard to display data over the exact period you are interested in.
With just a few clicks from the Firebase Crashlytics dashboard you can enable daily exports of all raw crash data on a per-app or per-project basis. This includes your stack traces, logs, keys and any other crash data. You can also use the new BigQuery sandbox to get started for free.
Once you link to Crashlytics to BigQuery, follow these instructions to connect this template with your Crashlytics dataset.
If you are a current Fabric user, you can gain access to BigQuery export and all the other features of Firebase by linking your app in the Fabric dashboard. Check out this link for details and documentation.
We hope this improvement makes it even easier for you to dig into your crash reporting data and efficiently debug your app! As always, if you have any questions, you can find us on Twitter (@firebase) and on Stack Overflow. Happy debugging!
Crashlytics currently processes more than 3 billion events per day for our developers and distills them into an opinionated and actionable set of issues in our dashboard. We've heard thousands of requests over the years to let you explore further into your crash data, and that's why today we're extremely excited to offer the ability to export your Firebase Crashlytics data into BigQuery for deeper analysis!
With just a few clicks from the Firebase Crashlytics dashboard you can enable daily exports of all raw crash data on a per-app or per-project basis. This includes your stack traces, logs, keys and any other crash data.
The Crashlytics dashboard currently retains data for 90 days. With BigQuery you own the retention and deletion policies, making it much simpler for your team to track year-over-year trends in stability data.
BigQuery also offers the ability to export your data in CSV, JSON, or Avro format. This should help to streamline any GDPR data takeout requests you may receive.
When you export your Crashlytics data to BigQuery, you can then see the distribution of crashes by level with this query:
#standardSQL SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.crashlytics.package_name_ANDROID`, UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
We hope this improvement makes it even easier for you to dig into your crash reporting data and efficiently debug your app! As always, if you have any questions, you can find us on Twitter and on Stack Overflow. Happy debugging!
MightySignal, a mobile intelligence startup based out of San Francisco, just published a new report examining the fastest growing Android SDKs of 2017. This fascinating report sheds light on which app development tools are taking off and what trends they signal for the year ahead. We're humbled and excited to see that 8 out of the top 20 fastest growing SDKs are part of Firebase!
This positive reception from the community validates and fuels our commitment to helping developers succeed. It also motivates us to continue making Firebase even better. Over the past year, we've made numerous improvements to our SDKs, including the ones highlighted in MightySignal's report.
Source: MightySignal's 2017 report on the fastest growing SDKs
For example, Firebase Realtime Database is number three on MightySignal's list, and it continues to be one of our most used and trusted products. We understand how important storing and syncing data is for your mobile business, and to further help you with this, we introduced another database product this year. If you're a Realtime Database customer, we think you'll love Cloud Firestore, our latest realtime, scalable NoSQL database that we built in collaboration with the Google Cloud Platform team. It allows you to sync and store data like Realtime Database, while also addressing its key limitations like data structuring, querying, and scaling. Cloud Firestore is available in beta today!
Another notable mention is Firebase Remote Config. Remote Config gives you the power to customize your app's interface and behavior for different audiences so you can deliver personalized app experiences without requiring users to update their apps. Now, Remote Config can be used with Firebase Predictions' dynamic user groups. This means you can change the look and feel of your app for users based on their predicted behavior (such as churn or in-app purchase). Wondering how this works? Learn how Halfbrick Studios grew their 7-day retention rate from 25% to 30% by combining Predictions with Remote Config.
And that's not all that's new with Remote Config! In the past, Remote Config allowed you to perform simple A/B testing, but now, we've gone ahead and added an entirely new experiment layer in Firebase that works wonderfully with Remote Config so you can set up, run, and measure sophisticated A/B tests.
We were also delighted to see that Firebase Auth and Firebase Crash Reporting are experiencing high growth as well, according to MightySignal's findings. After welcoming the Fabric team to Firebase, we worked together to add new features to Auth (such as phone number authentication), which we unveiled in June. More recently, we launched a beta version of Firebase Crashlytics, a powerful realtime crash reporting tool that will help you track, prioritize, and fix issues that erode app stability. Firebase Crashlytics is now our primary crash reporter. If you want to learn more about how app stability can lead to growth in user engagement and retention, check out how Doodle used Crashlytics to grow user engagement by 42%.
MightySignal's data on the fastest growing SDKs is available here. We're very thankful to be part of the developer community and committed to helping you build better apps and grow your business. Stay tuned for more product updates next year and, in the meantime, happy building!
Since Fabric joined forces with the Firebase team, our collective mission has been to bring the best of our amazing platforms together. Today, we are pleased to announce a major milestone in that mission with the beta launch of Firebase Crashlytics.
Firebase Crashlytics is a powerful, realtime crash reporting tool that will help you track, prioritize, and fix stability issues that erode your app quality. With this launch, Firebase developers can now access the best-in-class crash reporting solution right alongside all the other Firebase products you know and love in one unified console. From this point onwards, Crashlytics will be the primary crash reporter for Firebase, so if you're already using Firebase Crash Reporting, we recommend you upgrade now by clicking on the banner in your Crash Reporting dashboard. New Firebase developers can also start using Crashlytics by first installing Firebase and then clicking on Crashlytics in the left-hand navigation bar.
Here's what you'll get when you upgrade. These benefits and features make Crashlytics a must-have tool for all mobile app developers.
Faster troubleshooting
Crashlytics brings the most critical information regarding your stability to the forefront by grouping crashes based on similarity of stack trace and highlighting their impact. You can easily spot trends with the realtime crash data or, use version filtering to focus in on the specific releases you care about most. We designed the issue overview and the issue detail pages with the end-goal of reducing the time it takes to resolve issues.
On the overview page, your crash-free user rate is prominently displayed so you can gauge which builds are improving in stability.
You'll also notice significance badges. When highlighted, these badges indicate that important information is available for that issue that makes it unusual or stand out from the rest. For example, significance badges will tell you if certain issues only occur on a specific device, OS, or only on jailbroken phones.
Armed with this insight, you can effectively triage issues at a glance and quickly react to urgent problems. Perhaps you'll choose to ignore issues that are only prevalent on jailbroken devices. Maybe you'll choose to first focus on fixing problems that arose because of the latest OS release. Significance badges will help you make smarter decisions with your troubleshooting time.
Custom Keys and Logs
Crashlytics lets you instrument logs and keys, which provide additional information and context on why a crash occurred and what happened leading up to it.
Specifically, you can use logs to gather details on what users were doing right before they encountered a crash (ex. user went to download screen, clicked on download button). You can also use logs to get details on users' actions (ex. image download size). Logs show you a timeline of events that preceded a crash. When a crash occurs, we take the contents of the log and attach it to the crash to help you debug faster.
In some situations, knowing the last state of the user's app is just as important as the order of operations. Keys are key value pairs that record the last known value of something, because they get overwritten as a user navigates through your app. For instance, you can use keys to track the last level a user competed in your gaming app, or the most recent configuration of their custom settings - anything that may be indicative of context that might be relevant for debugging.
Logs and keys are great ways to find clues in the session metadata and retrace your users' steps to reproduce the bug.
Realtime alerting
Stability issues can pop up anytime - even when you're away from your workstation. Not only will new issues appear and be prioritized in realtime in your Crashlytics dashboard, but we'll also send you email notifications when new issues arise, if issues regress, and if issues suddenly increase in impact. That way, you can grab a coffee and step away with the peace of mind that we've got your back. Crashlytics will alert you if anything goes awry with your recently shipped app, so you never miss a critical crash.
Firebase Crashlytics + Cloud Functions for Firebase
In addition to bringing many powerful Crashlytics features into Firebase, we've also gone one step further by starting to integrate Crashlytics with other parts of the platform. Now, you can use Crashlytics data as an event source to trigger Cloud Functions for Firebase to streamline and customize your troubleshooting process. With this integration, you can automate a workflow that routes issues impacting critical app flows (such as your purchase flow) directly to engineers on your team, or to a Slack channel. This way, you can ensure that urgent issues are monitored and escalated properly and promptly.
We're also funneling stability data into various parts of the redesigned Firebase console, so you don't have to dig between different pages to stay on top of stability. Crashlytics data is now visible on your project overview page, Google Analytics for Firebase dashboard, and of course, the latest release section.
This beta launch of Crashlytics is just the beginning of combining the best of Fabric and Firebase. Customers have already started using our platforms together to achieve amazing results. Take Doodle, an app that helps people find the best date and time to meet, as an example. Doodle used Crashlytics and Remote Config to redesign their app and increase retention and engagement.
New Firebase customers can get started with Crashlytics by installing Firebase and clicking on Crashlytics in the left-hand navigation bar, while existing Crash Reporting customers can click on the banner in their dashboard. We'll continue to build out Crashlytics and can't wait to hear your feedback!
If you're already using Crashlytics on Fabric, you're all set for now - no need to migrate yet. We'll share exciting news soon about how your Fabric apps can take advantage of Firebase Crashlytics.
