From Crashlytics Labs: Unity and tvOS Support, Logged Errors for iOS

Last month, we improved our crash reporting service with enhanced visibility into the life cycle of an issue. Even though Crashlytics is already recognized as the #1 most implemented performance SDK, we knew there was more to do. Many app developers face challenges such as getting deep, actionable crash reports for their games, or gaining visibility into the stability issues that don’t always result in a crash.

Through Crashlytics Labs, we’re always tinkering with new ideas. Today, we’re announcing three new tools in beta: support for Unity, one of the most popular game development engines; support for tvOS; and the ability to log NSErrors on iOS, OS X and tvOS.

The onboarding process for Unity-based projects has traditionally been cumbersome. Our beta support for Unity aims to give you a completely streamlined onboarding experience. Right out of the box, our beta will support both Unity 4 and 5; you’ll no longer have to use your Mac app or Android IDE plugins to start building.

From our friends at Dots, Androidsx and Nordeus:

With Fabric, the idea of one SDK that will not take long to implement but give us a broad reach in terms of capabilities in Unity, is a huge offering.

- Chris Deaner, Director of Engineering,

The onboarding is brilliant, simple and fast.

- Pau Rodriguez, Software Engineer,

Having added a lot of plugins so far, I have to say that this was by far the easiest integration.

- Miša Damjanić, Game Designer,

We also knew that the developer community is excited to build tvOS apps that will live on Apple TV. Because of this, Crashlytics now supports crashes that come from those apps on Apple TVs. Available through Crashlytics Labs, you can now test out our tvOS app support in beta.

Beyond actionable insights into errors when an app or game crashes, we saw another need from many those who want visibility into NSErrors. Just because an app didn’t crash doesn’t necessarily mean that the user had a flawless experience, and our beta support for logging errors aims to help you solve that. Not all serious stability issues are crashes, and knowing about other non-fatal errors can help monitor and address problems before they become more serious, or uncover issues that might be due to a server/back end problem, etc. Starting in beta on iOS, OS X and tvOS, we plan to make NSErrors accessible so you have a way to optimize user experience even when your app isn’t crashing.

If you want to apply to test our new tools and other secret projects we’re working on, sign up here.


Crashlytics #1 in Performance, Answers #1 in Mobile Analytics

Just a few months ago, Crashlytics was named the #1 most implemented performance SDK by SourceDNA, the world's largest database of mobile app intelligence. Not only was it the most implemented, it was more than #2-6 combined! At the same time, Answers, the mobile analytics tool we built just over a year ago, was named #2 on iOS and #3 on Android.

Today, we’re thrilled to share that according to SourceDNA’s newest report, Answers is now the #1 most implemented mobile analytics SDK on iOS — just five months after it was named #2!

Here’s what SourceDNA said about Answers and Crashlytics just a few months ago:

Twitter’s efforts in the mobile ecosystem are clearly paying off. Their tools are some of the most implemented in apps that we’re seeing. It’s a clear sign that they are really making an impact and leading the way with mobile.


Since founding Crashlytics, our passion has always been to build developer tools that you love. With both Crashlytics and Answers being #1 in their space, we’re humbled, thrilled and ecstatic with the positive reaction for everything we’ve built. Even though we’ve received this recognition, we don’t plan to be complacent. We look forward to continuing our mission of building the best services for every developer in the world.


(If you haven’t yet, see the inside story of how a team of six of us built Answers to be the most popular mobile analytics tool today.)

Crashlytics September Update

Now that fall is here and school’s back in session, we’re studying up on how to make your lives even easier with more enhancements. In September, we shipped a new dSYM upload page and a more detailed user experience for Beta to support iOS 9 and its latest changes.

Seamlessly Drag and Drop dSYMs

This month, we enhanced our settings and user controls on your dashboard. For your iOS apps, there are scenarios that might result in you having a few missing dSYMs, one being if you’ve recently enabled Bitcode. But don’t worry — if your latest build is missing dSYMs, we’ll let you know right away via notification on your dashboard. Simply go to your settings page and drag & drop your dSYMs onto your dashboard. We’ll automatically start processing your crashes against the latest files.

We’ll even show you the most impactful missing ones, prioritizing the list in order for you.

iOS 9 Support for Beta Distribution

Since the release of iOS 9, we’ve been rolling out new updates to support it. iOS 9 changed the install steps for end users, so we updated our device tutorials to show users exactly the required steps are. For your beta testers who are now on iOS 9, we added the functionality to help them automatically download the newly required certificate to enable your beta build on their phones — all right within your tester onboarding flow.

Brand New Integrations

Building great apps takes teamwork and collaboration. This month, we’re excited to release two more integrations to help you further strengthen collaboration. Our first one is with Moxtra, which seamlessly synchronizes everything relevant to your team into a collaborative workspace that can be embedded into any app. With this integration submitted by Raj Sen Sharma, your crash reports and real-time alerts can now be funneled directly into your preferred binder. The second is Chatwork, a collaboration tool that connects individuals and teams of all sizes. With the ChatWork integration, you can now seamlessly send crash reports and other important data as notifications to your team.

Here’s our internal changelog:

Mac App

  • Enhanced settings tab to allow users to be able to upload dSYMs and check to see if the most recent build has a dSYM present

Android SDK

  • Fixed a minor id collection issue that occurred when customers ProGuard their apps


  • Added Bitcode support

  • Dropped support for iOS 5

  • Enhanced stack unwinding for i386 and x86_64 functions that do not create a stack frame

  • Enhanced support for functions that require evaluating DWARF expressions to unwind correctly

  • Fixed a bug that would prevent DWARF unwinding from working correctly on ARM64

  • An OS X AppKit exception-handling check is now performed even if debugMode is disabled

  • Provided a workaround for a header-related issue with Swift debugging

  • Adopted Objective-C generics, when supported

  • Removed some unnecessary code in our one C++ static initializer

Major Upgrade: Making Issues Even More Actionable

Having deep, actionable data as a developer is the key to building great apps. This is something we’ve kept in mind ever since we embarked on solving crash reporting. The real power of a crash reporting service is to distill mountains of information, organize crashes into groups and prioritize these crashes by impact. In Crashlytics, we already surface the most prevalent issues for you — but we didn’t stop there.

Today, we’re taking crash reporting to the next level by giving you enhanced visibility into an issue’s lifecycle. Now, you’ll be able to better manage your view into issues across versions from the first version that the crash occurred to the most recent version we see it causing a problem. We’ll even tell you if and when the same problem regressed along the way.

Optimal organization of your data

Previously, new issues were scoped to a particular version. Now, your dashboard will automatically merge the data about an issue occurring across versions so you can see that issue in a single row along with the range of versions it affects.                                                                                                    

With this upgrade, and with minimal effort, you’ll have an even deeper understanding of the impact of these issues. You can still filter by a particular version to see how that version is impacted, and when you filter to just one version on the dashboard, we’ll let you know if an issue is also occurring on the other versions.

