I find it incredible that it is possible to raise $1 million for something with no revenues, little barrier to entry, and that can be written by a very good hacker or two in a few months... Maybe I'm missing something. Anyway, congrats to them!
I'm just wondering how much one could raise revenues doubling twice in the last 2 years and more than half a million expected in the next 12 months.
Few months? A week or two, maybe, because the heavy lifting has already been done by one very nice fellow Landon Fuller who open-sourced his work as PLCrashreporter: http://code.google.com/p/plcrashreporter/
I've been using it for about 2 years now (even submitted a patch or two), and I have a pretty good grip on my crashes. When you use it for a while you realize you don't really need the statistical analysis of the crash reports, because you end up having no crashes if you fix the problems as soon as they show up.
So yeah, if you have a crash reporting problem just add PLCrashreporter to your project, add a file upload code (to your S3 bukket) and look through them regularly. That's all it takes.
PLCrashReporter is great. We've built many things on top of PLCR. A sliver of the many things we've built on the SDK side:
- transparent symbolication so that you get the exact line of code
- compatibility with ARC in iOS 5
- we handle both fatal and non-fatal exceptions
- detect low-memory warnings
- and much more
We also took the time to make our small SDK compatible with others so mobile devs can just drop us in easily.
Beyond that, there's a whole other world to consider outside the SDK. For example, since we want to make sure devs don't need to ship with debug symbols built in (30-50% increase in app size), we have done all the heavy lifting instead of shifting that to the developer (and then to the user).
In terms of just dumping the logs to an S3 bucket, that may work initially, but once you start getting tons of crash reports, the real problem starts -- how to make sense of it all. We also wanted the filename and the line of code that it crashed on, but this wasn't terribly easy to do. We ran into these issues ourselves and decided to build an elegant solution to this problem.
We're excited about this space and have been deeply involved in it. Great stuff to announce soon that should shed more light!
ARC is Apple's new scheme for memory management (more info here: http://developer.apple.com/library/ios/#releasenotes/Objecti...) and there are a bunch of requirements (see "ARC Enforces New Rules") that have to be met for an app to be ARC-compatible. Our SDK also has to follow those rules in order be used painlessly in an ARC-based app.
Getting the back trace is not the hard part. When you get tens of thousands or millions of them, they become useless very quickly. The real work is in de-duplicating, coalescing, and analyzing the backtraces to tell you the insights you need, including the exact line number of code that caused the crash. Pro tip: It's usually not line 0 of the backtrace :)
You're right - it's extremely difficult, but what I was trying to get at is that it's only the beginning of the complexity.
Landon has done incredible work in this area and we are incredibly grateful he has shared his work with the world - it very much inspired a good chunk of what we do. We have taken things further, though, and updated his techniques to work more robustly with LLVM3 and ARC, added non-fatal exception handling etc. All of this must be done extremely carefully, using async-safe code that is tuned to minimize memory footprint. It's not trivial, but it's worth the effort on our end to deliver the best product we can.
We're huge proponents of PLCR and I wouldn't discourage anyone from using it directly. In fact, we're 100% compatible with it, if you wish to run us and PLCR at the same time, side-by-side. The benefits to using our system, apart from the significant aggregation and analysis we do, is that we actively maintain and update our report collection to support the latest iOS and compiler capabilities, so you don't have to worry about that.
A great lightweight solution to a universal problem -- there's simply no way to fully test an app for all the possible environmental conditions that might cause errors (prior to a release). I like that the SDK is microscopic and doesn't require apps to ship with debug symbols. Debug symbols can increase the size of an app exponentially, so this is a huge space saver. Wayne and Jeff know software, and I wouldn't expect anything less than an elegant utility that does what is needed, and doesn't bloat up the app and cause errors of its own. I expect great things from these guys.
Agreed. HUGE problem for app developers and this looks to be a very simple and focused solution - something that's so key to get traction from the start.
Thanks! We really wanted to make sure our users get the best of both worlds - we symbolicate crash reports, provide device insights, and much more, without forcing devs to ship with debug symbols (which ends up bloating their app).
So, technology aside, how do you plan to sell this thing? Larger developers have this problem nailed down already, so that leaves medium and small developers for you. Do you have plans to reach the masses? That would be a very interesting innovation.
This could very easily trim out months of debugging that we have to do with releases across platforms, Looking forward to giving it a run through our dev cycles
stay tuned; I've gotten a sneak peak of the product, and you'll be blown away by how useful and simple it is. When I showed it to mobile app dev friends(who've tried to build this themselves), they all said that they needed this yesterday.
Incredibly smart and complementary founding team. If our enterprise apps used Crashlytics, I'd probably not lose so much productivity over crashes and updates that dont seem to fix anything.
I'm just wondering how much one could raise revenues doubling twice in the last 2 years and more than half a million expected in the next 12 months.