Over the last decade, mobile gaming has evolved from stacking colored blocks on a phone to encompass multidimensional and multiplayer experiences that engulf people in imaginative, high-fidelity worlds. As games have gotten more engaging, they’ve also become more complex to develop and maintain. Here at Firebase, we’re committed to providing game developers with the tools and resources you need to build, release and operate successful games that delight players.
We participated in the Google for Games Developer Summit in March, launched Unity and C++ SDKs for Cloud Firestore into open alpha, shipped improved workflows for Unity developers, debuted some new video tutorials, and wrote some new blogs too - so you can easily add Firebase to your game and get the most out of our platform.
We have more exciting updates to come, driven by your feedback and stories. Recently, we spoke to Gameloft to understand how they’ve been using Firebase.
Gameloft is one of the world’s largest gaming studios, employing 4,600 people across 19 global offices. Their vast portfolio consists of over 190 critically-acclaimed, award-winning games that are played by 80 million people each month. Gameloft develops original franchises, like Dungeon Hunter, and also partners with major entertainment studios like Disney.
With such a broad portfolio and audience, having the ability to monitor the stability of their games in a holistic way, and the agility to respond to issues quickly, is key to their success. However, they were lacking proper information about crashes, having a hard time reproducing crashes, and unforeseen technical issues were taking too long to track and fix, upsetting both their team and their players.
Gameloft realized they needed a robust crash reporting tool that could help them improve game quality in a more streamlined and efficient way, so they turned to Firebase Crashlytics.
Crashlytics aggregates crashes by root cause, highlights the impact on players, and provides contextual information on each issue, which helps Gameloft prioritize the crashes to fix first and speeds up their troubleshooting process. By using Crashlytics, Gameloft achieved a 10% reduction in users experiencing crashes overnight for one of their games (Overdrive City). According to Gameloft, this also led to a bump in the game’s Play Store rating and increased session duration by 16%! Find out what Gameloft did to drive these results with Crashlytics by reading the full case study. And learn more about how Firebase can help you build and grow your game, and see what other game studios are using Firebase.
With our announcement of the Firebase Crashlytics SDK Beta in February, we provided a path to help you remove all Fabric dependencies in your code, and complete your migration to Firebase. Since then, tens of thousands of apps have adopted the Beta SDK, and several hundreds of millions of end-users are using apps that include the SDK. Thank you to the adopters of our Beta SDKs; with your help, we have been able to polish and debug our SDK so we could ship it in its best possible launch state.
We are excited to announce that the Firebase Crashlytics SDK is now publicly available! Whether your app was migrated from Fabric or created in Firebase, we encourage you to upgrade to the official version of the Firebase Crashlytics SDK.
Now that the Firebase Crashlytics SDK is publicly available, we are deprecating the legacy Fabric SDK. The Fabric SDK will continue reporting your app's crashes until November 15, 2020. On this date, the Fabric SDK, and beta versions of the Firebase Crashlytics SDK, will no longer send crashes to your Firebase dashboard. To continue getting crash reports in the Firebase console, make sure your app has the following versions of the Firebase Crashlytics SDK, or newer: 17.0.0+ for Android, 4.0.0+ for iOS, and 6.15.0+ for Unity. Developers new to Crashlytics should begin with our getting started docs.
As always, we’d love to hear your feedback! Let us know what you think through our official support page!
Happy coding!
Update: To show respect for current events, we are postponing the launch of Firebase Live to June 23rd. Please take care of yourselves and your families. We look forward to connecting, sharing and learning together very soon. Stay tuned for updates.
Here at Firebase we are extremely proud of our avid developer community. We love interacting with so many of you at different events throughout the year. Our event plans have changed this year, but one thing that hasn’t changed is our commitment to you and all of the great stuff you build. So we’re trying something new to virtually bring everyone together, and are excited to introduce Firebase Live!
Firebase Live is a new 5-part weekly web series for developers consisting of talks, tips, and technical tutorials to help you increase productivity and collaboration among your team. Every Tuesday at 9:30am PST from June 23 through July 21, we’ll host a new video highlighting best practices and product updates. Everyone can watch the new video together and chat with members of the Firebase team and other developers along the way. After each video, Firebase experts will answer all your burning questions live. The topics include:
We will also be launching a new demo and codelabs with walkthrough videos so you can learn at your own pace and build your skills.
Excited about this weekly web series? Check out our event page and follow us on Twitter to join the conversation.
We may not be able to meet in person right now, but we’re still here to help you build amazing things.
Today we are extremely excited to introduce the Emulator UI to the Firebase community. The Emulator UI is a local web app that allows you to manage local emulators that make up the Firebase Local Emulator Suite.
Last year we released the Emulator Suite to simplify Firebase debugging and development. Until now, the Emulator Suite has only been exposed through the Firebase CLI. Today, the Emulator UI makes it even easier to develop locally with Firebase.
The Emulator UI aims to give you the freedom to develop on Firebase without concerns about billing or breaking a shared environment.
Need to create a function that triggers on the creation of a Firestore document? You can write that code, run it locally, and then create a document in the Emulator UI and see the trigger fire. What's better is that you can even see the logs of the local function to help with any debugging or even just to ensure a successful invocation. The goal is to provide you the safety of developing and testing your code without interfering with shared environments, waiting on deploys, or incurring billing costs.
The Emulator Suite doesn't just help with developer productivity, it also aims to help with team productivity as well. Having a local first environment also allows you to onboard new developers to your team without them needing to manage a cloud-connected Firebase project. Just run a few CLI commands and the Emulator Suite is up and running with local instances of Firebase services.
One of the biggest goals of the Emulator UI is to provide you with a local first workflow. Firebase has always been an online connected service. Most development required managing multiple projects, usually one for production and several others for prototyping, staging and development. The Emulator UI allows you to shift away from needing the online connected project and lets you start your development workflow with local instances.
The Emulator UI is not an exact copy of the online Firebase console. It's tailored for the functionality you need while developing. Here's just a small list of capabilities of the Emulator UI:
...and there's still more to come! We have plenty of features to simplify development planned for the future.
The emulators were designed to run locally. This means it has a looser set of restrictions on managing your data. We want to provide you the freedom to quickly delete and restore data without having to click through a million prompts. But we also don't want you to confuse a local environment with a production one. We took steps to clarify that you are operating in a local environment.
The Emulator UI introduces a new color into the Firebase palette. You'll notice as you navigate around, purple is the new primary color for all buttons, hover and selected states, and other primary actions in UI components. Even the favicon is purple! The online Firebase console uses a blue as the main active state color. With just a quick glance you'll be able to see the difference.
We also moved the navbar to the top for quick navigation. The Overview page displays the local ports of each instance as a reminder as well. We also provide a link to get your production/managed Firebase project, to help establish you are in a local environment versus a production one.
pssst… If you spend enough time in the Emulator UI, you also might find some new features in the Realtime Database data viewer.
Make sure you update the Firebase CLI to version 8.4.0 and run the following command:
firebase init
Select the products you need to initialize. Which means if this is a first time setup, you'll need to set up each Firebase product you need, such as Cloud Functions, Firestore and Realtime Database rules, as well as Hosting sites. Once everything you need is initialized, run the following command:
firebase emulators:start
This will start the Emulator UI on localhost:4000 by default. Open your browser to that URL and you'll see the Emulator UI up and running.
localhost:4000
We are so excited to see the community use the Emulator UI. Our hope is that it boosts your productivity and happiness when working with Firebase. But this is just the first step. We want to know what you are looking for in the Emulator Suite. Send us a tweet! We'd love to hear from you.
We know that Kotlin is the future of Android and that Kotlin developers want clean, idiomatic APIs when they use Firebase in their apps. For the past year, we've been releasing Firebase Kotlin extension (KTX) libraries alongside our Android Java SDKs to give Kotlin developers the best of both worlds.
Today, we're happy to announce that these KTX libraries are out of Beta and recommended for all Firebase developers using Kotlin in their Android apps!
So what does this mean for you?
To get started with our KTX libraries, look for the -ktx suffix in the "Kotlin+KTX" section of our available Android libraries. As an example, let's see what it looks like to set up Remote Config with and without the KTX library.
-ktx
app/build.gradle (before)
implementation 'com.google.firebase:firebase-config:19.1.2'
MainActivity.kt (before)
val remoteConfig = FirebaseRemoteConfig.getInstance() val configSettings = FirebaseRemoteConfigSettings.Builder() .setMinimumFetchIntervalInSeconds(3600) .setFetchTimeoutInSeconds(60) .build() remoteConfig.setConfigSettingsAsync(configSettings)
app/build.gradle (after)
// The -ktx library has a dependency on the firebase-config library implementation 'com.google.firebase:firebase-config-ktx:19.1.2'
MainActivity.kt (after)
// New global "Firebase" class val remoteConfig = Firebase.remoteConfig // New settings builder syntax val configSettings = remoteConfigSettings { minimumFetchIntervalInSeconds = 3600 fetchTimeoutInSeconds = 60 } remoteConfig.setConfigSettingsAsync(configSettings)
And the KTX libraries that we have available today are just the beginning, as we're working hard to add coverage for all Firebase products and add new Kotlin-focused features in the near future!
We wouldn't have been able to release these KTX libraries without the help of all the Kotlin enthusiasts in the Firebase community. We'd like to give a special shout out to Rosário Pereira Fernandes who contributed so much excellent code and documentation to the KTX effort.
If you have feedback or want to contribute, you can find us on GitHub.
