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

iOS

  • 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   

Android

  • 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

iOS

  • Added the ability to search for previous builds

Android

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

Web

  • 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:

iOS SDK

  • 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

Web

  • 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 (crashes.to/...) 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.

crashlytics_export_id

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 @ jointheflock@twitter.com. 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

Crashlytics_February_2015_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!

crash_icon_on_yosemite_dark_mode_screenshot-e1424973461809.png

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 'kits.properties'.
    • 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 ads.twitter.com and analytics.twitter.com 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 :-)

Announcing Share Links and Crash-to-tester for Beta by Crashlytics

beta-share-links-header-v2

It’s been just seven months since we launched Beta by Crashlytics. We’ve been thrilled by the response from developers looking for a seamless way to distribute beta builds of their apps to testers. In August, we released groups support, the first of many product additions, and in October, we re-released Beta as part of Fabric. Today, we’re excited to share the next evolution of Beta.

We heard you loud and clear that you need an even lighter-weight way of sending out builds – without email – and be able to control who gets access. Another challenge: how to efficiently get detailed, actionable feedback from testers about your crashes. Now we think we’ve got you covered with share links, the most convenient way to onboard testers to your builds, and crash-to-tester Identification, which combines the power of Crashlytics and Beta to help you quickly get to the bottom of your builds’ crashes.

Total Flexibility for Onboarding Testers

Many of you want to share your builds through channels beyond email. Now, with share links, you can seamlessly create onboarding links for each build and invite testers through any medium you choose – without needing to know their email addresses. Whichever channel you prefer, you have the flexibility to tailor your message to testers.

beta-share-link-v2

Within your share link dashboard, you can manage all your links in one place -- with complete control over who can access your builds. Share a public link with the press or your investors, or create a private link for internal dogfooding by setting domain restrictions. We also automatically point your internal links to the latest build so your testers can always access the latest from one reliable place.

No need to worry about manually adding new testers either! With share links, you can automatically assign new testers to a group when they sign up via your link. This ensures that everyone will receive your updates in the future, as soon as you send them out. On top of that, you can now create specific groups ahead of time based on where you plan to post your links. Organizing testers have never been easier.

Deep, Actionable Testers Feedback

One of the most powerful features of Beta is its deep integration with Crashlytics’ crash reporting, which empowers you to fix the most critical issues with the least effort before your app goes into the wild. With our new crash-to-tester functionality, you can instantly identify the individual tester who experienced a specific crash right within your crash reports.

crash-to-tester-v3

We automatically tag all crashes of your beta builds with your testers’ names and email addresses. Now, you can immediately contact your testers for feedback and even work with them to reproduce an issue. Coupled with your crash reports and custom meta data, you’ll be able to trace the exact steps and situation your testers were in when they encountered the issue.

From our friends at Lyft:

Using the direct share links has made distribution simple and easy. I can now use one link to ensure our testers always have the latest builds by sharing the link across multiple channels, including email, SMS, and social. In addition, the crash-to-tester feature has reduced time spent investigating issues by connecting users to specific crashes, tracing their actions leading up to them, and including relevant contact information for easy follow-up.

Will Farino,


Let us know what you think. Our roadmap is full of exciting features which we’ll continue to roll out in the coming months. Stay tuned!

 

Crashlytics November Update

 

It’s that time of year! The falling leaves, checkered scarves, pumpkin-flavored everything..the perfectly cozy atmosphere to sit down, code and ship something awesome. In October, we were thrilled to ship and unveil Fabric, the easiest way to build the best apps. But we didn’t stop there. Going into November, we were heads down building out even more new functionality and upgrades that you can play with before the holiday arrives :)

Finally, the Easiest Way to Build the Best Apps

Since the birth of Crashlytics, our mission has been to build the best suite of tools and services for mobile developers. We’ve thought long and hard about how to help developers address the most pervasive challenges: stability, distribution, revenue and identity. At Twitter Flight on 10/22, we officially launched Fabric, a modular mobile platform that helps you solve any one – or all – of these challenges. Learn more about Fabric here.

Since the launch, we’ve been inundated with requests for access. If you haven’t signed up for Fabric yet, request an invite!

Brand New Integrations

Since open sourcing our integrations code last year, we’ve seen many developers build and submit integrations on top of our existing infrastructure. Now, we’re excited to unveil two new integrations to help you strengthen team collaboration and manage your projects: Slack and FogBugz.

