Since Firebase first released an iOS SDK, CocoaPods has been the preferred way to add Firebase to your iOS projects. CocoaPods has served the iOS community well and has made adding libraries and frameworks as easy as adding their package name to your project's Podfile file and running pod install.
Podfile
pod install
In recent years, Swift Package Manager has grown in popularity thanks to being officially supported by Apple, and its tight integration with Xcode. The 2020 iOS Developer Community Survey shows that more than 41% of app developers use Swift Package Manager in their business apps. For hobby/personal apps, that number is even higher at > 56% of developers using Swift Package Manager in their projects.
Adding support for Swift Package Manager has been one of the most requested features in our issue tracker:
Firebase shipped initial (beta) support for Swift Package Manager in August 2020 with Firebase 6.31.0 for a partial set of Firebase products.
Today, we are excited to announce that as of Firebase 8.6.0 for iOS, Firebase fully supports Swift Package Manager. This means you can now add Firebase to your iOS project without leaving Xcode. Gone are the days of having to maintain a working Ruby installation, or having to remember the correct command line arguments just to be able to add a Swift library to your iOS project.
Adding Firebase to your iOS project is easier than ever before with Xcode 12.5:
Adding support for Swift Package Manager was a multi-year project that not only required us to refactor our directory structure and build options to conform to SwiftPM's requirements - we also worked closely with the SwiftPM community to resolve integration issues with binary libraries, resource support, and - last but not least - unit testing support.
Performance Monitoring was the last Firebase product that was missing support for Swift Package Manager, and just a few days ago, the Performance Monitoring team completed their work to get ready for SwiftPM. This involved substantial investment in migrating from Protobuf to nanopb, a refactoring that reduced the size of the SDK by more than 30%.
We know that many of you have been looking forward to being able to migrate to a SwiftPM-only project setup, and we're excited to be able to say that using Swift Package Manager is now the preferred way to add Firebase to your iOS project.
We're working on updating the documentation, setup flows, and quickstart apps to reflect this change.
Come visit us on our GitHub discussion board and issue tracker, and let us know what you think, or if you have any questions about migrating from CocoaPods to Swift Package Manager.
Hello Firebase Developers!
Dependency management is probably one of your least favorite aspects when it comes to app development - whether that’s managing dependencies for an app that you’re building or for an open source project that you’re maintaining.
That’s why we’ve been working on improving dependency management and versioning for our Firebase iOS SDKs, and putting the spotlight on our Firebase BoM (“Bill of Materials”) for Android.
For both platforms, our goal is to make it easy to know which SDK versions to pick for the products you want to use without any muss or fuss, and move straight on to developing your app. There are few other really important motivating factors too.
Let’s get into the specifics for each platform.
Previously, each Firebase SDK for each product maintained its own version number - for both the SDK and the CocoaPod itself. Whenever an SDK got updated, both the SDK and CocoaPod version numbers would get updated too.
This approach was helpful in that each product could update independently more easily, but we’ve heard your feedback that it also had some drawbacks:
That’s why we’re moving to a unified versioning model for all our Firebase SDKs moving forward.
Every Firebase product will now use the same unified version number for its iOS SDK. At each release of a major or minor update, this version number will update for all iOS SDKs. That means that you can just select the same Firebase SDK version number across all Firebase products you want to use - they’ll be designed to be compatible with each other. For any patch releases, the affected product will be fully compatible with all other products at the same minor version. You can run `pod update` to install the latest patches for all products.
There are also a few more reasons why we think moving to this unified versioning model will help iOS developers in the long run.
We’ve been making more and more of our iOS SDKs open source, which has been great for community engagement, but contributing to them hasn’t always been easy.
In the previous model, whenever a product had a new release, a new individualized tag was created for that product. When it came to integrating multiple Firebase products together, these individualized tags made it difficult to figure out which product's tags matched with each other - both from the perspective of using Firebase to build an app, or to contribute to the open source libraries.
With the unified versioning model, you can directly map your Firebase SDK integrations to a single tag in GitHub for both CocoaPods and the Swift Package Manager. The new model also makes it easier for contributors to understand our release and versioning strategy, and make contributions going forward.
While our current release strategy still revolves around CocoaPods, the versioning system we’re now using closely mirrors the conventions used in the Swift Package Manager as well.
Getting ready for that versioning system was additional motivation to move to this model. In fact, the Swift Package Manager for Firebase is now in beta if you want to give it a try.
Over in the Android world, we’re leveraging Gradle’s support for Android BoMs (or “Bill of Materials”), which provides a way to manage the versions for all the libraries you use by specifying a single BoM version for your app.
Firebase has its own “Firebase Android BoM” which has been around for a while, but we’re putting it back into the spotlight as it’ll be the recommended way to manage your library dependencies going forward. When using the Firebase BoM, all you need to do is set a single Firebase Android version in your app - the BoM’s version - and the BoM will pull in the versions of the libraries mapped to that specific BoM.
When you use the Firebase BoM, you’ll still need to declare which Firebase libraries you want to use in your app, but you will no longer need to specify which versions of those libraries your app will require. Instead, just specify the BoM version you want to use, and the BoM will manage which library version to use. And all these versions will be cross-compatible with each other!
Here's an example build.gradle file that uses the BoM:
dependencies { // Import the Firebase BoM implementation platform('com.google.firebase:firebase-bom:25.11.0') // When using the BoM, don't specify versions for Firebase dependencies implementation 'com.google.firebase:firebase-analytics' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
If necessary, you can override the library version specified in the BoM by including the desired version in the library's dependency declaration. For example:
dependencies { implementation platform('com.google.firebase:firebase-bom:25.11.0') implementation 'com.google.firebase:firebase-analytics:17.5.0' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
The goal behind using the Firebase BoM, though, is to avoid needing to do this in your project. Each BoM version is curated to include library versions that all play well together.
The improvements mentioned above are a start to further improvements we plan to make in the near future - from better support for the Swift Package Manager, to providing easier getting started journeys in the Firebase Assistant plugin in Android Studio.
Please stay tuned for more, and as always, reach out to us on the GitHub issue trackers for the Firebase iOS SDK and the Firebase Android SDK to let us know what you think about these updates.
Firebase Authentication provides an end-to-end identity solution for your applications, which allows you to authenticate and verify users with passwords, phone numbers and popular federated identity providers such as Google, Facebook, Twitter, and Microsoft.
Today, we are pleased to announce beta support for Sign in with Apple in Firebase Authentication. Sign in with Apple allows your users to sign in to your applications and websites using their Apple ID.
Firebase also provides FirebaseUI, a customizable drop-in authentication UI that allows developers to easily implement a variety of authentication flows using any of the authentication services supported by Firebase, including Sign in with Apple.
Support for Sign in with Apple is available in beta now, and can be integrated in your applications using the latest versions of the Firebase SDKs for iOS, Android, and the web.
Firebase Auth client SDKs make it possible to sign in as a Firebase user from federated identity providers, including Google, Facebook, and Twitter. The Firebase Auth team is always looking for opportunities to improve the auth experience for developers and users. We know that more sign-in options mean more opportunities to create the best app experience. That's why we are pleased to announce that you can now sign in to Firebase Auth using Microsoft and Yahoo!
Firebase Auth has added two new federated identity providers! Today, Microsoft and Yahoo join our growing list of providers. Applications that rely on these providers no longer have to handle custom credentials on the backend. With this simplified auth flow, developers can spend less time on implementing authentication and more time to spend on the core features of your application. Developers who implement Microsoft or Yahoo sign in for Firebase Auth will also get the benefit of a new, simpler way to get the provider credentials.
Signing in to Firebase with a given identity provider requires garnering a credential from that provider. This often involves including the provider's SDK and implementing the provider's sign-in methods before passing the credentials to Firebase Auth. For some providers, this can be particularly difficult on a native client, especially ones which do not support their own native SDKs. In order to remove the headache of implementing sign-in flows for these identity providers, we now offer generic OAuth2 provider sign-in.
Generic identity provider sign-in provides an easy means for developers to get that credential and use it to sign in by popping up a ChromeCustomTab on Android or a SafariViewController on iOS which will use the Web flow to generate the Identity Provider Credential, and then continue the sign in. Generic sign-in gives you many benefits:
Generic sign-in is available for Microsoft and Yahoo, and will be a feature of other identity providers in the future.
Ready to get started with Microsoft and Yahoo sign-in for Firebase Auth? Check out the guides linked below:
Microsoft Authentication for iOS
Microsoft Authentication for Android
Microsoft Authentication for Web
Yahoo Authentication for iOS
Yahoo Authentication for Android
Yahoo Authentication for Web
Quickstart for iOS
Quickstart for Android
Quickstart for Web
We at the Firebase office all enjoyed playing with Hanley Weng's "CoreML-in-ARKit" project. It displays 3D labels on top of images it detects in the scene. While the on-device detection provides a fast response, we wanted to build a solution that gave you the speed of the on-device model with the accuracy you can get from a cloud-based solution. Well, that's exactly what we built with our MLKit-ARKit project. Read on to find out more about how we did it!
This image takes a while to load, but it’s worth it.
ML Kit for Firebase is a mobile SDK that enables developers to bring Google's machine learning (ML) expertise to their Android and iOS apps. It includes easy-to-use on-device and cloud-based Base APIs and also offers the ability to bring your own custom TFLite models.
ARKit is Apple's framework that combines device motion tracking, camera scene capture, advanced scene processing, and display conveniences to simplify the task of building an AR experience. You can use these technologies to create many kinds of AR experiences using either the back camera or front camera of an iOS device.
In this project we are pushing ARKit frames from the back camera into a queue. ML Kit processes these to find out the objects in that frame.
When the user taps the screen, ML Kit returns the detected label with the highest confidence. We then create a 3D bubble text and add it into the user's scene.
ML Kit makes ML easy for all mobile developers, whether you have experience in ML or are new to the space. For those with more advanced use cases, ML Kit allows you to bring your own TFLite models, but for more common use cases, you can implement one of the easy-to-use Base APIs. These APIs cover use cases such as text recognition, image labeling, face detection and more. We'll be using image labeling in our example.
Base APIs are available in two flavors: On-device and cloud-based. The on-device APIs are free to use and run locally, while the cloud-based ones provide higher accuracy and more precise responses. Cloud-based Vision APIs are free for the first 1000/API calls and paid after that. They provide the power of full-sized models from Google's Cloud Vision APIs.
We are using the ML Kit on-device image labeling API to get a live feed of results while keeping our frame rate steady at 60fps. When the user taps the screen we fire up an async call to the Cloud image labeling API with the current image. When we get a response from this higher accuracy model, we update the 3D label on the fly. So while we are continuously running the on-device API and using its result as the initial source of information, the higher accuracy Cloud API is called on-demand and its results replaces on-device label eventually.
Which result to show?
While the on-device API is real-time with all the processing happening locally, the Cloud Vision API makes a network request to the Google Cloud backend, leveraging a larger, higher accuracy model. Once the response arrives, we replace the label provided by the on-device API with the result from Cloud Vision API.
1. Clone the project
$ git clone https://github.com/FirebaseExtended/MLKit-ARKit.git
2. Install the pods and open the .xcworkspace file to see the project in Xcode.
$ cd MLKit-ARKit
$ pod install --repo-update
$ open MLKit-ARKit.xcworkspace
GoogleService-Info.plist
Info.plist
At this point, the app should work using the on-device recognition.
★ The cloud label detection feature is still free for first 1000 uses per month. Click here to see additional pricing details.
At this point, the app should update labels with more precise results from the Cloud Vision API.
Notifications are one of the most powerful ways of bringing latent users back to your app. Properly timed and targeted notifications can be vital in increasing engagement. That's why we've redesigned the Firebase notifications dashboard to support much more sophisticated and powerful notification campaigns.
The old notifications dashboard let you set up notification campaigns as one-time alerts that could go out immediately, or be scheduled for a later date. For example, with a few clicks, you could set up a notification campaign that would remind new users who failed to complete onboarding to do so on Monday. However, it was not possible to automate this reminder to go out every Monday - unless you did it manually.
In the new Firebase notifications dashboard, we have added the ability to create recurring campaigns. Recurring campaigns are notification campaigns that run automatically, whenever a user meets the targeting conditions. Now, it's easy to set-up that weekly reminder to encourage new users to complete onboarding. Or, perhaps you want to offer bi-weekly discounts on in-app purchases to spenders to nudge them towards a purchase - that's also possible!
The new notifications dashboard allows you to set user-level message frequency caps, so you can limit the number of times a user gets a message to prevent spamming them. You can limit messages to only be sent once per user, or allow one message over a specified number of days.
Perhaps you want to send a welcome message once to each new user. Use a single message to target every new user once. Or, perhaps you want to encourage users to check out a tutorial on how to use the app. You can send a notification once every few days to guide them towards the action until it's been completed. And since targeted segments are dynamic, users who meet the criteria will automatically start receiving notifications, and users who no longer meet the criteria will stop receiving the targeted notifications. This means your notification will only be delivered to users who find it relevant.
Users can receive a notification just once
Users can receive notifications at a custom interval
Untargeted batch and blast notifications are annoying and can cause churn. It's vital to carefully segment the right users so your notification appears welcome and relevant to their recent interaction with your app - not out of place and random. The new notifications dashboard includes a more sophisticated segment builder that gives you the ability to target prevalent user characteristics, like last app engagement and the number of days since they first opened the app. This targeting is built into the dashboard, so you don't have to add any code to get these new parameters.
Finally, we also improved the results section of the notifications dashboard so you can better monitor the performance of your campaigns and make adjustments as needed. In the new notifications dashboard, you can now track the effectiveness of recurring campaigns day-by-day. Here, you can see daily data points for notification sends, opens, and conversions. You'll also notice that the graphs have been updated from a bar chart to a time-series graph, which are more intuitive and easier to interpret.
The redesigned Firebase notifications dashboard offers new, powerful campaign options, sophisticated targeting, and rich analytics to track the progress of your notifications campaigns. If you're new to Firebase notifications, get started with the Firebase Cloud Messaging guides.
Check out the Firebase console to set up your notification campaigns today!
When Test Lab was originally launched with Firebase in 2016, it supported only Android devices. At Google I/O 2018 in May, Test Lab launched closed beta support for iOS. This included a limited set of iOS devices and a basic UI.
Building comprehensive tests for Android involves writing code, using Espresso and UIAutomator, that acts as a sort of "remote control" for your app. Similarly, on iOS, testing is performed using XCTests. In both cases, Test Lab can run your tests against actual devices in a cloud-hosted device farm.
At the Firebase Summit in Prague at the end of October, the Test Lab team announced general availability of support for iOS, including ten models of iPhones and iPads running seven different versions of iOS, including iOS 12. We have also improved the iOS documentation and console experience for you.
Test Lab also launched a number of improvements to Robo, a tool which runs fully automated tests against your app running on Android devices. Here's what's new with Robo.
Games are difficult to crawl because they often have a highly customized UI, rather than using system widgets. This makes it difficult for Robo to crawl the game's experience. Now, if Robo detects that the app under test is actually a game, it will perform random taps and swipes in an effort to interact with the game's UI. This can yield useful crash and performance data and is an early but significant step towards more meaningful automated game crawling.
Test Lab now detects and warns if your APK makes use of internal Android APIs. On Android P and newer, using such APIs can crash your app. Whenever such an API is accessed during a Robo crawl a stack trace is recorded in the device logs. This pinpoints the location in your app's code where the violation occurs.
Test Lab now warns developers when it notices that Robo got stuck in a crawl. For example, if the user is presented with a complicated sign-up form or a login screen, it may be difficult for Robo to satisfy the requirements of the form. In situations like this, Robo will suggest an action to the developer to help it continue a full crawl, such as providing test credentials or writing a Robo Script.
If you aren't in the habit of regularly testing your app, consider giving Test Lab a try at no cost using the free daily quota of tests. No coding is necessary to run a Robo test on Android - just upload your APK to get started. And be sure to let us know what you think in the #test-lab channel of the Firebase Slack.
As an app developer, getting users to stay with your app is one of your biggest challenges. While OS-level notifications are a great way to remind users to return to your app, they can get lost in a sea of notifications from other apps.. If you want to tell your customers about, say, some new power-up that's for sale in your in-app store, wouldn't it be better to tell them about it when they've started up your game, or completed a level, rather than when they're driving to work?
With that in mind, we recently released the latest product to help you grow your app: Firebase In-App Messaging. With In-App Messaging, you can now engage users who are actively using your iOS or Android app by sending them targeted, personalized, and contextual messages. These notifications nudge users toward important in-app actions, such as subscribing to your newsletter, watching a video, or buying an item.
You now have the flexibility and control to set-up in-app messages in a variety of formats and trigger them based on user behavior. I'm going to walk you through just one example of the many ways you can utilize Firebase In-App Messaging. I've already set up my app to be able to receive messages by following the instructions in the Getting Started guide.
Let's say that I have a social media app that's all about posting pictures of cats. I've recently launched a new sharing feature that I want to tell my users about.
This is a perfect use case for Firebase In-App Messaging! With Firebase In-App Messaging, I can create this campaign right from the Firebase Console, as shown below.
In the console, I've selected an image and button color that align with the look-and-feel of my app. I have also included a button action, which, in my case, will bring up the sharing dialog in the app, so my users can easily start sharing their favorite photos.
With In-App Messaging, you have multiple options for targeting messages, allowing you to tailor messages to the groups you want to reach. You can select all users of the app, users from specific Google Analytics audiences, users matching given properties, or users who Firebase Predictions believes will participate in a behavior in the next seven days. In my case, I am selecting all users.
With the scheduling feature, I can decide when this dialog will appear in my app. While I could use Firebase In-App Messaging to show a message to my users when they first start up the app, I'm going to make my campaign more targeted and relevant by showing this message only to my users after they like (or "paws-up") their first photo.
I also have the option to set a start and end date for my campaign, in case I'm running a seasonal promotion.
Finally, you can select a conversion event, which is the measurement you would use to determine if the campaign is successful. In my case, I'll be tracking whether or not a user has successfully shared an image.
The chosen conversion event is tracked in the Firebase console, like the chart below.
As the campaign continues, I can track impressions, button clicks, and conversions. I can also edit the campaign, allowing me to test changes that may improve the conversion rate.
This is just one example of how In-App Messaging can promote conversion. It can also be used to highlight a sale or coupon within an ecommerce app, inform users of terms of service updates, or showcase new features. A guiding light within an app, Firebase In-App Messaging encourages app exploration and discovery, increases session time, and spurs conversions. For more examples, check out our blog announcement!
Ready to dive in? Get started today by checking out the documentation:
Getting started with Firebase In-App Messaging
Have a cool use case for Firebase In-App Messaging? Share it with me on Twitter at @ThatJenPerson. I can't wait to see the campaigns you build!
Firebase has an impressive feature list for getting your apps up and running quickly. I love that I can go from idea to working app in a matter of hours! But for developers who haven't had much experience with asynchronous programming, it's easy to get bogged down in the details. Heck, I've been working with Firebase for two years and I still find myself pausing to think about how I want to handle asynchronous calls. What will my view look like while waiting to populate data? How should I set up my data class so that it can alert the view controller about updates? After lots of practice and exploring options, I feel like I finally have an answer that works for me.
Now I'm not going to get into the what and why of asynchronous programming with Firebase because Doug Stevenson already addressed this in this great blog post. Instead, I want to get into how to get a function that uses an async callback working the way you want it to in Swift.
Take this example function I have below from this photo app I've created. It queries Cloud Firestore for 10 documents in a collection called "cats". Once the Cat data is downloaded, I want to use it to populate a UITableView with information about the cat photos.
// ViewController.swift var dbRef = Firestore.firestore().collection("cats") var cats = [Cat]() func downloadCats() { // order the posts by timestamp let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in print(error ?? "No error.") // iterate through the documents and create Cat objects guard let snapshot = snapshot else { return } for doc in snapshot.documents { let cat = Cat(snapshot: doc) self.cats.append(cat) } } print(cats) // 1 what will this print? tableView.reloadData() }
What will be printed at "1"? Since the call to getDocuments is asynchronous, the closure will be run when the download of data is completed sometime in the future. Commands that I write following the closure will be run immediately -- they do not wait for the work in the closure to be complete. So chances are, in the scenario above, that print statement is going to print an empty array. The UITableView will reload data immediately, so any Cat objects that were supposed to populate the view will not appear. That's not the behavior we want. So what can we do?
getDocuments
print
.
UITableView
Cat
One simple option is to move the functionality I want into the closure, like so:
// ViewController.swift func downloadCats() { let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in print(error ?? "No error.") for doc in snapshot!.documents { let cat = Cat(snapshot: doc) self.cats.append(cat) } print(cats) // 1 what will this print now? tableView.reloadData() } }
What is printed at "1" now? We should now see the full array of Cat objects, and when tableView.reloadData() is called, the UITableView can populate with the data of those Cats, assuming you've set up your UITableViewDataSource for it. This is a viable method for handling data in the closure, but it means you'll have to include this functionality in your UIViewController. As you add more functionality, such as different kinds of queries, Auth, Cloud Storage, and callable Cloud Functions, you'll quickly have a Massive View Controller on your hands.
tableView.reloadData()
UITableViewDataSource
UIViewController
I like to keep this functionality separate from my view controller whenever possible. I can do this by wrapping getDocuments() in a function with a completion handler. If I include a completion handler in this function, I can call completion() when the array of Cats is populated.
getDocuments()
completion()
// CatManager.swift var dbRef = Firestore.firestore().collection("cats") var cats = [Cat]() // function includes an completion handler, marked with @escaping func downloadCats(completion: @escaping () -> Void) { let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in print(error ?? "No error.") self.cats = [] guard let snapshot = snapshot else { completion() return } for doc in snapshot.documents { let cat = Cat(snapshot: doc) self.cats.append(cat) } completion() } } }
Then inside the view controller, I can call my function like this:
// ViewController.Swift func initializeCats() { activityIndicator.startAnimating() CatManager.sharedInstance.downloadCats() { // Data for UITableView is populated from the CatManager singleton self.tableView.reloadData() self.activityIndicator.stopAnimating() } }
Now I'm controlling the view from the view controller, reloading the tableView and indicating when the activityIndicator should run. The data is being handled in the CatManager class. This does, however, require a singleton, so while it may prevent a massive view controller from developing, singletons come with their own host of issues.
tableView
activityIndicator
CatManager
Instead of passing void in the completion, I can pass some useful values: an array of Cats and an optional error.
error
// CatDownloader.swift // Use instead of CatManager func downloadCats(completion: @escaping ([Cat], Error) -> Void) { var catArray = [Cat]() let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in if let error = error { print(error) completion(catArray, error) return } for doc in snapshot!.documents { let cat = Cat(snapshot: doc) catArray.append(cat) } completion(catArray, nil) } } }
With this function, since I pass the error in the closure, the view controller can be made aware of an error and display it to the user. Here I made a function called alert() that displays a UIAlertController. I can also create an instance of CatDownloader in the class because I don't need to depend on a single CatManger to keep track of the Cat array.
alert()
CatDownloader
CatManger
// ViewController.swift // create an instance of CatDownloader let catDownloader = CatDownloader() //… func initializeCats() { activityIndicator.startAnimating() catDownloader.downloadCats() { catArray, error in self.activityIndicator.stopAnimating() if let error = error { self.alert(title: "Error", message: error.localizedDescription) return } self.cats = catArray self.tableView.reloadData() } } func alert(title: String, message: String) { let alertController = UIAlertController(title: title, message: message, preferredStyle: .alert) let action = UIAlertAction(title: "OK", style: .default, handler: nil) alertController.addAction(action) navigationController?.present(alertController, animated: true, completion: nil) }
You may want to display a custom error message to the user instead of the error description, but you can see how the closure made it easy to get the info I needed to the right place in my app. You can use this same configuration for other Firebase features that incorporate closures, including the Realtime Database, Authentication, and ML Kit.
And there you have it! Now go forth and write your own functions with closures to help you update your views. What other examples would you like to see? Do you have any cool solutions you've found that you'd like to share? Reach out to me on Twitter at @ThatJenPerson to tell me all about it!
Firebase is returning to the Game Developers Conference this year in San Francisco! We've been hard at work making Firebase more valuable for all you game developers out there, and would love to spend time talking with you about how we can make it even better.
While we'll be available to chat at booth 823 for the rest of the conference, we also dropped by the Google Developer Day on Monday to share a few exciting announcements with everybody. In case you missed it, here's the quick summary:
Firebase Auth already lets your players log in safely and securely through a variety of ways -- everything from using their Facebook or Google account to a custom email and password -- but we've now added support for players to sign in using Google Play Games Services (GPGS).
If you're currently using GPGS in your game, you can use the credentials you already have to authenticate your users' accounts with the Firebase service. And if you haven't used GPGS in your Android games yet, you really should because it's an easy -- and often frictionless -- way to get your players signed in. Either way, this means your game can start using Firebase to store user-specific data in Realtime Database or Cloud Storage as soon as your players are signed in through GPGS.
While many of you are developing games for mobile devices, we know that it's often much more convenient to build and test your game on a desktop machine. With that in mind, we've added desktop support so that Firebase will work right from your development environment (Unity player on a Windows machine, for example). This support includes products like:
So if your game relies on one of these products, you can continue to use the same development process you always have, without the hassle of deploying your game on a device every time you want to test it.
Note that desktop support is intended to make development and testing easier, but it's not for publishing Firebase-enabled games to end users on desktop machines.
We debuted Firebase Predictions and A/B Testing at the Firebase Developer Summit in Amsterdam a few months ago, but we think both of these features are so useful to game developers that we want to mention them again. :)
Firebase Predictions brings the power of machine learning to Firebase. By analyzing your players' behavior, we can predict which ones will be most likely to churn out, spend money, or perform any other conversion event that you've defined in Analytics. This allows you to customize your app's behavior (using Remote Config or Notifications) specifically to that group of users. Want to engage players who are likely to stop playing your game? Give them extra lives, or send them a free gift they can redeem inside your game! Want to target players who are likely to spend money on in-app purchases? Notify them about a big sale, or change the layout of your in-app store!
In fact, Rockbite Studios did just that. They used Remote Config to feature certain items at the top of their in-app store for players who were predicted to spend money in their game, while also adding new ad-viewing options for players who were predicted to not spend money. As a result, they boosted revenue by 25% for their spenders, and 24% for their non-spenders!
Firebase A/B testing is great way to improve your game by making data-driven decisions based on experiments that you can run inside your app. Want to know if increasing the difficulty of your game will increase or decrease player engagement? Curious to learn if increasing the amount of premium currency your players start off with will increase or decrease your overall revenue? You can run experiments to uncover answers to all of these questions (and much much more) through Firebase A/B testing.
Firebase A/B testing is easy to get started with, as it runs on top of Remote Config and Analytics, which you might already be using. Experiments can be set up entirely through the Firebase console, which means your game designers or analysts can build, publish, and analyze experiments on their own without needing too much time from your engineering team. And it's all available at no cost to you, which is always nice.
If you want to learn more about how Firebase can make it easier for you to build successful games, come talk to us! We'll be available at booth 823 all during the expo, and we're giving a special presentation on what's new with Firebase and the Google Cloud Platform on Wednesday, March 21st, at 3:30 in the South Hall.
And of course, you can always find out more at https://firebase.google.com/games/
Game on!
Firebase helps you create better games faster without needing to build and maintain a backend infrastructure. We are really excited to announce the availability of our demo application MechaHamster for iOS on the App Store. If you're an Android user you can check out our prior release on the Google Play Store.
MechaHamster is built on our easy to install Unity SDK, and takes advantage of several powerful Firebase features, including:
Want to see how easy it was to plug Firebase into MechaHamster yourself? Check out the Unity project over at Github: https://github.com/google/mechahamster
We can't wait to see what amazing iOS games you build with Firebase. To find out more about how Firebase can power up your games, grow your business and create better experiences for your players head to https://firebase.google.com/games/