Total visibility into an issue’s life cycle

Within a crash report, you now have a pristine visual representation of the lifecycle of a specific bug or issue across all versions. You’ll be able to see all of the versions a particular crash is occurring on, which gives you a complete picture of how an issue is affecting your builds. If you need to identify the most affected version, or get a breakdown on the number of crashes by build, your new dashboard has you covered.

By being able to access the impact of bugs and issues across multiple versions, you can fully understand the lifecycle of your app’s bugs or issues. You can see how long an issue has been persistent and its severity to focus on those that matter most, and ship the most important updates.

More powerful: Regression detection & issue ignore functionality

With cross version issue support we also added two new features: regression detection and the ability to ignore issues. Regression detection alerts you when you close an issue, and the same issue appears on a new version later. Don’t worry -- we’ll notify you when an issue creeps back up after you’ve closed it as these regressions are usually warning signs you'll want to pay close attention to.

Sometimes there are things that aren’t regressions, they are just issues you know are going to occur. You may choose not to fix them because they aren’t issues in your code. Now, you can lock and ignore issues that you know will be present for many versions. By having this added control, you can now further fine tune your dashboard to bubble up the true, critical information that needs your immediate action.

Enhanced Answers integration

Besides managing issues, the team at Answers upgraded our integration to allow you to see crash-free users and sessions by versions on your Answers dashboard. Now, you can dive into each build and see the crashes affecting its stability. Learn more about this upgrade in Answers’ August update.

We couldn’t be happier to get these upgrades into your hands and help you to continue to build awesome apps. Log in to check out the new issues dashboard, or sign up if you don’t have Crashlytics yet!

Launching Pinned Builds for Crashlytics

Over the last few months we’ve continued to build out new tools, like NDK support, tester profiles and others, to make your life easier. Since then, we’ve been heads down testing out more tools to make your dashboard even more powerful for you. Today, we’re pumped to release pinned builds, a new feature that makes it easier for you and your team to quickly find the builds that matter to you.

Your most important builds. One click away.

Generally, you have a few builds you care most about. Maybe a few recent ones in production, beta builds and the nightly train. You also have builds that aren’t as important, that might take time to wade through to get to the ones you’re looking for. With our new pinned builds functionality, you can now find the builds you care most about more easily than ever.

Simply “pin” the builds you care most about, and they’ll appear at the top of your dashboard, keeping the most important information front and center. Besides  giving you immediate access, we automatically surface pinned builds to the top of your teammates’ dashboards so it’s even easier to collaborate on fixing crashes. This is especially helpful when you have a large team with hundreds of builds and millions of users.

We have hundreds of builds that we manage on both iOS and Android, so being able to quickly pin and find the ones that matter most is huge for us. Whether they are beta builds, nightly builds or ones in production, being able to manage those better will let us move faster as a team, and make impactful product decisions to benefit our customers much quicker.

- Greg Calvert, Director, Video Product Management

Pinned builds is live today, so you can start using it now on your dashboard. We can’t wait to hear what you think!

We also shipped a bunch of other enhancements in August. Here’s our internal changelog:

Mac App

  • Made enhancements that add support for Xcode 7 beta as well as the ability to automatically find the latest and greatest version of Xcode to help read dSYMs going forward

  • Fixed a couple of bugs to improve the stability of dSYM uploading


  • Crashlytics Core

    • Added more detail to "isCrash" property comment

    • Improved the accuracy around crash report detection

    • Renamed the property "apiKey" to "APIKey" in Crashlytics.h

Android SDK

  • Crashlytics Core

    • Fixed an issue that would cause logs written during app startup to not be submitted with crash reports

  • Crashlytics NDK

    • Fixed an issue that would cause native keys/logs to fail when called off the main thread


  • Shipped the ability to pin builds on your dashboard

Crashlytics July Update

With summer in full swing, our team turned up the heat this month shipping new features and performance upgrades under the hood that will help you build the best apps even faster.

Making NDK builds run faster

Just a few months ago, we released our official support for Android NDK crash reporting. In addition to bringing the best of our Java-based Android crash reporting to native code, we’ve made enabling NDK support completely seamless with just a few lines of code. But we didn’t stop there. In July, we made our symbol generation process even more efficient which allows us to dramatically reduce the time to build. Now sit back, relax and watch your native crash reports roll in!

Fine-tuning performance and stability

In July, we were heads down making improvements to our iOS SDK, bringing enhanced reporting stability and speed to your iOS apps. First, we made significant improvements to logging performance that increased speeds dramatically. Next, we quickly identified and worked around an early iOS 9 bug and, while we were in there, we made improvements to increase our defensiveness around reading binary image metadata.

We’re working on much bigger upgrades and enhancements, so stay tuned for more in the coming weeks!

Here’s our internal changelog:

Mac App

  • Added CocoaPods support as a way to manage Fabric dependencies


  • Increased logging speed by improving performance of CLSLog and CLSNSLog

  • Fixed issue with extra LLVM internal symbol in static library causing duplicate symbol errors when linked alongside other code or libraries built with Bitcode enabled

  • Improved resiliency in crash reporting by increasing defensiveness when reading memory during unwind operations

  • Fixed an issue where calling std::terminate directly would result in a crash

Android SDK

  • Made NDK builds run faster by making symbol generation more efficient

Crashlytics June Update

We can’t help much if you missed the summer solstice in June, but now that it’s summer, we do have a slew of upgrades to share. In June, we were heads down shipping new features to Beta to take tester management to a whole new level, along with integrating another popular project management/bug tracking tool.

Visibility into testers: completely streamlined

When we launched Beta by Crashlytics last May, our vision was to build the most seamless beta distribution experience for both developers and testers. Along the way, your continued feedback has been extremely valuable. We’ve added groups support, the ability to share links as the most convenient way to onboard testers to your builds, and crash-to-tester Identification. And in June, we wanted to make tester management even simpler.

Many folks have requested a new feature to provide a comprehensive view into your individual testers and their activity. Based on the overwhelming demand, we’re excited to release tester profiles today!

With tester profiles, you’ll be presented with an intuitive card, which allows you to see your testers’ most recent activity, how long they’ve been a tester and their activity on all builds — centralizing your tester management dashboard. On top of that, managing your testers has never been easier. From revoking access to certain builds to renaming groups and deleting profiles — it’s at your fingertips.

To help seamlessly track down tester activity for a particular build, your tester profiles include all of the builds your testers are active in and other important information, such as how they’re contributing to the feedback cycle of your app.

Instantly locate your latest build

We’ve also heard you need an easier way to manage your builds in Beta. For example, if you know your latest release in the App Store was version 1.2.2, you now have an easy way to find that exact build. Maybe you want to follow up on a particular build where you fixed that tricky bug that was causing major headaches for testers? Now you can easily navigate to find the answer you’re looking for — on both iOS and Android.

Brand new integration

Since you’re constantly multitasking, we know you're relying on Red Bull and project management/bug tracking tools like Zoho Projects to manage and prioritize your crashes.

