(Image Courtesy BostInno)
The 50 on Fire awards celebration brought together the city’s brightest individuals who are powering the future of the Boston community and beyond. We’re thrilled to announce that Crashlytics won BostInno’s 50 on Fire award in Technology!
With more than 2,000 companies nominated, we’re humbled to have been selected and are privileged to share this honor with some of Boston’s most innovative and inspiring individuals and companies. We had such a great time celebrating with the Boston community and our supporters.
Congratulations to all of the other winners — it’s great to see so much innovation happening in Boston!
Oh, and check out this video featuring highlights of the night’s winners.
View More
We’re excited to announce that we’re hosting our very first SXSW event! RSVPs are rolling in from many of the top mobile developers and we hope to see you there as well!
The brunch will be held at #FEED at the Austin Museum of Art — located at the center of all the SXSW festivities. Demand is high — reserve your spot now. Learn more about it here.
- When: Sunday, March 10th from 12-2pm
- Where: #FEED at AMOA (700 Congress Ave, Austin, TX)
- Cocktails and brunch: On us
- Want to crash it? RSVP here
View More
Posted by Wayne Chang on Feb 12, 2013 in Company, Featured, Industry
Crashlytics gives mobile app developers insight into their apps’ performance, so you can pinpoint and fix issues quickly and easily. In addition to the main Crashlytics product, we’ve also offered Crashlytics Enterprise, which we introduced for those who wanted even more robust reporting and workflow integration, among other features.
Now all developers can have the best tools to identify and fix issues — we’re folding the features of Crashlytics Enterprise into Crashlytics. The enterprise features will be available to all – for free.
With Crashlytics Enterprise, there are no usage costs, fees, or limits when it comes to your app’s performance monitoring. The features and usage we used to charge for based on limits are now unlimited across the board. This means that you no longer need to worry about numbers like monthly active users, disk space or API limits. And since Crashlytics Enterprise has no limits, you can add as many apps and developer seats as your team needs.
In the future, all new Crashlytics accounts will be automatically upgraded to the unlimited, free version of the product; existing users have already been transitioned. And the capabilities of Crashlytics Enterprise don’t stop here. Working with Twitter, we’ll continue to develop new features even faster.
Try Crashlytics in your app now!
Cheers,
View More
What an incredible journey this past year has been — today, we’re excited to announce: we’re merging with Twitter to take our platform to an entirely new level!
Our Product
We started Crashlytics a little over a year ago to address a huge hole in mobile app development. With hundreds of millions of devices in use around the world, it was impossible for developers to fully test every edge-case and catch every bug before release. Even worse, when problems did crop up, it was often difficult and complicated to find the root cause. App developers were stuck with little insight into what happened and forced to rely on vague end-user feedback to diagnose problems.
We built Crashlytics to deliver the world’s most powerful and lightest-weight crash reporting solution. With us, developers gain instant visibility into the precise line of code that caused a crash, enabling them to more easily fix issues. Since our iOS launch, we’ve had the privilege of working with thousands of incredible app developers, from those building independent passion-projects to many of the top iOS apps available today – Twitter, Vine, Yelp, Kayak, TaskRabbit, and Waze, to name just a few.
-
-
Dashboard of Issues
-
-
Individual crash details
-
-
Our Mac App
What’s Next
With today’s announcement, much will remain the same. Development of Crashlytics will continue unabated and we remain dedicated to working with all of our customers – current and new, big and small – to deliver the key app performance insights they need.
Going forward, we’re thrilled to work with the incredible team at Twitter. We share a passion for innovating on mobile and building world-class applications. Joining forces will accelerate our build-out, allowing us to leverage Twitter’s infrastructure to deliver new features faster than ever.
On a more personal note, it’s an honor to work with the entire Crashlytics team – the best group we’ve ever been a part of – and we couldn’t be more excited to continue doing so.
Join us on our mission and try Crashlytics in your app if you haven’t yet!
Onwards,
Highlights from the Twitterverse:
View More
At Crashlytics, one of our founding principals has been an extreme (some would say, absurd) attention to detail. Crash detection and reporting, particularly on iOS, is a complex and esoteric problem to solve, with arcane restrictions that throw modern programming practices out the window.
Need to allocate memory at crash-time? Revisit your approach. Thinking of calling an Objective-C method? Dream on.
This focus has not gone unnoticed: many of the world’s best mobile engineering teams – that build many of the most-well-known apps – now trust our award-winning Crashlytics for iOS solution to deliver accurate, detailed, crash reports from hundreds of millions of devices around the globe.
But we’re not satisfied.
Over the past 6 months, we’ve embarked on a ground-up rewrite of our iOS SDK to take things to a whole new level and, after 2 months of intense testing, I’m extremely pleased to publicly announce the release of Crashlytics for iOS v2.
Highlights from hundreds of improvements
When we set out to design our new iOS SDK, it was the perfect opportunity to fundamentally rethink our approach. We’ve made hundreds of improvements to our iOS SDK that have lead to significant performance and stability increases. Here are some of the major ones:
- Mach Exceptions. Better than signal handlers.
All widely-used crash-reporting solutions for iOS and Mac OS are currently based off signals and uncaught exceptions. By registering handlers for both of these events, it’s possible to detect and inspect the majority of crashes that occur. As our usage has exploded, however, it became painfully obvious that crashes were sneaking through. For example, it’s not possible to catch all stack-overflow crashes with a signal handler.
Fortunately, there’s a better way. In Darwin, signals are actually implemented on top of lower-level events called Mach Exceptions. Handling these directly is the holy-grail – all crashes can be captured immediately after they happen with far more precision and accuracy. The Mach Exception API is radically more complex than signal handling, but capturing every crash more than justifies the hurdles.
- Advanced techniques to stop secondary crashes.
Processes that crash often end up sustaining considerable damage before the kernel takes action to terminate them. In many of the nastiest crashes we’ve seen, this can result in secondary crashes, where the crash-handling code itself is unable to operate correctly and fails, obscuring the source of the original crash. Secondary crashes have two primary causes, both due to corruption. A buffer-overrun could mangle or destroy the in-memory data-structures that Crashlytics uses to track state. Alternatively, hardware failures or disk errors could damage the temporary cache files used to record data before it was sent to our servers.
Our new SDK goes to great lengths to address these scenarios. By carefully controlling its memory usage, our new SDK is able to pre-allocate a contiguous block of RAM that it then surrounds with guard pages, protecting against buffer-overruns. In the case of cache corruption, we’ve invested in making our file-handling code extremely defensive, so parsing cache files can’t crash unexpectedly.
- Stack unwinding. Finding the real path to the crash.
One of the most abstruse aspects of crash detection is stack unwinding, the seemingly omniscient ability to determine historic code execution that directly lead to the crash. In practice, it involves carefully walking up the stack in memory and searching for return addresses – the instruction pointers of the calling lines.
Writing an ARM stack unwinder that works in most cases is relatively straightforward – the stack layout for iOS is well-defined. However, things start to fall apart when custom assembly is thrown into the mix, as there are no hard rules on what can and can’t be done. It just so happens that objc_msgSend is such a method, performing countless tricks to make dynamic method invocation in Objective-C as fast as possible. All works perfectly during normal operation, but if objc_msgSend crashes, a naïve ARM unwinder could easily miss the stack frame of the calling function. Of course, that’s the critical line you need to know!
Our new SDK uses a vastly better technique to determine the calling instruction that works in the case of objc_msgSend and many other “creative” methods that still conform in-part to Apple’s iOS ABI.
We could not be happier to get these improvements into the hands of thousands of app developers and the feedback so far has been fantastic. Thanks to all those who have helped us test Crashlytics for iOS v2 and trust me – we’re not stopping here – the most advanced crash reporting SDK for iOS will keep getting better!
Have questions about Crashlytics for iOS v2? Send us email!
View More
