How to Analyze App Crash Logs: Process of Obtaining .ips Files and Locating Code

This article explains how to analyze App crash logs, combining practical engineering experience to detail the complete process from obtaining iOS crash logs, symbolization, to call stack analysis. By using Keymob Assistant to export logs and real-time logs for auxiliary analysis, it demonstrates how to transform crash information into specific code issues, providing developers with an actionable method for crash troubleshooting.

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

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