This year’s WWDC had an excellent session about it, but we thought it would be a good idea to give another overview here, since it is not widely known yet.

The basic idea is that work done in response to user interactions or other events is grouped under an activity, no matter if the work is done synchronously or if it’s dispatched to other queues or processes. For example, if the user triggers a refresh in your app, you’ll know that this particular user interaction caused a subsequent crash, even if it happens on a different queue and several other code paths could have led to the crashing code as well.

Activity tracing has three different parts to it: activities, breadcrumbs, and trace messages. We’ll go into those in more detail below, but here’s the gist of it: Activities allow you to trace the crashing code back to its originating event in a cross-queue and cross-process manner. With breadcrumbs, you can leave a trail of meaningful events across activities leading up to a crash. And finally, trace messages allow you to add further detail to the current activity. All this information will show up in the crash report in case anything goes wrong.