Introducing Cloud Firestore: our new document database for apps

Originally posted by Alex Dufetel on the Firebase Blog

firebase_firestore-horiz-dark-2.png

Today we’re excited to launch Cloud Firestore, a fully-managed NoSQL document database for mobile and web app development. It's designed to easily store and sync app data at global scale, and it's now available in beta.

Key features of Cloud Firestore include:

  • Documents and collections with powerful querying

  • iOS, Android, and Web SDKs with offline data access

  • Real-time data synchronization

  • Automatic, multi-region data replication with strong consistency

  • Node, Python, Go, and Java server SDKs

And of course, we've aimed for the simplicity and ease-of-use that is always top priority for Firebase, while still making sure that Cloud Firestore can scale to power even the largest apps.

Optimized for app development

Managing app data is still hard; you have to scale servers, handle intermittent connectivity, and deliver data with low latency.

We’ve optimized Cloud Firestore for app development, so you can focus on delivering value to your users and shipping better apps, faster. Cloud Firestore:

  • Synchronizes data between devices in real-time. Our Android, iOS, and Javascript SDKs sync your app data almost instantly. This makes it incredibly easy to build reactive apps, automatically sync data across devices, and build powerful collaborative features -- and if you don’t need real-time sync, one-time reads are a first-class feature.

  • Uses collections and documents to structure and query data. This data model is familiar and intuitive for many developers. It also allows for expressive queries. Queries scale with the size of your result set, not the size of your data set, so you'll get the same performance fetching 1 result from a set of 100, or 100,000,000.

  • Enables offline data access via a powerful, on-device database. This local database means your app will function smoothly, even when your users lose connectivity. This offline mode is available on Web, iOS and Android.

  • Enables serverless development. Cloud Firestore’s client-side SDKs take care of the complex authentication and networking code you’d normally need to write yourself. Then, on the backend, we provide a powerful set of security rules so you can control access to your data. Security rules let you control which users can access which documents, and let you apply complex validation logic to your data as well. Combined, these features allow your mobile app to connect directly to your database.

  • Integrates with the rest of the Firebase platform. You can easily configure Cloud Functions to run custom code whenever data is written, and our SDKs automatically integrate with Firebase Authentication, to help you get started quickly.

Putting the ‘Cloud’ in Cloud Firestore

As you may have guessed from the name, Cloud Firestore was built in close collaboration with the Google Cloud Platform team.

This means it's a fully managed product, built from the ground up to automatically scale. Cloud Firestore is a multi-region replicated database that ensures once data is committed, it's durable even in the face of unexpected disasters. Not only that, but despite being a distributed database, it's also strongly consistent, removing tricky edge cases to make building apps easier regardless of scale.

It also means that delivering a great server-side experience for backend developers is a top priority. We're launching SDKs for Java, Go, Python, and Node.js today, with more languages coming in the future.

Get started!

Cloud Firestore enters public beta starting today. If you're comfortable using a beta product you should give it a spin on your next project. We can’t wait to see what you build and hear what you think of Cloud Firestore!

7 tips for getting the most out of Crashlytics

By Jason St. Pierre, Product Manager

Crashlytics tips

For many years, developers and app teams have relied on Crashlytics to improve their app stability. By now, you’re probably familiar with the main parts of the Crashlytics UI; perhaps you even glance at crash-free users, crash-free sessions, and the issues list multiple times a day (you wouldn’t be the only one!).

In this post, we want to share 7 pro-tips that will help you get even more value out of Crashlytics, which is now part of the new Fabric dashboard, so you can track, prioritize, and solve issues faster.


1. Speed up your troubleshooting by checking out crash insights

In July, we officially released crash insights out of beta. Crash insights helps you understand your crashes better by giving you more context and clarity on why those crashes occurred. When you see a green lightning bolt appear next to an issue in your issues list, click on it to see potential root causes and troubleshooting resources.


2. Mark resolved issues as “closed” to track regressions

