Symbolication delay distorts priority

iOS teams still page me about “brand new” crashes two hours after a store push. The stack is a row of hex. The vendor UI has kindly labelled it a unique group. Everyone is very awake.

Nine times out of ten, the group is an old failure wearing an unsymbolicated face. dSYMs from the build machine arrived late, or bitcode leftovers confused the upload, or someone archived the wrong UUID. Until frames resolve, clustering software cannot match the new dump to the four-month-old cousin sitting quietly in last quarter’s export.

The 36-hour freeze

In our iOS desk we ask teams to adopt a dull rule: no P0 solely on unsymbolicated-only groups for the first 36 hours after a binary hits the store. You may still watch user counts. You may still halt a staged track if a named journey dies with a readable stack. You may not invent a war room from hex.

This rule feels negligent the first time. It feels obvious the first time a rebuilt dSYM merges the “new” monster into a known map-SDK crash you already scheduled for next sprint.

What to fix in the pipeline

Treat symbol files as a release artefact with an owner, not as a CI side effect. Confirm UUID match before you celebrate a green upload. Keep three prior versions rebuildable; vendors lose history more often than people admit.

Android mapping files have a quieter version of the same disease. If you only teach iOS, you will still recognise the politics: the person who owns the upload is rarely the person who gets paged.

If you want the lab version of this argument, sit iOS symbolication and crash clustering. The flagship programme covers the 36-hour rule as one module, not the whole desk.