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.
Comments
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:
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!
I use PLCrashutil and I do not ship debug symblos. Can you explain what improvement you added here?
Looking forward to your improvements to PLCrashReporter, hopefully they will be open-source as Landon's work. Welcome to the space!
- Team HockeyApp
what does compatibility with ARC mean exactly?
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.
Good question. Sounds to me like they've simply made the output of backtrace() available online.
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 :)
Actually, getting the backtrace sounds like a pretty difficult part:
http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Repor...
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.
Hope this helps!
Thanks, I think! ;-)