Our new integration, built by the Zoho Projects engineering team, enables you to automatically generate issues within their service from crashes reported by Crashlytics. Now, you can stay on top of the most prevalent crashes and spend more time on the fun stuff, like coding the next hottest app :)

Here’s our internal changelog:

Crash Reporting


  • Crashlytics SDK

    • Added a workaround for an iOS 9 bug that prevented us from correctly capturing loaded libraries
    • Improved performance of custom key-value and logging
    • Optimized use of file protection API resulting in improved launch and logging performance
    • Fixed a race condition around launch failure detection that could result in a crash in the CLSFileManager class
    • Fixed a linker bug that could prevent catch or @catch from working correctly
    • Custom keys will now be removed if the value is set to nil
    • Addressed a launch performance regression that could cause the main thread to be blocked on a slow background operation
    • Fixed an issue that would incorrectly default to enabling NSURLSession background uploads in extensions
    • Adjusted the wording of logging messages around background uploads to be more clear
    • Fixed a bug that could prevent one of our memory corruption defenses from being enabled
    • Improved initialization to ensure the singleton sharedInstance is returned by all initialization patterns in Swift   


  • Crashlytics SDK

    • Removed deprecation annotations for static Crashlytics API. Originally we deprecated this in favor of a more testable API, but we heard your feedback that it was still useful, so we've reinstated it as a convenience :)
  • Crashlytics Core

    • Added support for NDK custom keys, user and logs metadata.

  • Crashlytics NDK

    • Fixed bug causing incorrect thread names to be written to NDK threads in rare cases.
    • Added C++ Crashlytics API header.
    • Fixed issue causing NDK crash reports to fail to be processed with a JSON exception in the logs. 

Beta Distribution


  • Added the ability to search for previous builds


  • Deferred app launch reporting until an Activity is shown on API >=14
  • Added the ability to search for previous builds


  • Shipped new tester profile UI



Crashlytics May Update

Between the world buzzing about the fight of the century and sipping margaritas on Cinco de Mayo, we were still heads down in May shipping a slew of new features and upgrades. From SDK v3.0 to NDK support, we were excited to share these upgrades with both the iOS and Android communities ahead of Google I/O and WWDC!

Crashlytics SDK 3.0: Taking reliability to a whole new level

Since starting Crashlytics, we've seen billions of crashes, and have learned that it’s impossible for developers to address every crashing scenario users will face. This is why we aim to give you deep, actionable insights into the most prevalent crashes with minimal effort on your part.

But that’s only the beginning: In May, we released SDK 3.0 for iOS and OS XWith SDK 3.0, we've taken all we’ve learned in the past few years and implemented numerous upgrades to make sure we can reliably get crash reports to you -- even in the most precarious usage situations. See how we did it in our full blog post for all the technical nitty-gritty :)

Finally, NDK crash reporting that just works

In May, Crashlytics was recognized as the #1 crash reporting SDK by SourceDNA, the largest mobile app intelligence firm in the world. We were humbled by this recognition, but there’s more to do to make Crashlytics work even better for you. Since we released Crashlytics for Android, we’ve heard that not only do you want deep, actionable reports to fix the most prevalent crashes within the Android NDK; you want something that just works, with no headaches.

That’s why we were excited to release our official support for NDK crash reporting in May. Just as with Crashlytics for Android, it’s great to bring the best of our Java-based Android crash reporting to native code. We’ve made enabling our NDK support completely seamless with just a few lines of code. To protect your app’s secret sauce, our build tools will generate the needed symbols for you – completely client side – before uploading them to our servers.

See the full announcement on how to get started with our NDK support.


Here’s our internal changelog:


  • Improved initialization to ensure the singleton sharedInstance is returned by all initialization patterns in Swift.

  • Addressed a launch performance regression that could cause the main thread to be blocked on a slow background operation.

  • Increased speed dramatically on that background operation.

  • Fixed an issue that would incorrectly default to enabling NSURLSession background uploads in extensions.

  • Adjusted the wording of logging messages around background uploads for maximum clarity.

  • Fixed a bug that could prevent one of our memory corruption defenses from being enabled.

Android SDK

  • Implemented ability to detect and symbolicate crashes in C++

  • Shipped client-side symbol auto-generation functionality

  • Improved retry logic during degraded network connectivity

Android Build Tool Support

  • Implemented NDK support installation and symbols upload functionality on Gradle

  • Implemented NDK support installation with command-line app onboarding and symbol upload functionality on Ant


  • Added support to display native crashes in the crash reporting dashboard

Beta Distribution

  • Shipped the ability to search for builds on the tester side on iOS

  • Made performance and bug fixes to the Beta Air app on Android


The Wait is Over: Launching Crashlytics for Android NDK

When we launched Crashlytics for Android two years ago, we took on a challenge: fixing crashes within Android apps. Just recently, Crashlytics was named the top performance tool on Android by SourceDNA, the largest mobile app intelligence firm in the world. But we continued to listen to your feedback on what could be better. Your response: NDK support.

Since then, we’ve been heads down building out our NDK support in Labs. We’ve listened to your feedback and understood that getting insightful crash reports for NDK code is hard. You not only wanted deep, actionable reports to fix the most prevalent native crashes, but also something that would just work without a headache.

Today, we’re excited to announce our official support for NDK crash reporting!

Most powerful, yet lightweight

We’ve brought the best of our Java-based Android crash reporting to native code. We perform a deep analysis of each stack trace to identify the most important frames so you can see the exact line of code that caused the crash and quickly address the issue.

You’ll have access to the same deep information like devices, hardware, versions.  And now, you’ll spend less time finding and more time fixing your native crashes.

First-in-class installation

The last thing you want is a cumbersome setup or complex configuration just to get crash reporting for your NDK code. Before today, NDK crash reporting involved numerous steps: adding external files, jumping through repos, manually provisioning keys, etc. We’ve built our NDK support to be the opposite: it’s seamless and it’s intelligent.

If you’re already using Crashlytics, you won’t have to download any new plugins or build tools. Simply add a few lines of code within your Gradle or Ant-based project, and we'll do the rest. We’ll even pull in all the dependencies you need automatically.

Not building from a standard IDE? No worries. We'll auto-provision your keys and onboard your app from the command line, just as we do with our plugins. Now sit back and focus on the fun stuff, like coding the next killer app!

Don’t worry, your code is safe

Today, many crash reporting tools for NDK still rely on you uploading your unstripped binaries to generate symbol files server-side. This poses significant risk for your code, sending your secret sauce to third parties, not to mention wasting bandwidth by transmitting your full executable.

With Crashlytics NDK support, our build tools generate the needed symbols – completely client side – before uploading them to our servers. You’ll have total control over the upload process, and our symbol upload file is a fraction of the normal size, saving you tons of bandwidth.

Experience the power

Our official support for NDK is already trusted by many top apps in the Android Play Store:

