クラッシュレポートの確認・分析でやっていること

NavigationStackへの移行を終えたある日、身内から「たまにアプリが落ちる」と言われたものの、自分の手元では全く再現できず困っていました。そこで初めて、Xcodeにクラッシュレポートを確認する機能があることを知り、使ってみることにしました。

1. クラッシュレポートを見る場所を知らなかった

「たまに落ちる」という曖昧な報告だけでは何もできないと思い込んでいたのですが、実はXcodeの「Organizer」という画面から、ユーザーの端末で実際に発生したクラッシュの詳細を確認できると知りました。

Xcode > Window > Organizer > Crashes

存在を知らずに数ヶ月過ごしていたことに驚きました。App Storeで配布しているアプリであれば、ユーザーが許可していれば自動的にクラッシュ情報が収集され、この画面で確認できるのだと理解しました。

実際にクラッシュレポートを開いてみると、大量の英数字が並んだログが表示され、最初はどこを見ればいいのか全く分かりませんでした。

Thread 0 Crashed:
0   MyApp    0x0000000102a3c1a4 ContentView.someFunction() + 128
1   MyApp    0x0000000102a3c220 ContentView.body.getter + 64

すべてを理解しようとせず、まず「Thread 0 Crashed」の直後に並んでいる、自分のアプリ名（MyApp）を含む行だけに注目すればよいと知ってからは、原因箇所の見当がつけやすくなりました。関係のない大量のシステム内部の行は読み飛ばしてよいと分かったのが大きな発見でした。

一部のクラッシュログが、関数名ではなく謎のアドレス（数字の羅列）だけで表示されており、全く読めない状態になっていました。

0   MyApp    0x0000000102a3c1a4 0x102a38000 + 16292

これは「シンボリケート」という、アドレスを人間が読める関数名に変換する処理が行われていない状態だと分かりました。Xcodeが自動で変換してくれる場合が多いものの、アーカイブ時のdSYMファイル（デバッグ情報）が見つからない場合はこうなると知り、アーカイブ設定を見直すきっかけになりました。

以前は「自分の手元で再現できないクラッシュ」に対して、原因不明のまま放置してしまうことが多くありました。クラッシュレポートを見る習慣がついてからは、SwiftDataのスキーマ変更のように、特定の端末環境やデータの状態でしか起きない問題がクラッシュログから具体的に見えてくることが増えました。

「自分の手元で再現しない」ことと「原因が分からない」ことは別物であり、クラッシュログというもう一つの情報源があると知ってから、原因究明の手段が一つ増えたと感じています。

身内からの曖昧な報告だけで終わらせず、実際のログを確認する習慣がついたことで、原因究明の精度が上がったと感じています。

本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。