Ok, so we’re building a crash reporting service

Crashes are just the worst. Often, they’ll show up just in time to spoil the enjoyment of releasing a new version of your app. And then it can be a real scramble to fix them. It’s stressful to be debugging all while you’re worried about impacting customers. This is why everyone uses a crash reporting system of some kind. They work well. So, why on earth would we build our own?

Well, as time goes on and your app evolves, you end up with this sea of mysterious, inscrutable crashes. This is a problem that I’ve been interested in for a while. But, when we started facing the same thing with Chime, I couldn’t help myself. I began to tinker. It started with a crash capturing system, eventually released as Impact and Wells. I then threw together a very simple backend to accept reports. Symbolication, storage, it just started growing bit by bit. Eventually, I started also experimenting with different ways to group and analyze crashes.

But how is this different?

More and more, this little side project starting looking like something that other people might want to try. So, we put some actual effort into it, bought a domain, threw together a website (obviously), and Stacksift was born. It’s not full-featured, but it definitely is a real system. And, all the while it’s been defined by three characteristics: privacy, developer control, and a focus on debugging.

Our goal is to collect and process crash reports, and that’s it. We have no interest whatsoever in user or developer tracking. We avoid collecting identifiable information when we can, strip it out if we can’t, and delete data regularly as it gets old. Sometimes privacy and debugging context are at odds. This is something we want to continue to tackle without sacrificing end-user privacy.

Stacksift is also made to be used however you want. We do have an SDK, but it exists purely for convenience. Today, we support Impact- and MetricKit-generated reports. But, you can use the Stacksift processing service without putting any of our code in your app. We’re also looking at supporting PLCrashReporter’s format, and are open to others.

But, just like we won’t tie our service down to one SDK, we also won’t tie it down to one interface. We do have a client app available. But, it feels a little like “My First SwiftUI App”, because that’s exactly what it is. Our client-side API will be accessible for anyone else interested in consuming processed crash data.

The thing we’re most excited about is Stacksift’s focus on debugging. We do things a little differently from traditional crash reporting services here. Most services map a crash into exactly one group. Stacksift finds multiple, common elements across all your crashes. This can reveal relationships that you never knew were there, and can really help to guide your debugging efforts from a higher level. We also have ways to annotate reports to aid in understanding exactly what was going on at the time of crash. We’ve gone deep to try to help you make sense of that long tail of mysterious crashes. But, with just one app’s worth of data, it’s all still very experimental.


Honestly, it’s also all been quite an exercise in doing the least work possible. We have another project going on, but we couldn’t ignore the opportunity. And there are still so many questions. Our backend system is expensive to run - can we afford to do this and what price do we charge? Is this even something people are interested in? Is our analysis really helpful? All things we need help answering.

So, that’s why we’re throwing this preview out here. We’d like to find a few testers. If Stacksift seems like something you’d like to try, we’d love to hear from you.

Thanks and happy debugging!

May 24, 2021 - Matt Massicotte

Next: Expanded MetricKit Support