We use Crashlytics daily to improve the quality in our apps: Path, Path Talk and Kong. NDK support by Crashlytics is one of the best tools on the market to find native errors which are not reported by any other tools.

- Dario Marcato,

A critical portion of the Rdio app relies on NDK. Thanks to Crashlytics, we now trust that we have the best tool on the market to monitor it properly.

- Sean Smith,

Integrating NDK Fabric support only took a few minutes and the payoff was huge! Now we can see exactly where we’re having crashes in our native code by function and line number.

- Dallin Dyer,


We’ll be rolling out NDK support over the next few days. Once you have access, you'll see a toggle at the top of our instructions page for Gradle and Ant. Simply toggle the button to the right to see how you can enable NDK support within your projects.


If you're already using Crashlytics, be sure to upgrade to the latest Crashlytics Kit on Fabric. If you're already on Fabric and you needed NDK support yesterday, give us a shout and we’ll try to get you into to our next batch! 

We can’t wait for you to try it and hear what you think we should tackle next :) 




Just in: Crashlytics #1 in Performance, Answers #2 in Mobile Analytics

When Jeff and I started Crashlytics back in 2011, we were on a mission to help developers build the best apps. Since every app crashes, we started with crash reporting and then built other services like Beta by Crashlytics, our easy and fun beta distribution tool, and Answers, our focused, real-time approach to mobile analytics.

Four years later, Crashlytics has seen over 1 million apps integrate its crash reporting SDK, and it was recently named the most implemented performance SDK by SourceDNA. Not only is it the most implemented - we’re more than #2-6 combined! We’re extremely grateful for all your support as we continue to build the best in mobile crash reporting.


Not just Crashlytics, Answers too

We launched Answers last summer, and 10 months later we’re proud to announce that SourceDNA has also reported that Answers ranks as #2 on iOS and #3 on Android in the mobile analytics space.

From SourceDNA:

Twitter’s efforts in the mobile ecosystem are clearly paying off. Their tools are some of the most implemented in apps that we’re seeing. It’s a clear sign that they are really making an impact and leading the way with mobile.


We’re humbled, thrilled, and ecstatic with the positive reaction for both Crashlytics and Answers. We look forward to continuing our mission of building services that you love.

Kick off WWDC with Crashlytics + Twitter

For three years, we’ve hosted a party during WWDC to celebrate with the mobile developer community. And this year’s no different: we’re bringing back the party you won’t want to miss. Join us at 1015 Folsom to hang out with top iOS developers and other Apple aficionados as we celebrate another year of all of you who are building amazing apps.

Now that Crashlytics is part of Fabric, we need a bigger stage to dance on. That’s why we’re celebrating with a Fabric party; it’s the same great memorable event as last year, just with a new look.

We can’t wait to celebrate with you and hear all about what you’re building!

Want to crash our party?

  • When: June 8, 2015

  • Time: 8:00 - 11:00 p.m.

  • Where: 1015 Folsom, San Francisco

  • Cost: It’s on us!

(act quickly -- tickets are limited!)

To get excited for the big night, check out the highlights from last year!

Announcing SDK 3.0: Taking reliability to a whole new level

In-process crash reporting is a highly complex problem. All kinds of reasonable assumptions about your environment can break down when you are running code after a process has already failed. It's incredibly perilous, but can also make for some pretty fun challenges. Can you be defensive enough to survive failure and corruption – and still produce a useful report? This is what we really obsess about, and our latest release, Crashlytics 3.0 for iOS and OS X, takes crash reporting reliability to a whole new level.

Implementing effective defenses against memory corruption

The most common cause of report failures by far is memory corruption of some kind. With the 2.0 release, we began using the mprotect API to guard our SDK’s data structures. We used read-only pages where we could, and guard pages to help protect the writeable areas. This worked out fantastically, and produced a huge improvement in reliability.

Since then, we’ve continued to analyze the remaining sources of corruption, and with 3.0, we've gone even further, using specialized on-disk structures to further minimize our exposed memory. This means the next time some code stomps all over your memory, we're even more likely to get you an accurate report.

Reporting exceptions in your OS X apps

Exceptions have a long and complex history on OS X. This is particularly evident in the differences between how UIKit and AppKit interact with and approach exceptions. By default, exceptions can be very problematic for an AppKit app. Under many circumstances, they are caught by the framework itself. Not only does this prevent a crash report from being generated, it can also result in serious damage to the running process. This is due to the general exception-unsafety of Cocoa. While we cannot fix those issues, we can integrate more closely with AppKit. Now, we're far more likely to be able to produce useful crash reports for exceptions on OS X.

Background uploads

We’re also excited to announce that we’ve adopted NSURLSession’s background capabilities. Where available, SDK 3.0 makes use of background uploads for report submission. This is a huge reliability win, particularly for apps that tend to have short user session durations. As a side effect, we also benefit from the OS’s ability to efficiently schedule networking operations. This means a report that might have gone over a power-hungry cellular connection can now wait until Wifi is available. This can translate into reduced power requirements for crash reporting.

Ship with more confidence

We know how shipping goes. You're huddled over the Answers dashboard, waiting for that new version to start ramping up. This is the best part of shipping, and also where stability problems spoil all the fun. That is why we try so hard to build reliability into everything we do. We want to give you the ultimate confidence in your app's stability, so you can get back to enjoying all those fancy graphs.


To get SDK 3.0, make sure you're on the new Fabric Plugin and upgrade your kit!

If you're not on Fabric, no worries -- get SDK 3.0 by upgrading your account to Fabric