Debugging and troubleshooting crashes is time-consuming, hard work. As developers ourselves, we understand the urge to sign-off and return to more exciting tasks (like building new app features) as soon you resolve a pesky issue - but don’t forget to mark this issue as “closed” in Crashlytics! When you formally close out an issue, you get enhanced visibility into that issue’s lifecycle through regression detection. Regression detection alerts you when a previously closed issue reoccurs in a new app version, which is a signal that something else may be awry and you should pay close attention to it.


3. Close and lock issues you want to ignore and declutter your issue list

As a general rule of thumb, you should close issues so you can monitor regression. However, you can also close and lock issues that you don’t want to be notified about because you’re unlikely to fix or prioritize them. These could be low-impact, obscure bugs or issues that are beyond your control because the problem isn’t in your code. To keep these issues out of view and declutter your Crashlytics charts, you can close and lock them. By taking advantage of this “ignore functionality," you can fine tune your stability page so only critical information that needs action bubbles up to the top.


4. Use wildcard builds as a shortcut for adding build versions manually

Sometimes, you may have multiple builds of the same version. These build versions start with the same number, but the tail end contains a unique identifier (such as 9.12 (123), 9.12 (124), 9.12 (125), etc). If you want to see crashes for all of these versions, don’t manually type them into the search bar. Instead, use a wildcard to group similar versions together much faster. You can do this by simply adding a star (aka. an asterisk) at the end of your version prefix (i.e. 9.12*). For example, if you use APK Splits on Android, a wildcard build will quickly show you crashes for the combined set of builds.


5. Pin your most important builds to keep them front and center

As a developer, you probably deploy a handful of builds each day. As a development team, that number can shoot up to tens or hundreds of builds. The speed and agility with which mobile teams ship is impressive and awesome. But you know what’s not awesome? Wasting time having to comb through your numerous builds to find the one (or two, or three, etc.) that matter the most. That’s why Crashlytics allows you to “pin” key builds so that they appear at the top of your builds list. Pinned builds allow you to find your most important builds faster and keep them front and center, for as long as you need. Plus, this feature makes it easier to collaborate with your teammates on fixing crashes because pinned builds will automatically appear at the top of their builds list too.


6. Pay attention to velocity alerts to stay informed about critical stability issues

Stability issues can pop up anytime - even when you’re away from your workstation. Crashlytics intelligently monitors your builds to check if one issue has caused a statistically significant number of crashes. If so, we’ll let you know if you need to ship a hot fix of your app via a velocity alert. Velocity alerts are proactive alerts that appear right in your crash reporting dashboard when an issue suddenly increases in severity or impact. We’ll send you an email too, but you should also install the Fabric mobile app, which will send you a push notification so you can stay in the loop even on the go. Keep an eye out for velocity alerts and you’ll never miss a critical crash, no matter where you are!


7. Use logs, keys, and non-fatals in the right scenarios

The Crashlytics SDK lets you instrument logs, keys, non-fatals, and custom events, which provide additional information and context on why a crash occurred and what happened leading up to it. However, logs, keys, non-fatals, and custom events are designed to track different things so let’s review the right way to use them.

Logs: You should instrument logs to gather important information about user activity before a crash. This could be user behavior (ex. user went to download screen, clicked on download button) to details about the user’s action (ex. image downloaded, image downloaded from). Basically, logs are breadcrumbs that show you what happened prior to a crash. When a crash occurs, we take the contents of the log and attach it to the crash to help you debug faster. Here are instructions for instrumenting logs for iOS, Android, and Unity apps.

Keys: Keys are key value pairs, which provide a snapshot of information at one point in time. Unlike logs, which record a timeline of activity, keys record the last known value and change over time. Since keys are overwritten, you should use keys for something that you would only want the last known value for. For example, use keys to track the last level a user completed, the last step a user completed in a wizard, what image the user looked at last, and what the last custom settings configuration was. Keys are also helpful in providing a summary or “roll-up” of information. For instance, if your log shows “login, retry, retry, retry” your key would show “retry count: 3.” To set up keys, follow these instructions for iOS, Android, and Unity apps.

