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!
Posted by Patrick Martin, Developer Advocate
Historically, to integrate Firebase into a Unity game, a developer would have to go through the process of downloading a fairly large zip file with a number of unitypackage files in it for each Firebase product. Then they would slowly import each package one by one.
Since the SDK needs to be placed in several disconnected “special” folders, it can be hard to remember which Firebase plugins you have installed. This is especially difficult when upgrading Firebase since you have to remember to upgrade each feature you’ve decided to use manually.
Typically a developer should install the Unity packages in the “dotnet4” folder, but this isn’t a universal rule. Especially for a newer developer, it can be confusing that “.NET Standard 2.0” means the “dotnet4” folder even though “2.0” is closer to the “3” in “dotnet3”:
These issues are a result of careful planning around Firebase’s desired level of simplicity, Unity’s architecture. It also allows us to continue supporting developers who cannot upgrade their Unity version for technical reasons. These unitypackage files are not going away, and we’re continuing to support Unity developers back to the Unity 5 branch.
Because of this complexity, the team is always looking for ways to simplify the Firebase for Unity integration process. In 2018, Unity began implementing the “Unity Package Manager” -- a NPM based solution for managing prebuilt dependencies. As of Unity 2020.1, this new package manager has become easier than ever to use. Firebase has fully embraced this new system, and I can readily recommend it as the simplest way to add and maintain the Firebase plugin in current and future Unity based games.
There is no change to the Firebase backend for this new process. So if you’re starting a new project, begin in the Firebase console as you normally would.
but when it becomes time to download the Firebase SDK, just ignore it!
Instead, jump on over to Unity.
Here you want to go to your Build Settings. From there click Player Settings. Finally, in the Player Settings window, select Package Manager.
From the Package Manager window, you’ll want to create a new “scoped repository”. Then enter:
Name: Game Package Registry by Google
Game Package Registry by Google
URL: https://unityregistry-pa.googleapis.com
https://unityregistry-pa.googleapis.com
Scope(s): com.google
com.google
Now you can manage Firebase dependencies directly in the Unity Package Manager under “My Registries.”
We’ve added a scoped registry to Unity named “Game Package Registry by Google” in a process very similar to what a Node developer would expect. This means that it’s a repository unaffiliated with Unity but can otherwise enjoy an integration path akin to core engine features such as Unity’s new input system or the Entity Component System. The name of the scoped registry is simply a hint for yourself and you may change this name if you want, but the URL and Scope(s) added are fixed. The URL tells Unity where to find the Google packages and the Scope(s) telling Unity the package names that this registry can handle, in this case any package that starts with “com.google”.
Before this new process, you would now have on your disk a large zip file with redundant Unity SDKs depending on whether or not your version of Unity had the class Task. You unzipped this somewhere on your file system and began importing each of these unitypackage files. These files themselves were larger than necessary since each one had a copy of every dependency in it, relying on Unity to not import the files you didn’t need. This way a developer wouldn’t accidentally forget to add “Firebase Authentication” when integrating “Cloud Firestore.”
Task
Now, you indicate that your game depends on “Cloud Firestore” and just one copy of “Firebase Authentication” is downloaded to support it.
Another problem that developers run into is that the Firebase SDK may include several large binary objects that end up in source control. In some cases, such as the Linux shared object files, these individual dependencies are so large that they can’t be committed to popular services like GitHub without enabling Git LFS.
Now, as long as you don’t commit your Library/ directory to source control, these files are only downloaded when needed on each developer’s machine and won’t take up space in your version control system. Like other NPM based packaging solutions, Unity is intelligent with caching these dependencies, and will keep one copy in a local cache so developers aren’t constantly downloading packages as they checkout projects.
Previously, upgrading your Firebase SDK was a bit of a process. To figure out which version of Firebase you were on, you typically look in the Firebase directory for any file that looked like it had a recognizable Firebase version number in it. You’d also have to poke around in here to see which SDKs you’ve integrated into your project when upgrading so you know which unitypackage files to import.
Now you get a nice list of all the Firebase products you have installed under “In Project”:
And even individual versions for each dependency under “My Registries”:
Are you running into issues after upgrading? You can quickly scan this screen to see what you’ve missed rather than just installing all the unitypackages again!
Prior to Unity Package Manager, downgrading was even more difficult. Typically requiring you to keep copies of each Firebase SDK you’ve used or by guessing at the URLs for old SDK versions. Now, if something goes wrong, you can just go back to the package manager and revert to an old version:
The Unity Package Manager supports “scoped registries” as far back as Unity 2018. Prior to Unity 2020, you could only add the registry by modifying the file under Packages/manifest.json as noted here. The External Package Manager for Unity -- a tool that ships as part of the Firebase Unity SDK -- will also offer to automatically migrate the old style of unitypackage to the new UPM mechanism when available. If you’d like to migrate an existing Firebase install to the new UPM system, simply navigate to “Assets > External Dependency Manager > Package Manager Resolver > Modify Registries”. Note that we do not make dotnet3 variants of the Firebase packages via the Unity Package Manager, but this is only a concern for Unity 2018 users (2019 and later have dropped support for the older .NET standard).
Packages/manifest.json
Now that Firebase is just an entry in a package manifest, it’s easier than ever both to add Firebase if it sounds intriguing as well as remove it if a feature doesn’t work out. You can freely move between versions with confidence, and you’re doing all of this whilst keeping your Assets/ directory as clean as possible. This repository will also unlock other Google products such as Play Asset Delivery and Google Play Instant, giving you an easy way to test features that will improve the quality of life for your Android players.
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.