Our SDK 3.0 changelog:

  • Feature: Background support submission with NSURLSession.
  • Feature: General API for recording non-native language exceptions (Lua, Javascript, C#...).
  • Feature: Support for C++ exception metadata capture (type and .what(), where available).
  • Feature: AppKit integration for much-improved NSException support on OS X.
  • Feature: Support for compact unwind and DWARF unwinding (i386, x86-64 and arm64).
  • Feature: Runtime control over submission behavior as well as the ability to add info to crashes before submission.
  • Enhancement: Adoption of NSProcessInfo's Activity APIs for better developer visibility into Crashlytics' internal operations.
  • Enhancement: Greatly reduced runtime memory footprint, for improved robustness against memory corruption.
  • Enhancement: Improved Swift integration with adoption of nullability attributes.
  • Enhancement: Improved diagnostics for detecting existing crash/exception handlers that will interfere with Crashlytics normal operation.
  • Enhancement: Improved defensiveness during stack unwinding.
  • Enhancement: Improved defensiveness around multiple threads crashing concurrently.
  • Enhancement: Improved behavior when submissions fail due to transient network issues, particularly on iOS 7+ and OS X 10.9+.
  • Fix: Addressed a potential reliability issue for reporting of crashes during launch.
  • Fix: Reports are no longer generated for OS X apps that spawn child processes which then crash.
  • Fix: Bug that would result in rare cases of incorrect stack unwinding for the current thread on ARMv7 and ARMv7s devices.
  • Fix: Improves the performance of validating memory reads in the trivial-fail case.
  • Fix: Adds in explicit warnings for setting the Crashlytics delegate post start.

Crashlytics + Twitter invites you to kick off Google I/O

After our big bash last year, we’ve decided to do it again. Join us for a Google I/O party to remember and come hang out with the top Android developers as we celebrate the awesome apps you’re building. We are humbled by your support for Crashlytics for Android and for being a part of the over 1 million apps integrated with Crashlytics. We couldn’t have reached that milestone without you!

And now that Crashlytics is part of Fabric, we’re getting a bigger tent. This is the Fabric party; it’s the same great celebration as last year, just with a new look.

We’re looking forward to hearing about all the cool stuff you’ve been working on. Who’s ready for fun?


Want to crash our party?

  • When: May 27th, 2015

  • Time: 8:00 p.m. - 11:00 p.m.

  • Where: 1015 Folsom, San Francisco

  • Cost: On us!

(act quickly -- tickets are limited!)


To get excited for the big night, check out the highlights from last year.

Crashlytics April Update

Whether you celebrated Easter, Passover, Earth Day or World Penguin Day in April (we love our penguins), we were busy celebrating too: our systems have now seen more than 1 million apps integrated with Crashlytics!

Aside from this milestone, April was another exciting month around here: we integrated Beta with Answers to give you deeper insights into your releases and now we’re heads down building out support for NDK.

Ensuring release confidence

Since we launched Beta by Crashlytics, one goal has been to give you rich, meaningful insights into how those testers are engaging with your apps. Now with the new Answers integration, you can quickly get a snapshot into the performance of your latest release right within your Beta dashboard. This integration will ensure that you have the most confidence in your app before releasing it to the App Store or Google Play.

By combining the Answers data stream with Crashlytics and Beta, you’ll get instant visibility into how much testing has been done and how stable each release is compared to the last. For each new release, you can compare these metrics to the previous builds and know whether your latest changes helped make your app more engaging and stable.

And by integrating Answers' intelligent data analysis into your Beta distribution dashboard, you’ll have unparalleled insights about your users to improve the performance, stability and overall experience of your app.

An update on NDK support

Since opening access to our beta program in October, our Labs team has continued building out NDK support and enhancing its feature set every day. We're now working with top companies who have already shipped their apps with our beta, so if you haven’t tested out our NDK beta yet, apply to be part of Crashlytics Labs.

Here’s our internal changelog:

  • Crash Reporting
  • Beta distribution
    • Web
      • Shipped new interactive UI dashboard to display metrics from Answers.
      • Implemented number of sessions and seconds tested metrics from Answers.
      • Implemented crash-free devices and crash-free sessions metrics from Answers.

We're working away on more enhancements in the coming months. Stay tuned.


Milestone Achieved: Over 1 Million Apps!

Developer tools have always been about power, focusing less around ease-of-use and the overall user experience. When Jeff and I founded Crashlytics four years ago, we made it our mission to fix this. We didn’t just want to build the most powerful, yet lightest weight crash reporting tool – we wanted to focus on the entire experience. From how you onboard Crashlytics, to what happens when you close an issue, to how we handle support requests, every detail was tailored to building the best developer experience for you.

Today, after four years of tremendous focus and effort by our team, we’re proud to share that we’ve reached a major milestone: our systems have now seen more than 1 million apps integrated with Crashlytics!

Crashlytics is a truly revolutionary offering thanks to how easy it is to implement and use.

Ryan Johnson, VP of Mobile Engineering,

Across those apps, our systems now analyze over 7 billion crash events every 30 days and we’ve learned a tremendous amount about what it takes to support you as you build incredible apps.

What has made Crashlytics such an integral part of every app developer’s toolkit? We asked and below are some of your favorite features that make Crashlytics so valuable to you.

Deep, insightful reports

Crash reporting is more than just a raw paste of a stack trace. To make debugging easier, we built Crashlytics to perform deep analysis of each and every thread, deprioritizing lines that don't matter and highlighting the most interesting ones.

We then went several layers deeper, giving you precise information on the performance of the devices and operating system that your apps run on.

Often, the cause of your crashes goes beyond the device model or operating system. With Crashlytics, you gain even deeper insights – for example, if your app only crashes in landscape mode, or if the proximity sensor is always on. You can resolve crashes caused by more complex factors, like rooted or jailbroken devices, memory, version-specific issues, etc. – factors you would not otherwise have visibility into. By having this insight, you’d be able to ignore an issue that only occurs on jailbroken devices or focus on how things like orientation and memory can be indicative of what is causing the crash.

Dynamic, real-time notifications

Critical issues require your immediate attention, and you just never know when they might occur. With real-time alerts on your web dashboard, there’s no need to wait days for a crash report: we’ll notify you with what’s important so you can fix the crashes that affect the most users as they happen.

Unlike typical notification systems, your alerts will automatically update themselves in real time, grouping crashes by type so they don't pile up as subsequent crashes come in. You’ll know exactly how many new crashes there are and can scan through them with minimal effort.

Find reports you need, when you need them

Context is king when debugging crashes, and knowing the values of critical variables in your app, such as the level of the game the user got to or the byte size of the last photo they took, can help you shave hours off your debugging time. Also, it’s helpful to know which of your users experienced a given crash to help them resolve the issues and keep them happy.

With Crashlytics, you can instantly locate specific crashes with custom keys and user information using our real-time search.

Of course, you can also find crashes by file names, method names, line numbers or issue notes. Our search functionality empowers you to hunt down the important issues and know precisely what happened leading up to the critical moment.

World-class service: more than just a tool

Instead of a tool that merely displays stack traces or data charts, we built Crashlytics into a full service that makes your life easier. Not only can you search for and fix the most important issues in real time, but more importantly, you can easily collaborate with your team to tackle these issues.

When a critical bug comes in, the last thing you want is to struggle with sharing that crash report with your team. We’ve made this incredibly simple within your web dashboard, so that you can invite multiple members – all at once – to join your org. And in just two clicks, you can share the intricate details of each crash with your team, either by sharing the report via email (we generate for you!), or using our short link ( within your favorite IRC client.

On top of email and shareable links, you can seamlessly share your reports through Slack or directly into JIRA, Hipchat, and more through our third-party integrations. Besides collaboration tools, we also integrate with project management services you use every day – like Trello, GitLab, and more – so you can manage your apps with minimal effort.

But as an app developer, understanding your app’s performance starts before you launch. That’s why we built Beta. Not only can you easily control the list of testers you send your app builds to and track their progress, but you can also hone in on those crashes with the greatest impact on your testers.

In just one click you’ll be in your Crashlytics Issues dashboard, with all of our deep analysis tools to help you debug the most complex crashes.

With Beta’s deep integration with Crashlytics’ crash reporting and its crash-to-tester functionality, you can instantly identify the individual tester who experienced a specific crash right within your crash reports. Going one step further we automatically tag all crashes of your beta builds with your testers’ names and email addresses so you can trace the exact steps and situation your testers were in when they encountered the issue.

Finally, thank you.

Since the birth of Crashlytics, we’ve kept to our passion for building services that developers love. This major milestone is just the beginning.

Thank you for being part of our journey. We look forward to continuing to support you in building even more amazing apps!

Crashlytics March Update

march _2015_update

Between St. Patrick’s Day, warmer weather and Bunsen Burner Day (no kidding), we’ve been working around the clock to bring you more new features and upgrades!

In February, we launched Dark Mode support for Yosemite, performed massive internal refactoring on our infrastructure, and continued building out our NDK support. In March, we rolled out a new feature that lets you export select user IDs so you can quickly reach out to those who experienced a specific crash. We also revamped the front-end code for Beta by Crashlytics to be powered by React, so we can enhance and debug our dashboards more efficiently than ever.

Export user ID meta data

With Crashlytics, you can already leverage user ID meta data to identify users who have experienced a specific crash. Many of you have asked for new functionality to easily extract that data. We heard you loud and clear, so now you’ll have the ability to export user IDs in order to communicate with those users faster and with more relevancy.


For example, you can offer a coupon for a lost purchase, or the ability to download a better version of your app. With Crashlytics, you can keep more of your users happy and build better relationships with them.

Working React into the Crashlytics UI

We’ve spent some time working the powerful UI framework React into the Beta by  Crashlytics UI. With that in place, we can enhance our dashboards much more efficiently with even better code. Our own Pete Hopkins recently wrote a detailed post on this (it was featured on HackerNews, too – enjoy!).

Here’s our internal changelog:

Crash Reporting

  • Web
    • Implemented userIDs export functionality on crash reporting dashboard.
  • Crashlytics Labs

Crashlytics for OSX

  • iOS SDK
    • Extended crash reporting support for OSX apps to the Fabric platform.

Beta Distribution

  • Mac App
    • Fixed a bug that prevented Beta distribution if the ZIP environment variable was set.
    • Fixed entitlements to be compatible with ad-hoc distribution.

We're heads down on more enhancements in the upcoming months – stay tuned!

Why We Are Converting to React


I feel weird writing about React. I’m not a contributor or upstanding community member. I’m not even an early adopter – we only started working React into Crashlytics about six months ago.

I’m a fan, though. A huge fan. And even though I thought I was the last person to this party, I keep running into frontend developer pals who haven’t given React a try.

Let’s change that!

The models who couldn’t save themselves

My React fervor was sparked by a bug I wrote. I work on Beta by Crashlytics, and much of our web frontend is written in Backbone. Late last summer, our dialog for managing groups of testers regressed: every so often, it would stop working. Any attempt to edit the group’s name, or add or remove testers, would be met with the same error in the JavaScript console: A “url” property or function must be specified.

How could this be? I had a Group model object, a whole collection of them in fact. You can see them right there in the sidebar. They each had their IDs, and their collection was very clear about how to turn those IDs into URLs. And yet, somehow “save” was broken. Why wasn’t it making its URL?

Let’s be clear, this is my bug. And –  full disclosure  –  I wrote it when converting some other parts of the UI to React. I was finding the Backbone Collection’s “set” method to be too chatty announcing change events, so, for the code that updated our global Group collection in response to a periodic server poll, I changed over to “reset” instead. It even seemed more correct, in my mind: make the groups list exactly like the latest state from the server.

Unfortunately, “reset” works by first emptying the collection of its existing models, then re-populating it. That emptying carries the consequence that those previous occupants — such as the Group object that the editing UI had a reference to — would be orphaned, no longer a member of anything. No parent collection meant no “url” method, and that meant no way to save.

I felt a bit stupid for having caused such a regression, but that was eclipsed by my frustration that such a bug was even possible. Model objects that are capable of saving themselves had already been a pet peeve of mine due to how they hindered testability, but now I found model objects that could arbitrarily lose their ability to save themselves in the middle of my program!

This was a mutation bug on steroids: an object’s functionality changing not even due to local state modifications, but by whether or not another object was holding a reference to it. How could I reason about behavior if this possibility was lurking in my code? What automated test would have even exercised this?

I was determined. I was vengeful. It was now time to, as they say, React all the things.

The DOM Doctors

Doubling down on a new UI rendering library might seem a strange way to solve a model logic problem, but React has the remarkable power to send ripples of correctness through your codebase. Consciously or not, libraries like Backbone end up encoding assumptions about how views work in their data classes. If we fundamentally changed how rendering happens, why wouldn’t that affect how we managed data?

If you’ve heard anything about React, it’s probably that it has a “virtual DOM” that makes its HTML fast using an efficient tree diff algorithm. If you’re like me, the first time you heard that you may have dismissed it. My HTML isn’t slow.

And maybe it’s not that slow, but only because we frontend developers learned not to push it. We joined together our template strings for one big innerHTML splat at the outset and then just modified individual elements going forward. We couldn’t conceive of being so callous as to re-render an entire dialog just because a group’s name changed. We were good programmers, we were precise. We were surgeons, jQuery was our scalpel, and when the “name changed” event came in we made only the tiniest incision in the page to bring it up-to-date.

There’s another reason for why we stepped lightly in the tree: DOM elements are stateful beyond how we created them. They have focus, or scroll positions, or in-progress edits. Some cavalier re-rendering wouldn’t just be slow, it would stomp user data at the same time. And that, at least, was unacceptable.

These constraints had a profound effect on our code. We couldn’t just write the state of what our UI should look like (“the button is disabled because a network request is in progress”). Instead, we were condemned to write the state transitions between those UIs. On network request start? Add class “disabled.” On complete? Remove class “disabled.” If we were lucky, we found all the ways that state tended to linger on our pages. On showing a form? Remove any error messages from the last time we showed this form.

Testing this style of code is both painful and approximate. On top of exercising your initial rendering, you need to test your transitions. They need plausible prior states just to run, but to have good coverage you need to test them against each important variation of prior state that your application is capable of getting itself into. A “finite” state machine perhaps, but only in theory.

Spared from Change

Enter React. The real benefit of that O(n) tree-diffing algorithm isn’t performance per se. It’s that it frees us from having to hand-write every state transition in our UI. Besides reducing drudgery, that actually eliminates the entire class of leaky-state bugs mentioned above. If you declare that your UI is a dialog with an active button and no error message, React will transition to exactly that, performing DOM manipulations that ensure that your button is active and no error message is seen. Any vestiges of previous state are cleansed with no extra effort on your part.

Fundamentally, your old state transition code was a function over your application data, but also over the previous state of the UI. That’s why you needed to consider varied “prior states” when testing. In contrast, your React rendering code is a function over just the application data. You can imagine how much more pleasant that makes your tests.

The real answer to how “just” a view library can affect your data handling is that React is a view library because that’s all that it needs to be. When I talked about the Backbone data classes having assumptions about the way you displayed your UI, I was thinking of mutation handling and attribute-level change events. If you’re writing minimal state transitions, that kind of information is important for doing precise DOM surgery. If you’re writing a React component, though, where declaring UI state is cheap and getting to it is fast, the only notification you really need is “something has changed, probably.”

Since all you need are coarse-grained change notifications, your data objects can be correspondingly simpler. One could argue that React even works best on just plain hashes and arrays. All you need is for a data source to hand your component hierarchy the latest values, and everything flows efficiently from there. No mutation-tracking, self-saving, collection-inhabiting model objects necessary.

Efficient coarse updating also enables what may be my favorite part of React: props and state.

In a correctly-written React component, the only inputs to the UI rendering method are its “props” and its “state.” These are exposed as a pair of hashes on the component object, and changes to either of them cause the component to re-render. (Something has changed, probably.)

The difference between the two is how they change. “props” can be thought of as the input from the outside world. It’s set from the parameters your component is called with, and its values should be treated as immutable. “State,” on the other hand, is the data that’s owned by your component. You update it via the “setState” method, and no one else should be changing it on you.

To give a concrete example, consider a component for editing a group. The props would include the group’s name, while the state might be whether it’s showing a “delete” link or the “confirm” / “cancel” buttons that appear instead when that link is clicked.

This may seem like just a helpful little pattern, but by calling out this distinction between props and state, React has bestowed an enormous understandability boon on your code. Gone is the catch-all “options” hash that contains everything, internal and external. Your data is going to naturally fall into one hash or the other, so there’s one fewer choice to make when structuring your component, and, more importantly, one more signal of your intent when your team comes back to your code months later to extend it.

In practice, the state of one component actually ends up trickling into its child components as props, and establishing your intention is even more valuable. When the same data is “state” here and “props” there it’s perfectly clear what level of your component hierarchy is responsible for coordinating its changes.

Finally, when you consider testability, you can, in almost every case, proceed in ignorance of changes to your component’s props. So, while you and I both know that group names can change, all the component that renders the list of groups in the sidebar needs to do is render the names it’s given. If they change, it’ll be given new names, and it’ll render them just the same. No need to waste time in your tests verifying that case.

Path to salvation

React is fascinating because it takes this rather clever little algorithm for fast tree diffing and follows it to its logical extreme, introducing an incredibly effective paradigm to web developers: If we can diff in O(n) time we can quickly convert one DOM tree to another. That means it’s efficient even if the difference is small. It also means we can keep that partially-filled <input> around. That means we can do coarse-grained updates for any change. That means that re-rendering can be triggered automatically by the framework. That means we can have a simple, standard pattern for state management. And so on.

As a library, React doesn’t really let you build anything that you couldn’t do before with any other UI framework. Maybe some things will be more performant out-of-the-box, but functionality-wise your product will be very much the same. What React gives you instead is much less, better code, sooner. Declarative UIs are faster to write, simpler to test, and far far far easier to reason about.

It feels like nothing short of giving you frontend engineering superpowers.

Hopefully this has whet your appetite for React. Maybe it will be as revelatory for you as it has been for me. Soon, I’ll follow this post up with some more specifics about how we’re using React on Crashlytics, why you don’t need JSX, and our take on a unidirectional data flow pattern :)

We're helping our customers build the best apps in the world. Want to be a part of the Crashlytics team and build awesome stuff? Ping us @ We look forward to chatting with you!

(Big thanks to Kevin Robinson, Sam Neubardt and Sam Phillips for contributing to this post.)

Crashlytics February Update


Roses are red, violets are blue..and we are thrilled to ship new upgrades to you! Last month, we launched two brand new integrations with GitLab and OpsGenie to help you stay on top of crashes and collaborate with your team to fix the most critical issues. In February, despite having Valentine’s day, the Super Bowl and the endless New England blizzards, we still worked around the clock to bring you even more feature enhancements and new functionality :)