Non-fatals: While Crashlytics captures crashes automatically, you can also record non-fatal events. Non-fatal events mean that your app is experiencing an error, but not actually crashing.

For example, a good scenario to log a non-fatal is if your app has deep links, but fails to navigate to them. A broken link isn’t something that will necessarily crash your app, but it’s something you’d want to track so you can fix the link. A bad scenario to log a non-fatal is if an image fails to load in your app due to a network failure because this isn’t actionable or specific.

You should set up non-fatal events for something you want the stack trace for so you can triage and troubleshoot the issue.

If you simply want to count the number of times something happens (and don’t need the stack trace), we’d recommend checking out custom events.

These 7 tips will help you get the most out of Crashlytics. If you have other pro-tips that have helped you improve your app stability with Crashlytics, tweet them at us! We can’t wait to learn more about how you use Crashlytics.
 

Faster automated screenshots: fastlane’s snapshot now supports multiple concurrent simulators

by David Ohayon, Software Engineer

fastlane-snapshot-header.png

Every mobile developer needs to take app screenshots in order to have their app listed on the app stores. Like a book cover, screenshots are crucial in depicting the best parts of your app and convincing potential users to download it.

Unfortunately, generating app screenshots is a huge pain because they take a ton of time, especially if your app supports different locales and languages. For example, if you need to take 5 screenshots for your app store listing - but your app supports 20 languages for 6 devices - you’ll manually have to take 600 screenshots (5 x 20 x 6)! It makes us shudder to think how many precious hours that would eat up.

fastlane’s snapshot tool automates the process of taking screenshots (in the background) so you can focus on building features users love. Today, we’re excited to share that snapshot now supports multiple, concurrent simulators for iOS apps in Xcode 9. Taking screenshots just got even faster because you can now generate screenshots for all of your devices at the same time!

Speeding up screenshots (even more!)

Before Xcode 9, only one simulator could be running at a time, which means that you had to run snapshot once for each device you wish to support. While snapshot automated the process of taking screenshots, we wanted to make things even easier.

The launch of Xcode 9 gave us another opportunity to improve snapshot. In Xcode 9, multiple UI tests can run simultaneously, so we added multiple simulator support to snapshot as well. Now, you can take screenshots for all specified devices with a single command, at the same time. This drastically shortens the time it takes to generate your screenshots.

Here's an example:

fastlane-snapshot-comparison.png

More exciting updates on the way

fastlane’s mission is to save you time by automating the cumbersome tasks of app deployment, even as mobile evolves. That’s why we’re fully committed to updating the fastlane toolset to take advantage of new releases and features - such as Xcode 9.

And since fastlane is open source, we’re so thankful that our community also helps us make fastlane better by building and using plugins. In fact, we now have more user-generated plugins available for you to try than native fastlane actions. We recently reorganized these plugins to make it easier to find the right plugins for your unique needs.

We always strive to anticipate your needs and build our tools to be ready for the future. To start using the new version of snapshot, simply update fastlane and run snapshot as you normally would. If you’re taking screenshots manually, check out our guide to start using snapshot (and enjoy the extra free time!). As always, we can’t wait to hear what you think!

Learn from app makers: How Levi Bostian used Fabric & fastlane to scale

By Todd Burner, Developer Advocate

Learn from app makers

In this series, we feature customers that have used our platform in an innovative way. For this installment, we chatted with freelancer and indie app developer Levi Bostian, who uses Fabric and fastlane to scale his one-person development shop.

Levi Bostian is a native Android and iOS app developer from Cedar Rapids, Iowa, who spends his days building apps for a rotating set of external clients. As a one-man app development shop, he needs to set-up a streamlined development process so he can focus his attention on client work without being bogged down with tedious tasks. But since Levi is extremely busy running his business, he doesn’t have much time to learn complicated new tools. Let’s learn more about Levi, his work, and his experience streamlining his development process.

Levi's workstation

Levi's workstation

What types of apps do you work on?