We understand the importance in team collaboration and being in constant communication to understand who’s working on what. Emmanuel Pinault built the Crashlytics integration with team collaboration service Slack. With this integration, messages are posted directly into your preferred channels so you can quickly and easily communicate with your team about your app stability. On the other hand, our FogBugz integration, built by Jeremy Durham, automatically organizes and imports your app crashes into your issues tracker on FogBugz. Now, you can keep a close eye on the performance of all your projects -- mobile or web -- in one central place!

More Powerful Swift Support

We’ve been working on enhancing our official support for Swift since launching it two months ago. Now, by combining our new logging functionality for Swift with real-time search, you can instantly locate the exact crashes you were looking for in your apps and know precisely what happened leading up to the critical moment. Enjoy coding in Swift -- we’ve got you covered.

Fine-Tuned Beta by Crashlytics

To make it even simpler for you to manage your testers, we added “groups on release” to your Beta web dashboard. You can now, at a glance, track the progress of all your groups and individual testers associated with a specific build. Also, your testers progress dashboard now updates in real-time!

Latest Toys from Crashlytics Labs

Since launching Crashlytics two years ago we’ve been tirelessly seeking out feedback from our customers. Many of you who are building awesome apps with the NDK tool set on Android have requested support within Crashlytics. Our Labs team has been hard at work building this out, and we are very excited to invite you to request access to participate in our beta program.

Growth & Monetization, Simplified

Beyond stability, we wanted to help you tackle the challenges of growing and monetizing your apps. Together with teams at Twitter and MoPub, we’ve built the Twitter Kit and MoPub Kit for Fabric. With the Twitter Kit, you can create a seamless onboarding experience through Digits and instantly tap into Twitter’s network and content to grow your audience. The MoPub Kit, on the other hand, empowers you to turn your app into a business by making it dead simple to integrate ads with just a few clicks. Both kits are easily accessible in your new Mac app / Android IDE plugins.

Here’s our internal changelog:

Fabric Platform

  • iOS SDK
    • Integrated Crashlytics Kit (Crashlytics, Beta by Crashlytics and Answers by Crashlytics).
    • Integrated Twitter Kit (Digits, Sign In to Twitter and Tweet Embeds).
    • Integrated MoPub Kit.
    • Shipped one-line-of-code install functionalities for Crashlytics Kit, Twitter Kit and MoPub Kit.
    • Implemented Swift onboarding support for kits.
    • Simplified usage of Tweet IDs throughout iOS codebase.
  • Android SDK
    • Integrated Crashlytics Kit (Crashlytics, Beta by Crashlytics and Answers by Crashlytics).
    • Integrated Twitter Kit (Digits, Sign In to Twitter and Tweet Embeds).
    • Integrated MoPub Kit.
    • Shipped one-line-of-code install functionalities for Crashlytics Kit, Twitter Kit and MoPub Kit.
    • Refactored Android session management to include Digits support.
    • Shipped network stack refactorings to reduce SDK size.
  • Mac App
    • Shipped new Fabric Mac app with kits selector.
    • Implemented support for XCode 6 and legacy XCode versions in the new Mac app.
    • Deployed ability to install individual kits or upgrade to new kit versions.
  • Android IDE Plugins
    • Shipped new Fabric Android IDE plugins with kits selector.
    • Implemented support for Android Studio, IntelliJ and Eclipse in the IDE plugins.
    • Deployed ability to install individual kits or upgrade to new kit versions.
  • Web
    • Shipped new Fabric web dashboard to include Crashlytics, Beta by Crashlytics,  Answers by Crashlytics, Twitter Kit and MoPub.
    • Redesigned entire onboarding experience (i.e. Mac app/Android IDE plugins installation, build tools integrations, email notifications) with Fabric branding.
    • Implemented auto-download functionality for Android IDE plugin install packages.

Crashlytics Kit

  • Crashlytics
    • iOS SDK
      • Integrated into Crashlytics Kit on Fabric.
      • Shipped new reports endpoint to prepare for new SDK version.
      • Launched logging functionality for Swift.
      • Shipped extension support for iOS 8.
    • Android SDK
      • Integrated into Crashlytics Kit on Fabric.
    • Integrations
      • Implemented Slack and FogBugz service hooks.
  • Beta by Crashlytics
    • iOS SDK
      • Integrated into Crashlytics Kit on Fabric.
    • Android SDK
      • Integrated into Crashlytics Kit on Fabric.
    • Web
      • Launched direct URLs for onboarding testers to specific builds.
      • Implemented ability to identify specific tester who experienced a specific crash inside crash reports.
      • Resolved javascript errors on tester side.
      • Fixed group summary counts.
  • Answers by Crashlytics
    • iOS SDK
      • Integrated into Crashlytics Kit on Fabric.
    • Android SDK
      • Integrated into Crashlytics Kit on Fabric.
      • Shipped IDFA collection in Fabric.
  • Crashlytics Labs
    • Opened private access via /secret to beta program of NDK support.