Finally, Dark Mode Support

For those of you building on Yosemite, we recognized that some of you have customized your desktop’s look and feel with its new “dark mode“. This month we’ve solved the hardest computer science problem yet: Crashlytics now supports Yosemite dark mode! Your Mac App now automatically detects the mode and displays the Crashlytics icon in its light or dark version accordingly, ensuring that the icon is always visible within the OS X toolbar. All jokes aside, we've actually been heads down building lots of other great stuff in the past few months which you’ll be seeing in the near future -- so stay tuned!


A More Robust Foundation

We’ve been fortunate to power many of the world’s top apps and be trusted by thousands of companies since building Crashlytics three years ago. Like all services of this scale, we’ve accumulated some technical debt, so we spent this month performing some massive internal refactoring on our infrastructure. We started by segmenting large classes into smaller parts and re-organizing our code to make writing unit tests easier. We also brought up a new cluster, implemented sampling and migrated data from old cluster to scale our session service. Now, we can deploy feature enhancements and bug fixes for you faster and safer than ever before, while laying the foundation for more stability and better performance in the future.

Latest Toys from Crashlytics Labs

Many of you who are building awesome apps with the NDK on Android have requested support from Crashlytics. Since opening access to our beta program in October, our Labs team has continued building this out and enhancing its functionalities every day. We're now working with top companies who have already shipped their apps with our beta -- so if you haven’t test out our NDK beta yet, request early access here :)

