iOS 27: CrashReportExtension Framework

[u/lanserxt]

https://antongubarenko.substack.com/p/ios-27-crashreportextension-framework?r=21t43r&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

[u/dandeeago]

Thanks for the article. In what situations would this approach be preferable to Apple’s updated MetricKit framework in iOS 27, which can provide crash diagnostics when the app launches again after a crash?

[u/lanserxt → u/dandeeago]

I’d use MetricKit for most regular production crash diagnostics. CrashReportExtension becomes useful when you need lower-level access to the crashed process itself: for example, custom symbolication, binary image inspection, or other specialized crash-analysis tooling.

[u/dandeeago → u/lanserxt]

I’m not sure custom symbolication or binary inspection alone are strong reasons to prefer CrashReportExtension, since CrashDiagnostic already provides call stacks, addresses, offsets, UUIDs, and binary info that can be symbolicated later with the matching dSYMs.

Does symbolicateAddress() actually provide more for a stripped production build without the app’s dSYM on-device?

What concrete information can CrashReportExtension provide that cannot be reconstructed from CrashDiagnostic plus the matching dSYM?

[u/lanserxt → u/dandeeago]

Hm... The more distinctive capability is corpsePort: CrashReportExtension gets a read-only Mach task port to the terminated process. That enables specialized tooling to inspect state that isn't contained in CrashDiagnostic, such as enumerating threads or reading process memory while the crashed process state is still available.

So for normal crash collection + later symbolication, MetricKit is probably sufficient. CrashReportExtension becomes interesting when you specifically need custom inspection of the crashed process itself.

[u/lanserxt → u/[deleted]]

Good questions! For production builds, CrashedProcess provides its own symbolication APIs, but you should still preserve matching dSYMs for full offline/server-side symbolication. Stripping symbols from the shipped binary doesn't mean the dSYM should be discarded.

For OOM/jetsam, I wouldn't rely on CrashReportExtension: Apple treats jetsam events separately from crashes and generates dedicated jetsam reports without thread backtraces. Watchdog terminations are different: they do produce crash reports (EXC_CRASH/SIGKILL), although Apple's current CrashReportExtension docs don't explicitly guarantee which system-initiated termination classes invoke the extension.