Firebase Remote Config is a simple way for you to change elements of your app on the fly, just by using the Firebase console. As developers used Remote Config, many of you requested the ability to change these values without having to go through the Firebase console at all. We're happy to announce that you can now update your Remote Config values directly through the new Remote Config REST API.
The API itself consists of two calls: one to retrieve the current set of Remote Config values from the console, and another to set them. And to be clear, these are designed only for the purpose of setting remote config values without going through the Firebase console. If you want your clients to retrieve these values, they should do so through the native mobile client SDKs.
With this new API, you have the ability to make Remote Config more useful for your team, by creating in-house tools that incorporate specific logic that would be impossible to do from the Firebase console alone. Some examples include:
Adding sanity checks to values: If you want to give your app designers the ability to tweak values in your in-app economy without accidentally giving away something for free, you could set reasonable sanity checks around some of the values they're setting within Remote Config. You could also add character limits to strings (to avoid unsightly text overflow errors) or ensure that a string that's supposed to represent a JSON object is valid parsable JSON.
Restricting certain actions to some users: Many developers have asked for the ability to allow their marketing team to adjust content like their in-app messaging, while allowing their game designers to adjust gameplay values, without having the two overlap. With the Remote Config API, you can build your own interface to the service that will make it more difficult for a member of your team to accidentally set a value they're not supposed to touch.
Creating your own version history: With the REST API, you can create your own version history for Remote Config! Every time you publish a new change to Remote Config via the API, save out the existing Remote Config, either to a local file or a database like Cloud Firestore.
Scheduling Remote Config updates: By using the REST API in conjunction with a cron job, you can change Remote Config values on a regular schedule. So now you can power a daily message through Remote Config without waking up anybody at midnight to hit the "publish" button.
Batch importing values: Want to transition from your own proprietary system to Firebase Remote Config? The REST API allows you to do that quickly and easily.
Using Remote Config with Cloud Functions: You can use Cloud Functions for Firebase (or your own custom server code) in conjunction with the Remote Config API to start changing values in your app based on events that happen server-side. For example, you can use Remote Config to promote a new feature in your app, and then turn off that promotion automatically once you detect enough people have interacted with this new feature.
...and you've probably got a great idea or two we haven't even thought of yet.
The REST API is available starting today for anybody who wants to use it with their project, so give it a try! As always, if you have any questions about the REST API, or just want to show off some fun new tool you've built, please contact us in the Firebase Talk group, or on Stack Overflow.
At Firebase, it's our mission to help developers like you build better apps and grow your businesses. That means Firebase needs to work for you from your first user up to your millionth, with pricing plans that scale as you do.
Today, we're excited to announce that we're changing our Blaze (pay-as-you-go) plan to align with the free usage that we offer on our Spark (free) plan. To view more detail about these free usage limits, including a pricing calculator, you can check out our pricing page or scroll to the end of this blog post.
If you're on the Blaze plan and stay within these free usage limits, you will not be charged for the month and you will not receive a bill. You'll be charged for any usage above these limits at the same rates as before. The Spark and Flame (subscription) plans remain unchanged.
Tracking your spending with budgets
We've also heard your concerns about exceeding specific limits on the Blaze plan. Now, you can set up alerts, so you get notified when you're reaching usage thresholds, and set budgets in the billing section of the Firebase Console. You can choose project or billing level budgets and specific alerting thresholds.
Firebase + Google Cloud Platform
This update will also make it easier for you to use Google Cloud Platform (GCP) services. The credit card you use for the Blaze plan is also a payment method for GCP. We know that previously, it was tough to justify adding a payment method when you would lose your free tier on Firebase. With this change, you can safely upgrade to the Blaze plan to use a GCP service without it affecting your Firebase costs.
Differences in free usage between Spark & Blaze
There are a few minor differences between the Spark plan and the free usage within the Blaze plan.
Free usage on the Blaze plan is calculated daily, whereas the Spark plan is calculated monthly.
For Cloud Functions, free usage on the Blaze plan is calculated at the billing account level, not the project level (multiple projects can be associated with a single billing account). The usage limits are 2M invocations/month, 400K GB-second/month, 200K CPU-seconds/month, and 5 GB of outbound networking/month.
For Test Lab, free usage on the Blaze plan is calculated in device minutes/day, not tests/day. The usage limits are 30 Physical Device minutes/day and 60 Virtual Device minutes/day.
As always, if you have any questions, please don't hesitate to contact us. We hope these pricing changes simplify your life and let you focus on what matters: building a great app. Happy coding!
*July 11 Edit: An earlier version of this blog post said that Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully. To clarify, that means that Firebase Crash Reporting will be accessible on September 8, 2018 and will no longer be accessible on September 9, 2018.*
Back in October, we were thrilled to launch a beta version of Firebase Crashlytics. As the top ranked mobile app crash reporter for over 3 years running, Crashlytics helps you track, prioritize, and fix stability issues in realtime. It's been exciting to see all the positive reactions, as thousands of you have upgraded to Crashlytics in Firebase!
Today, we're graduating Firebase Crashlytics out of beta. As the default crash reporter for Firebase going forward, Crashlytics is the next evolution of the crash reporting capabilities of our platform. It empowers you to achieve everything you want to with Firebase Crash Reporting, plus much more.
This release include several major new features in addition to our stamp of approval when it comes to service reliability. Here's what's new.
Integration with Analytics events
We heard from many of you that you love Firebase Crash Reporting's "breadcrumbs" feature. (Breadcrumbs are the automatically created Analytics events that help you retrace user actions preceding a crash.) Starting today, you can see these breadcrumbs within the Crashlytics section of the Firebase console, helping you to triage issues more easily.
By broadly analyzing aggregated crash data for common trends, Crashlytics automatically highlights potential root causes and gives you additional context on the underlying problems. For example, it can reveal how widespread incorrect UIKit rendering was in your app so you would know to address that issue first. Crash insights allows you to make more informed decisions on what actions to take, save time on triaging issues, and maximize the impact of your debugging efforts.
From our community:
"In the few weeks that we've been working with Crashlytics' crash insights, it's been quite helpful on a few particularly pesky issues. The description and quality of the linked resources makes it easy to immediately start debugging."
- Marc Bernstein, Software Development Team Lead, Hudl
Pinning important builds
Generally, you have a few builds you care most about, while others aren't as important at the moment. With this new release of Crashlytics, you can now "pin" your most important builds which will appear at the top of the console. Your pinned builds will also appear on your teammates' consoles so it's easier to collaborate with them. This can be especially helpful when you have a large team with hundreds of builds and millions of users.
dSYM uploading
To show you stability issues, Crashlytics automatically uploads your dSYM files in the background to symbolicate your crashes. However, some complex situations can arise (i.e. Bitcode compiled apps) and prevent your dSYMs from being uploaded properly. That's why today we're also releasing a new dSYM uploader tool within your Crashlytics console. Now, you can manually upload your dSYM for cases where it cannot be automatically uploaded.
Firebase's default crash reporter
With today's GA release of Firebase Crashlytics, we've decided to sunset Firebase Crash Reporting, so we can best serve you by focusing our efforts on one crash reporter. Starting today, you'll notice the console has changed to only list Crashlytics in the navigation. If you need to access your existing crash data in Firebase Crash Reporting, you can use the app picker to switch from Crashlytics to Crash Reporting.
Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully.
Upgrading to Crashlytics is easy: just visit your project's console, choose Crashlytics in the left navigation and click "Set up Crashlytics":
Linking Fabric and Firebase Crashlytics
If you're currently using both Firebase and Fabric, you can now link the two to see your existing crash data within the Firebase console. To get started, click "Link app in Fabric" within the console and go through the flow on fabric.io:
If you are only using Fabric right now, you don't need to take any action. We'll be building out a new flow in the coming months to help you seamlessly link your existing app(s) from Fabric to Firebase. In the meantime, we encourage you to try other Firebase products.
We are excited to bring you the best-in class crash reporter in the Firebase console. As always, let us know your thoughts and we look forward to continuing to improve Crashlytics. Happy debugging!
You have questions about Firebase, and the Firebase community has answers!
But do you know the best place to get your questions answered?
It can be kind of overwhelming to figure out which destination is the best for your particular question. What I'd like to explore today are your options, and how to choose the best one. Choosing the best (and knowing how best to ask) could give you a huge advantage in getting the answers you need. There are five leading options, each with a different purpose. Let's explore those options!
Google Search
It might seems silly to say, but I think your question should start with a Google search. A well-constructed search could surface existing answers in some of the forums I'll discuss next. You can't pass up the chance of getting your question answered immediately because someone else asked it first!
Try entering your question directly into the search box. Or, if you have an error message in your code, try copying it in there. For exact error messages, sometimes it's helpful to put your search string in quotes to force the most relevant matches to the top of the results.
Bear in mind that not every search yields good results. In some cases, you might stumble across something so rare that only one other person has ever seen it!
That time I searched for "ERROR: Walrus not found: have you checked the polar ice caps?"
If a search doesn't give what you're looking for, it's time to choose from some other options.
But before we continue - if you end up deciding that your question is appropriate for multiple forums, be sure to state that you've cross-posted your question. That gives everyone a chance to figure out which forum may be the best options, and if the question has already been answered elsewhere. That saves everyone time.
Stack Overflow
Stack Overflow is great for programming questions. In fact, that's the only kind of question you're supposed to ask there. Many Firebase team members pay attention there, including members of the greater community. There are a few tips to making the best of your question on SO:
Learn how to ask a good question. Don't skip reading this! A well-formulated question has a much greater chance of being answered quickly.
Also learn how to format your code and question using the provided editor, so it's easy to read.
Tag your question with firebase, and any other other tags for languages and specific Firebase products.
Not all questions are good for Stack Overflow. In particular, your question may be closed by the community if it's any of the following:
It's seeking recommendations (for off-site products and examples).
It's seeking opinions (e.g. "which is better, X or Y?")
It's too broad, unclear, or doesn't explain the expected behavior of the code.
It's asking for code to be written, without making a good attempt.
It isn't a programming question.
It's a bug report or feature request (see Firebase support below).
If your question is closed by the community, it will almost certainly not be answered. But don't worry: for questions about Firebase that don't follow the Stack Overflow requirements, there are other options!
Quora
Quora is great for general questions, especially those seeking recommendations and opinions. There doesn't have to be a "correct" answer to a question on Quora. It's OK to ask broad questions.
If you choose Quora, be sure to tag your question with the Firebase topic so it's more likely to get noticed by people who have experience with Firebase.
firebase-talk Google group
firebase-talk is a long-standing mailing list for people who are looking for open-ended discussion about all things Firebase. It's great for open-ended discussions that require a lot of text that goes back and forth between group members. Many Firebase team members scan the messages here.
When you post your first message here, be prepared to wait for some time for a moderator to accept it.
The Firebase Slack
The Firebase Slack is where Firebase enthusiasts gather to talk about, well, Firebase! This is good for general chit-chat and gathering opinions. While some Firebase team members check in from time to time, it's not an official support channel. So if you have a question that better fits Stack Overflow or Quora, I think it's better to ask there first.
One notable exception is the Firebase Test Lab team who use the #test-lab channel for direct support.
Here's a couple tips for using the Firebase Slack effectively:
Before you say anything, be sure to search the list of channels. There is likely a channel that's directly relevant to your interests (such as #functions and #firestore).
Following #1, avoid asking your question too quickly in the #general channel. It'll likely get lost among all the other chit-chat happening there and scroll away before people see it. Try to choose a better channel first.
Even though it's a realtime chat, don't expect an immediate response. A lot of us are busy at work and don't have time to respond quickly to messages.
Firebase support
This is a good place to ask for urgent issues such as problems with your production app. It's also good for troubleshooting if you require some back and forth with a real person with a problem that can be reproduced in code. You can expect a response from support within 24 hours of asking your question.
Firebase support also handles bug reports and feature requests. So if you have one of those, please fill out the form in that link.
Where not to ask
If you want a timely response, I would avoid the following destinations for general questions:
Twitter (because there's often not enough space for good replies)
Firebase YouTube videos (when not directly related to the video's content)
The other reason I would avoid these is because they have limited visibility to the world, whereas the destinations above are well known by the Firebase community. You probably want your question to reach the maximum number of people as possible, in order to get answered quickly.
However, we do encourage you to use Twitter and other social media to broadcast the questions you ask on other sites. For example, it's good to ask a question on Stack Overflow or Quora, then tweet the URL of the question with the hashtag #AskFirebase. Your questions may get picked up for use on the Firebase channel on YouTube.
The Firebase community loves to help with Firebase! And it's easier to get help if you follow the guidelines here to make sure your questions reach the correct audience.
Now watch this video with Kato Richardson, who loves our Firebase community!