Here’s our internal changelog:

Crash Reporting

  • iOS SDK
    • Improved crash reporting latency when devices have no network access.
    • Fixed an issue with NSUserDefaults access while an app is in the background.
  • Mac App
    • Implemented icon support for Yosemite in dark mode.
  • Infrastructure
    • Performed large scale internal refactoring.
    • Segmented large classes into smaller parts.
    • Re-organized code structure to make writing unit tests easier.
    • Enabled enhancements and bug fixes to be deployed faster and safer for customers in the future.
  • Web
    • Fixed minor bug for Crashlytics and Fabric related accounts.

Beta Distribution

  • Build Tools
    • Fixed minor bugs within Gradle integration to make distribution uploading more robust with flavor dimensions.

Crashlytics January Update


It was exactly two years ago that we joined forces with Twitter. Since the acquisition, not only have we continued to make Crashlytics even more powerful, we also released several major products in 2014 -- Beta by Crashlytics, Answers, and most recently, Fabric. What an incredible journey it has been!

In December, we were busy crafting a dozen new gifts for you just before the holidays: more upgrades for Beta by Crashlytics, new app installs tracking with Answers, and more. Even though we were stuffed from all the holiday feasts, we are kicking off the new year strong with two new integrations and a ton of feature enhancements :)

Brand New Integrations

Just two months ago, we launched our integrations with Slack and FogBugz to help you strengthen team collaboration and manage your projects. Now, we’re excited to unveil two more integrations: GitLab and OpsGenie.

