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.
Hi, Firebase developers!
In what might be my shortest (but most exciting) blog post this year, we wanted to let you know that Cloud Firestore now has support for not-equal queries. This means you can now query, for example, all documents in a "Projects" collection where the project's status field is not equal to the value "completed"
status
"completed"
On a similar note, Cloud Firestore also supports not-in queries, where you can query for documents where fields are not in a list of values. So you can, for example, find all documents in a "Projects" collection where the status isn't equal to "completed" or "dropped" with a single query.
not-in
"dropped"
Note that neither of these calls will allow you to fetch documents where this field doesn't exist. If a field is completely missing from a document, it will not be returned in your query results.
Notice that project 4593 does not get included in the results, because it has no owner field
When it comes to combining these not-equal operators with others in the same query, they have many of the same restrictions as other inequality operators (<, >=, etc.). You can't use a != operator against two different fields, for instance. Similarly, you can't use a != query on one field and then sort by a second field. And combining a != query in one field with a == query in another field requires your creating a composite index. Make sure to check out the official documentation for all the details.
<
>=
!=
==
This functionality is currently supported by the iOS, Android and Web client libraries, as well as the Node.js and Java server-side SDKs. Support for C++ and other server libraries is coming soon.
We hope this new addition makes it a little easier to develop Cloud Firestore-powered applications, and as always, if you have questions, please feel free to reach out on StackOverflow.
Happy coding!
Getting your internal team to run the most recent pre-release build of your app is critical to receiving feedback on the latest features you’re getting ready to ship. However, testers receive a lot of emails on a daily basis and sometimes miss out on an email notification about a new build. This means your testers might be running old builds and sending you bug reports for an issue that’s already been fixed.
With the App Distribution iOS SDK, open sourced and available today, testers receive in-app alerts when a new build is available. Right from your test app, testers can install the update and quickly start running the latest build.
In-app alert of new release within test app
Like App Distribution, the iOS SDK was built with flexibility top-of-mind, giving you the option to customize the full user experience to make it feel like a natural extension of your app.
We’ve been working with a number of companies over the past few months, incorporating their feedback and understanding how they’re using the App Distribution iOS SDK. Twitter, who had previously used a similar feature with Fabric’s Crashlytics Beta, has integrated the SDK into their nightly builds to make sure testers can easily access the latest update. We sat down with Twitter iOS engineer, Mateusz Dzwonek, to learn more about their experience:
Why did the Twitter Release Team decide to use the Firebase App Distribution iOS SDK?
One of the main goals for our Twitter employee app is to catch bugs before they go to the public Twitter app. We always try to make it as easy as possible for people to install and update this app to the latest version, but it can get out of date pretty quickly with how often we ship new versions. In the past, we relied on sending emails to have our users update the app, which put the burden on the user to always keep up with it. But thanks to the Firebase App Distribution SDK, we were able to simplify the process by showing users if they are on the latest version and allowing them to update from the app instead of having to click on a link in an email.
How did the team use the Firebase App Distribution iOS SDK to improve your testing release process?
Before Firebase, we would check if the user was on the latest version and if not, we’d display a prompt that started an immediate update. We know that most of our users launch the app to complete a specific task, and forcing them to close the app to update it can be frustrating. So one of the most important features we were able to add to our app was a new and improved update mechanism which was possible with the Firebase App Distribution SDK. Now we’ve added an option to install the update when they close the app, and it has reduced the amount of time it takes for the latest version to reach the majority of users by nearly 20%.
Wrap Up
We hope Twitter’s success story highlights the importance of improving your tester’s experience by giving them the flexibility to install your latest pre-release versions right from your test app. We’re excited to hear about how other companies use the App Distribution iOS SDK as part of their internal testing workflow. To get started, check out our docs to set up in-app build alerts. Happy testing!
Keeping your app healthy can be a very time consuming process, even if you’re already using Crashlytics. The bigger your app grows, the more difficult it becomes to keep track of all the crashes your users experience, and which part of your ever growing codebase is causing them. By combining Crashlytics with Google Analytics, all of those previous hurdles become much more manageable, with a supplementary SDK that allows you to reproduce issues and keep track of data with much more granularity. Some of these features include a detailed insight into your crash-free user metrics, the ability to use breadcrumbs to track specific events a user went through before a crash occurred, and the ability to link your apps data to BigQuery to easily visualize your apps key metrics.
Out of the box, Google Analytics keeps count of the number of sessions, and crashes that occur in your Firebase app. This is done through events that the Google Analytics for Firebase SDK tracks automatically--aptly titled “automatically collected events”. By pulling the “session_start” and “app_exception” events, Google Analytics is able to understand when a user session has started and respectively when a crash has occurred. Having those metrics alongside your Crashlytics data gives you a top level view of crashes in your app, as well as the ability to analyze those individual user sessions that led to a crash. This also provides you a dashboard that allows you to quickly notice a dip or a spike in your Crash Free Users, and to check the crash issues right underneath, to figure out what caused it.
Sometimes, you not only need to know where in your code a crash occurred, but exactly what a user was doing in your app before it crashed. As we mentioned earlier, Google Analytics automatically collects several different events in your app, but you also have the ability to log custom events, and custom event parameters. Crashlytics will then add these custom events to individual crash sessions, allowing you to track user sessions with much more granularity. Using these custom event markers alongside Analytics breadcrumbs, you’ll be able to create a trail leading directly to the users crash.
One example you get out of the box is screen view events. This means if you have both Crashlytics and Analytics, you’ll be able to see exactly what screens your user traveled through before they experienced a crash. You can read more about breadcrumbs and Crashlytics here.
Monitoring the stability of your app within your user base is critical for understanding what your areas of focus need to be. This process has been made much simpler with the Latest Release feature. This display will highlight your data once you have both the Google Analytics SDK and Crashlytics SDK integrated, and you will be able to detect crashes in your app’s most recent version, as well as its most popular versions. This view is extremely useful for identifying a prevalent bug that might appear in your app’s latest version that might not present in other versions. Using this tool will allow you to isolate the issue, and solve it much more quickly.
Creating queryable reports on the insights you’ve gathered can be instrumental for your app’s success, among developers and stakeholders alike. Both Crashlytics and Google Analytics offer the ability to export your data into BigQuery and visualize it with Data Studio. You can create complex dashboards that use data from both Analytics and Crashlytics, providing crucial metrics for your business.
By implementing user identifiers or key value pairs into your crash reports, and exporting them alongside your Google Analytics custom events, you can start tying your Crashlytics and Google Analytics data together in order to better understand how stability is affecting your users and your revenue. For example, if you’re a game developer and your users are only getting to the first level of your game before they reach a fatal error, this could be causing a lot of churn. You could figure that out by querying for most pervasive crashes in your app by user ID, and then filtering by your first level custom event.
Picking up on trends such as which crashes are causing your users the most grief in a given week, or figuring out which demographic of users those problematic crashes are affecting, are just a couple of the useful features that exporting your Crashlytic and Google Analytics data to BigQuery will provide you. Here are a handful of useful queries you can try out for yourself!
No party is complete without pizza, and no Firebase Crashlytics integration is complete without Google Analytics. So, whether you’re looking to keep track of your app’s latest version, break down your user data in BigQuery, or just need a robust app development platform, head over to the Firebase console and integrate your app with Crashlytics and Google Analytics!