Twitter Kit

  • Digits
    • iOS
      • Launched integration and sign in button initialization support.
      • Shipped sign in, sign up and phone number confirmation functionalities.
      • Shipped unique user IDs and OAuth tokens support.
      • Shipped “Find Friends” functionality for your apps’ end-users.
      • Launched support for 28 languages.
    • Android
      • Launched integration and sign in button initialization support.
      • Shipped sign in, sign up and phone number confirmation functionalities.
      • Shipped unique user IDs and OAuth tokens support.
      • Shipped “Find Friends” functionality for your apps’ end-users.
      • Launched support for 28 languages.
    • Web
      • Launched integration support with Javascript.
      • Shipped sign in, sign up and phone number confirmation functionalities.
    • Digits.com
      • Implemented custom security settings (i.e. two-factor authentication) for your apps’ end users.
  • Twitter Sign In
    • iOS
      • Launched single sign-on functionality.
      • Shipped support for Twitter sessions callback and exceptions handling.
      • Shipped functionality to request Twitter end-user email.
    • Android
      • Launched single sign-on functionality.
      • Shipped layout XML support for sign in button integration.
      • Shipped support for Twitter sessions callback and exceptions handling.
      • Shipped functionality to request Twitter end-user email.
  • Tweet Compose
    • iOS
      • Shipped Tweet composer for end-users to share your app’s content on Twitter.
    • Android
      • Shipped Tweet composer for end-users to share your app’s content on Twitter.
  • Embedded Tweets
    • iOS
      • Shipped embeddable Tweet objects in native apps.
      • Implement support for custom sizing and theming Tweets to match your app fonts/colors.
      • Shipped localization support.
      • Implemented OAuth Echo support.
    • Android
      • Shipped embeddable Tweet objects in native apps.
      • Implemented support for custom sizing and theming Tweets to match your app fonts/colors.
      • Shipped localization support.
      • Implemented OAuth Echo support.
  • Web
    • Shipped new dashboard for Twitter on fabric.io.

MoPub Kit

  • Mac App
    • Implemented ads format selector.
  • Android IDE Plugins
    • Implemented ads format selector.
  • Ads Integration
    • Native Ads
      • Shipped integration, sizing, placement, targeting and auto-caching support inside Fabric.
    • Video Ads
      • Shipped integration, placement, targeting and auto-caching support inside Fabric.
    • Interstitial Ads
      • Shipped integration, placement, targeting and auto-caching support inside Fabric.
    • Banner Ads
      • Shipped integration, placement, targeting and auto-caching support inside Fabric.
  • Web
    • Shipped new dashboard for MoPub Kit on fabric.io.

Introducing Fabric

  Introducing Fabric

Almost three years ago, we set out to solve the problem of mobile crash reporting. Since then, we’ve launched our deeply technical, award-winning crash reporting service, and with Twitter, expanded our product line to include a white-labeled beta distribution tool and our real-time mobile analytics product. Our mission has been, and remains, to build the best mobile developer tools.

Today at Flight, we announced the evolution of all of this work: Fabric, a modular mobile platform that makes it easy to build great apps.

We’ve thought long and hard about how to deliver great solutions to address the challenges developers face. The Crashlytics team, together with teams at Twitter and MoPub, have developed Fabric. It’s exactly what we hoped to build back when we started the company.

Fabric is modular, so you pick just the features — we call them kits — you want. If the Crashlytics Kit is the one you need for your app, you can easily add just that one. Crashlytics customers will recognize the Fabric interface: it’s based on our existing IDE plugins but with a fresh new look. You’ll even see the same familiar dashboard.

Read more about the Fabric features and individual kits on the Twitter developer blog.

What’s next

In the coming weeks, we’ll be rolling out Fabric to current Crashlytics customers. We’ve worked to make the upgrade experience very simple for you. If you’re interested in exploring the other kits (Twitter and MoPub), they are easily accessible in the new plugin.

As with all our launches, your experience and feedback is critical to us. Write to support@fabric.io to let us know your thoughts. We really want to build the tools that you love to use.

Onward,

 

Crashlytics September Update

September_Update

School’s back in session, and we have lots of upgrades and enhancements for you.