We understand the importance of staying on top of crashes and collaborating with your team to fix the most critical issues as they occur. Based on overwhelming demand from many of you, Jeremy Durham built the Crashlytics integration with GitLab. With this integration, crashes are automatically delivered to your issues management dashboard on GitLab so you can track all issues and bug fixes in one central place. On the other hand, our OpsGenie integration, built by Halit Okumuş, automatically alerts you if an issue changes status or a new issue occurs. Now, you can sit back and focus on the fun stuff, like coding the next coolest app!

Digits: Login for Web

For those of you building mobile-first services, the best signup experience is likely to be through the native app. But you may also want your users to continue to engage with your apps on the web. This month, we launched Digits login for web which allows you to implement a simple and secure login on your app’s website with just a few lines of code. To help you preserve the mobile-first experience of your service, your users still sign up first through your mobile app, as they normally would, before they can log in to your site. But now, not only can Digits help you drive more downloads for your app, it also enables you to bring your mobile service onto the web — giving you a consistent identity experience across platforms.

Here’s our internal changelog:

Fabric Platform

  • Android Studio
    • Tweaked the plugin so it does not appear on top of other application windows.
    • Added support for multiple monitors.
  • IntelliJ
    • Tweaked the plugin so it does not appear on top of other application windows.
    • Added support for multiple monitors.
  • Eclipse
    • Improved kit refreshing functionality by adding 'Refresh Kits' option from ''.
    • Enhanced support for multiple monitors.

Crashlytics Kit

  • Crashlytics
    • Integrated crash reporting functionality with GitLab issues management.
    • Integrated crash reporting functionality with OpsGenie issues alert service.

Twitter Kit

  • Digits
    • Web
      • Launched Login for Web functionality to make it easy for mobile-first-apps to to use phone number identity across the web.
    • Android
      • Removed Twitter login from fallback screen.
      • Fixed Resources$NotFoundException on Gingerbread devices.
      • Fixed theme detection when building with Eclipse.
      • Fixed functionality to update old guest authentication token.
      • Improved handling of different target SDKs.
  • TwitterCore
    • Android
      • Added logInGuest method to enable guest access to statuses endpoints user_timeline, show, and lookup, search/tweets, and favorites/list.

Crashlytics December Update


Just like the best holiday cards are written from the heart, every line of code we’ve written since the birth of Crashlytics came from our passion of building tools that developers love. In November, we were heads down coding up new 3rd party integrations, a more powerful Swift Support and an upgraded Beta by Crashlytics -- all while continuing to build out our NDK support at Crashlytics Labs. This month, we’ve been busy crafting a dozen new gifts for you: more upgrades for Beta by Crashlytics, new app installs tracking with Answers, and more. We’re excited to share these gifts with you before the year draws to a close!

Beta by Crashlytics: Share Your Builds Anywhere

Many of you have requested the ability to share your builds through other channels beyond email. Now, with share links for Beta, you can create direct links to specific builds while having complete control over who can access those builds -- whether it’s external press or internal employees for dogfooding. To help you fix crashes even faster, we now identify the exact tester who experienced the particular issue right within your crash report -- so you can contact that tester and gather feedback immediately.

Answers: Free App Installs Tracking

Running marketing campaigns to grow and monetize your apps can be difficult, especially when it’s expensive to measure installs. Together with teams at Twitter, we've integrated Answers with Twitter’s advertising platform to make tracking installs incredibly simple. Now, within seconds, you can have total visibility into the installs driven by your paid and organic campaigns on Twitter -- completely free, with no additional code! Also, our solution is now self-serves so you can easily manage your campaigns. Learn more about app installs tracking with Answers here.

Digits: Now Themed to Your App

Your app’s sign-in experience is crucial to growing and retaining your user base. When Digits was first released back in October, you could already launch the Digits sign-in flow from any button anywhere within your app. This month, the Digits team launched theming support to help you further optimize your onboarding experience on both iOS and Android. With the new support, you can match Digits exactly to your app’s ambience so your Digits sign-in flow looks indistinguishable from your app. Theming requires just a few lines of code, and Digits will do the rest!

Here’s our internal changelog:

Fabric Platform

  • iOS SDK
    • Fixed minor bug that occurred for users with multiple accounts.
  • Android SDK
    • Shipped multiple bugfixes.
    • Updated Android tests to make them compatible with Level 21.
    • Updated SDK version from 7 to 8.
    • Fixed kit initialization error that affected a small amount of developers.
  • Mac App
    • Released updated Kits and enabled update by customers through the app.
  • Android Studio Plugin
    • Released updated Kits and enabled update by customers through the plugin.
  • IntelliJ Plugin
    • Released updated Kits and enabled update by customers through the plugin.
  • Eclipse Plugin
    • Released updated Kits and enabled update by customers through the plugin.

Crashlytics Kit

  • Crashlytics
    • Web
      • Shipped crash-to-tester feature to identify the tester who experienced a specific crash.
      • Implemented auto-tagging of all crashes of beta builds with testers’ names and email addresses.
  • Beta by Crashlytics
    • iOS SDK
      • Shipped upgrades to allow for future Beta and Answers integrations.
    • Android SDK
      • Shipped upgrades to allow for future Beta and Answers integrations.
    • Web
      • Increased tester limit on groups to 500.
      • Implemented share links for sending specific builds.
      • Shipped domain restriction functionality for share links.
      • Deployed dashboards for managing share links and tester access.
      • Shipped functionality to automatically point internal share links to the latest build.
      • Implemented auto-tagging of all crashes of beta builds with testers’ names and email addresses.
  • Answers
    • iOS SDK
      • Implemented functionality to enable Twitter conversion tracking.
      • Shipped upgrades to allow for future Beta and Answers integrations.
    • Android SDK
      • Implemented functionality to enable Twitter conversion tracking.
      • Shipped upgrades to allow for future Beta and Answers integrations.
    • Web
      • Shipped ability for customers to select Answers on and UI.
      • Implemented functionality to enable app install tracking via self-service.

Twitter Kit

  • Base
    • Improved proguard configuration by bundling Consumer Proguard Config file with AAR.
  • Digits
    • iOS
      • Shipped custom theming support.
    • Android
      • Shipped custom theming support.
  • Twitter Sign In
    • Improved stability of Twitter login on devices that do not have the Twitter for Android App.
    • Ensured Login with Twitter and Share Tweet button text doesn't show in all caps on API 21.

MoPub Kit

  • iOS
    • Shipped MRAID 2.0 support.
    • Shipped specification to enable rich media ads in banners and interstitial ad units.
    • Shipped automatic geolocation updates for apps that already have location permissions.
    • Implemented functionality to automatically attempt to acquire location data for ad requests (permission-based).
    • Added support for AdColony SDK 2.4.12.
  • Android
    • Shipped MRAID 2.0 support.
    • Shipped specification to enable rich media ads in banners and interstitial ad units.
    • Shipped geolocation polling updates.
    • Updated the ChartboostInterstitial custom event to support Chartboost SDK 5.0.4.

This year has been full of fun and excitement and we can’t wait to continue to celebrate with you into next year. Happy holidays from our Crashlytics family to yours :-)