"I am a freelancer building native Android and iOS apps with Node.js APIs for startups. I’m also an indie developer building my own apps like Your Circle, a virtual support group app for cancer patients. In the past, I have built social media, mobile banking, beauty, manufacturing, and music streaming apps as well as apps that connect to Arduinos. I have also worked with Google, Salesforce, Jack Henry and Associates, and a dozen startups on their apps. I love the variety of apps I get to work on."

What challenges have you run into as a freelance developer?

"Because I work with external clients, I distribute a lot of builds for many separate apps. My biggest pain point has been distributing beta apps as I make incremental changes and add testers. Every time I need to beta test a new build, I have to update the provisioning profile, update beta testing devices, build and sign the app and then distribute it - which is a lot of steps. This gets repetitive and is very error prone especially since I don’t have access to the users’ devices for troubleshooting. I need to get everything right the first time."


Finding fastlane

Levi was looking for a way to automate the distribution of these daily beta builds to each of his clients. For a while, he tried to script the signing and distribution steps on his own, but it required too much maintenance to keep up and running. After talking to some friends, he learned about fastlane. fastlane is an open source toolset that automates app deployment. In other words, it does the heavy lifting of streamlining code signing, distribution, and more. While Levi was already using Fabric to distribute beta builds and monitor app stability, he decided to try using fastlane to speed up distribution of his native Android and iOS apps to his external customers.

When did you first start using fastlane?

“I was using Crashlytics Beta, which is part of the Fabric platform, for my Android and iOS beta testing because  it makes adding new testers and managing versions very easy. I had been manually uploading builds using the Fabric plugin, but with my business growing, I also needed a way to automate the build, signing and deployment process. It was getting really hard to manage all of the provisioning profiles and devices registered to each app.

After many headaches with code signing, I decided I was going to get fastlane setup and I did.  Whoa! It handles the code signing and building steps and also lets me automate the submission of the beta app after those are done. It saves me tons of time, which I can now use to focus on building apps! I’m so glad I picked it up!”

What was your initial reaction and experience?

“I was blown away by how easy it was to get up and running. The documentation on GitHub is very thorough and you can generate everything you need on the Fabric site. The first time I ran 'fastlane run crashlytics' it distributed my app with a few simple inputs. That’s when I knew I had found something great!"


Growing & scaling with fastlane

Now that Levi has used fastlane in more than 10 shipped projects, he's uncovered new, creative ways to use our toolset to scale his business and make working with external clients easier.

Now that you’ve been using fastlane for 8 months, how has it impacted your development process?

“It’s been saving me so much time. I’ve been able to take on more work and do more side projects. I love it! And in addition to distributing my beta apps, I’ve been gradually adopting other fastlane tools too.

For example, I just started using match. Match saves me the headache of creating and syncing a huge amount of provisioning profiles. I really dislike dealing with those manually and using match in fastlane to manage all your apps, devices, certs, profiles all via a git repo is magic. I want to give fastlane a big kiss for all it does for me there.

I’m also delighted by how I can configure fastlane to be a hands free build system. I have my iOS and Android Fastfiles setup with parameters so that when I run a fastlane action, it doesn't require any work on my end. It just runs in the background and does all the hard work for me. I can spend my time working on features instead!”

Did anything else about fastlane surprise you?

“The amount of Android support. Initially, my friend told me it was just for iOS but after poking around, I realized I can do so many things with it in Android too! Outside of distributing betas, I’m able to manage Play Store metadata and APK uploads and I even use it to run gradle tasks. I use it for complex tasks, such as building versions of my app via gradle and releasing those builds to Crashlytics, as well as simple tasks, such as running gradle clean. It’s much easier to type "fastlane install" rather than "./gradlew installDevelopmentDebug."

What resources do you use to get help with fastlane?

“There is a very active GitHub community for support and bugs. I’ve thought about contributing code to the project as well, but fastlane has everything that I need at the moment. When the time comes, I will make sure to do so - and I would be happy to be a part of it. The product is so rock solid and it would be an honor to help out.”


Looking forward

By using fastlane and Fabric together, Levi has been able to successfully scale his business without needing to hire additional help. He’s quickly become a power user of fastlane and wants to explore the many more fastlane tools.