Last month, we launched group support for Beta by Crashlytics and improved plugin support on Android. This month (while many of you were no doubt waiting in line for your new iPhone), we shipped enhanced features for Answers by Crashlytics and Beta by Crashlytics, launching Swift support and improved version tracking. Oh, and we also unveiled our participation in Twitter’s first mobile developer conference, Flight. Will we see you there?

Improved alerts

When we launched Answers by Crashlytics, we set out to create a mobile analytics tool that required zero analysis. We wanted the alerts to be so intuitive that you could understand the pulse of your app with just a glance. Now with email alerts, it’s even easier for you.

Our daily digest offers a summary of your app’s performance from the previous day. With these top-level metrics, you easily get a sense for how your apps are performing without you needing to do any analysis – delivered right to your inbox. With our real-time stability alert email, you know immediately if the stability of your apps has changed. No need to sit and watch your dashboard all day, we’ll deliver the information to you, with the ability to easily jump back into the stability page of your Answers dashboard. And as with all of our email notifications, you can easily manage your preferences in your settings dashboard.

The more the merrier

Last month, we launched group support for Beta by Crashlytics, giving you the ability to send specific builds to a specific set of testers based on their development cycle. This month, we added the ability to upload .csv files. Now you can easily import lists and add testers to groups to get even more of them up and running.

Gone, but not forgotten

We know many you have very active release cycles; older versions of your app quickly become outdated. We heard you loud and clear when you asked for the ability to archive old versions so you can declutter your version list. Now, your dashboard shows a quick view of the versions that matter most.

We love when you share ideas of how we can make app development easier, and are always eager to learn how we can help. Make sure you keeping sending along feedback, product requests or just say hi to our team at support@crashlytics.com.

Build how you want, where you want

When Apple promoted Swift as a language that was easier to read and maintain, we wanted to get on board. So this month, we launched support for Swift apps, providing developers with the flexibility you need to build inside existing workflows and streamline the overall development process. We developed a customized onboarding experience with our Mac app letting you choose between building with Objective-C or Swift. Whether you’re new to Crashlytics or migrating to this new language, you’ll experience the same powerful features, combined with native support for Swift-based builds.

Join us at Flight

In case you missed it, we announced Twitter Flight: Twitter’s first conference exclusively for mobile developers. There’s still time to apply to attend. We’d love to see you there, so don’t miss out!

Here’s our internal changelog:

General

  • iOS SDK
    • Removes requirement to import Crashlytics in your bridging header for Swift apps.
    • Mac App
      • Support for seamless Swift app onboarding via plug-in.

Beta by Crashlytics

  • Web
    • Added .csv upload allowing you to easily import tester lists.

Answers by Crashlytics

  • Web
    • Launched the daily digest email highlighting your key metrics from the previous day and the real-time stability alert email.

Crash Reporting

  • Web
    • Added version archiving to declutter your version list.

Join Crashlytics at Twitter Flight

 

Today Twitter announced Flight, the company’s first annual conference for mobile developers, and we’re joining in on the fun. Flight will take place on October 22nd in San Francisco. At Flight, you’ll have a chance to learn how Twitter can help you build the best mobile apps. You can learn more about Flight on the Twitter Developers blog.

As a friend of Crashlytics, we want to give you the first chance to apply to attend Flight. So take a peek at the details, apply, and we hope to see you there!

Launching Crashlytics Swift Support

swift_header_image

When Apple introduced Swift, their new programming language, at this year’s WWDC, like you our engineers didn’t waste any time and dove in to see what it was all about. After spending the past few months testing out support in our developer preview, we’re excited to announce Crashlytics official support for Swift!

Build How You Want, Where You Want

At Crashlytics, we’re huge supporters of making it as easy as possible to develop mobile apps. When Apple promoted Swift as a language that was easier to read and maintain, we knew we wanted to get on board. In anticipation of Apple’s upcoming announcement, we’re rolling out our official support so that developers can quickly get up and running. Our support for Swift provides developers with the flexibility they need to build inside their existing workflows and streamline the overall development process.

Our engineers worked tirelessly updating our backend to support the demangling of Swift crashes and took meticulous care to preserve our seamless onboarding and pristine UI. To provide you with a customized onboarding experience, our Mac app allows you to choose between building with Objective-C or Swift. Whether you're new to Crashlytics or migrating to this new language, you’ll experience the same powerful features, combined with native support for Swift based builds.

swift_screenshot (1)

We love supporting developers as they continue to experiment with new and improved ways for building mobile apps. We’re excited for the launch of Crashlytics support for Swift, get started here.