Introducing Reprocessing for iOS

In order to provide useful and human-readable stacktraces for iOS crash reporting, developers have to share their app debug symbols with Sentry. If a crash comes in, Sentry uses these debug symbols to map memory address to the according function name and line number.

For example: the unreadable 0x205d2d000 becomes ViewController.onClickFatalError(AnyObject) -> () (ViewController.swift:113)

Now the user knows exactly where the app crashed and can fix the bug. But for this to work inside Sentry, there was a catch: you had to provide these symbols before the crash occurs. And not all iOS developers have access to symbols before they go up on the App store.

Today we are proud to announce our new reprocessing feature. With this update, events from iOS error monitoring that cannot be processed due to missing debug symbols will be held from the event stream and reprocessed once the symbols have been uploaded.

Why reprocessing matters

This has two major advantages for iOS developers. The first is that this keeps noise down due to bad grouping caused by lack of information. In the past, if events were submitted before debug symbols were uploaded, you could easily end up with lots of incorrectly grouped errors that were just duplicates from older issues.

The second benefit is that since we put those issues on hold temporarily, we will not send out any email notifications from those until the debug symbols are up.

While in a perfect world you would never see an event before the debug symbols are ingested, we know that this is hard to do in practice. In particular, if you have bitcode-enabled builds, it can take a long time for processing to finish on the iTunes Connect side. This means that there is a good chance that someone may start (ab)using your app before you’ve had time to upload symbols.

Enabling reprocessing

Reprocessing is disabled by default and can be turned on in the project settings. Additionally, if you have an issue that lacks debug symbols, we’ll point you to the reprocessing settings page.

In the project settings you can turn it on with a flip of a switch:

There you can also see a log of all the reasons events were not processed (for instance, because of missing debug symbols, because broken debug symbols were uploaded etc.).

When debug symbols are missing you can see this on the event stream. A red warning bar will appear and inform you to upload missing symbols.

Our command line tools have been updated to trigger reprocessing automatically. If you are using an older version of sentry-cli that does not have this automatically enabled, you can also manually trigger reprocessing from the project settings.

How it works

What happens if it’s turned on?

When the feature is enabled, all events that are missing mandatory debug symbols go into a queue and will not show up until their debug symbols are uploaded. Currently we only require a small set of debug symbols and when all those are up the event is free to be reprocessed.

What is considered a mandatory debug symbol?

This is currently implementation defined and we might tweak it in the future. For now, you can see the list of debug symbols we deem required in your project settings once we encounter such debug symbols. We recommend uploading all debug symbols you have.

What triggers reprocessing?

There is an API you can hit which starts the reprocessing. By default this is done automatically by the sentry-cli tool but this can be disabled. You can also trigger reprocessing again from the project settings.

What about optional debug symbols?

We recommend uploading optional debug symbols first or to not trigger reprocessing until you have them all up. Once an event is no longer on hold we no longer permit reprocessing.

Can I see events on hold?

There is currently no way for you to see such events but we will investigate this option in the future.

What happens if I disable reprocessing?

If you disable reprocessing, events that are already on hold will be processed and shown to you in the stream view. Future events that come in will also show up as they arrive. This, however, might cause bad grouping because information relevant for grouping could be unavailable. We recommend against turning off reprocessing.

See also our updated Swift client

Reprocessing isn’t the only thing that’s changed for iOS. We recently pushed out a big change to our client for Swift error tracking, which – together with some server side changes – greatly improves the accuracy of our symbolication process. If you are not using the latest and greatest version yet, please make sure to upgrade.