How has your use of Fabric & fastlane evolved over time?

“I started by only using Fabric to distribute beta builds, then added fastlane into the mix. Now, I’ve been gradually adding a bunch of other fastlane tools to my flow. I use match for iOS and the gradle action heavily for Android.

Today, all projects that I build (or apps that I make some updates to) I install fastlane right away. I distribute 5 - 8 beta releases a week for both (Android and iOS) apps. By using fastlane in conjunction with Crashlytics Beta, I have way fewer headaches because I have the fastfile fully configured to ask for no input. One command and within 3 - 8 minutes a build is out to my client.

One of my products I mentioned earlier, Your Circle, is a white labeled app. All of its builds share the same code base with nice theming added to each. I have fastlane setup so that I can build and release updates to all of the white labeled apps with 1 command. Plus, I use fastlane to generate all of the separate icons for each white labeled app target. So awesome! All commands, certificates, list of devices, synced via Git with the project. I have no idea what I would have done if I didn’t have fastlane to distribute this app.

Your Circle app

Your Circle app

Since adding fastlane into my workflow, my client relationships have greatly improved because I’m able to sync everything I need into my git repo so that it’s contained in the project. This helps me keep track of my code and metadata in the same place, makes it easier to communicate updates to clients, and speeds up releases.”

Are you thinking about trying any other fastlane tools?

“Taking screenshots for the app stores is something I hope to try soon. I plan to set up fastlane up to a CI so it can automatically take screenshots for me in the background and make it a hands-off process. I’m excited about the potential there.”

What advice would you give to new fastlane users?

“Come into fastlane with an idea of what you want the toolset to do for you. Do not get overwhelmed by the dozens of plugins and actions it provides, come in with a game plan. If that is to sync your provisioning profiles with your team, start there. It's easy to add to your configuration at any time, but just start with one problem to solve and get to it.”
 

Join us at the Firebase Dev Summit 2017 in Amsterdam!

By Frank van Puffelen, Developer Advocate

We’re excited to announce that the registration for the Firebase Dev Summit is opening today!

Please join us in Amsterdam on October 31st for a day of talks, codelabs, and office hours, as well as (of course) an after-party.

I had a blast at last year’s Dev Summit in Berlin

I had a blast at last year’s Dev Summit in Berlin

Three months ago, thousands of developers joined us at Google I/O to hear about improvements to the Firebase platform, like Performance Monitoring, Phone Authentication, and our newly open sourced SDKs. We haven’t slowed down since then and now we’re excited to bring the Firebase and Fabric teams to Amsterdam to talk about a bunch of new announcements, as well as hear your feedback on how we can improve Firebase to help you build even more extraordinary experiences for your users.

Registration is now open, but keep in mind that space will be filled on a first-come, first-serve basis, so make sure to request an invitation today.


What is the Firebase Dev Summit?

The Firebase Dev Summit is full day event for app developers that will focus on solving core infrastructure and growth challenges in app development. We’ll have deep dive sessions, as well as introductory overviews, so all levels of Firebase familiarity are welcome!

We also want you to get your hands dirty with Firebase. You’ll get a chance to put your new knowledge into practice with instructor-led codelabs, as well as ask our team any questions you have at our #AskFirebase lounge.

The day isn’t just about us talking to to you, though. Our product managers and engineering team (including me!) are excited to meet you in person and hear your feedback about what is and isn’t working in Firebase. Our community is what makes Firebase great, so we couldn’t be more excited to get your help in shaping the future of Firebase.

As a native Dutchie, I’m thrilled that we’ll be combining two of my favorite things at the Dev Summit this year: Firebase & The Netherlands! If you’ll be traveling to Amsterdam for the conference, I highly recommend you stay an extra day. Take a canal tour, visit one of the many museums, rent a bike, or just take a stroll and say hi to a local. We’re friendly, I promise :-).

We’re looking forward to meeting you in person. Dank je en tot gauw!


This post originally appeared on the Firebase blog.