In iOS development, crashes are one of the most typical issues. But the real difficulty is how to find the code problem in the crash log?

Many people feel overwhelmed when they first see a .ips file, with its hexadecimal addresses and multi-threaded call stacks, making it seem like a system issue rather than a code problem.

In fact, crash analysis follows a structured path. This article combines my practical handling methods in projects to break down the process clearly.

Step 1: First Obtain the Correct Crash Log

Before analysis, the most critical step is obtaining a complete, version-matched log.

Common Methods for Obtaining Logs

Xcode (Development Phase)

  • Devices and Simulators
  • View Device Logs

Suitable for development debugging, but not applicable for testing environments.

Directly Export Logs Using Device Tools (More Common)

In testing or production issues, I more commonly use Keymob Assistant to export crash logs.

Operation Steps

1 Connect the Device

  • Connect iPhone via USB
  • Open Keymob Assistant

2 Enter the Log Directory

On the left side, select:

File Management → Log Files
Log Files

3 Find CrashReporter

Enter:

CrashReporter

This stores all crash logs.

4 Filter by Time

File naming convention:

AppName-Date-Time.ips

For example:

MyApp-2026-03-21-103512.ips

Find the corresponding file based on user feedback time.

5 Export the Log

  • Check the file
  • Click Save
  • Export to local

Step 2: Confirm Log Usability

After obtaining the log, don’t rush to analyze.

First confirm two things:

  • Whether it is a crash from the current version
  • Whether there is a symbol table (dSYM)

If not symbolized, the call stack is basically unreadable.

Step 3: Symbolication

This is where many people get stuck.

Method 1: Xcode Automatic Symbolication

Drag the .ips file into Xcode:

  • If dSYM matches, it will automatically parse
  • Function names become visible

Method 2: Manual Symbolication (When Necessary)

If automatic fails, you need:

  • Corresponding version dSYM
  • Use the symbolicatecrash tool

Step 4: Actually Start “Reading the Log”

After symbolication, the log becomes readable.

Focus on three parts:

1 Crash Type

For example:

  • EXC_BAD_ACCESS
  • SIGABRT
  • KERN_INVALID_ADDRESS

This step determines the analysis direction.

2 Crash Thread

The log will mark:

Thread X Crashed

Only look at this thread; don’t start by examining everything.

3 Call Stack

Read from top to bottom:

  • The first is the crash point
  • The following is the call path

Step 5: Understand the Issue by Combining with Runtime Process

The log only tells us where it crashed, but not why.

At this point, align the crash time with runtime behavior.

Supplement Context with Real-Time Logs

When reproducing the issue, you can open Keymob Assistant’s real-time logs while operating the App.

When a crash occurs, you can see the log output before the crash and whether there are any abnormal prompts.
Real-Time Logs

Looking at Crash Logs Alone

In practical work, crash logs are just a result.

Truly complete analysis requires:

  • Crash logs (result)
  • Real-time logs (process)
  • Business logic (context)

Only by combining all three does it make sense.

Some Common Pitfalls

In practice, several points are particularly prone to issues:

  • dSYM mismatch
  • Analyzing the wrong thread
  • Ignoring pre-crash logs

These problems can lead to completely wrong analysis directions.

Reference link: https://keymob.com/blog/175