How to investigate the Apple Unified Log

To investigate the Apple Unified Log, work through these steps:

1. Collect a logarchive from the device as early as possible, preferably with log collect on a Mac.
2. Convert it to JSON with log show.
3. Narrow it down to a time window and the relevant subsystems.
4. Interpret the entries as a sequence, anchored to something outside the log.

This page walks through that workflow as I use it, with the commands and the mistakes I see most often. If you are new to the log itself, start with what the Apple Unified Log is.

1. Acquire early

The Unified Log keeps overwriting itself for as long as the device is switched on. In my tests an iPhone held 14 days of history through log collect and only 2 days through a sysdiagnose. Every day between seizure and acquisition costs you data you will not get back. I would put Unified Log acquisition in the first response, not in the lab queue.

Write down the acquisition time, the device’s time zone and a hash of the resulting logarchive. You will need all three later, when timestamps are questioned.

2. Choose your acquisition method

With the device unlocked and paired to a Mac, log collect gives the longest time window:

sudo log collect --device --output ~/case-001.logarchive

The full procedure is in Acquiring the Apple Unified Log via Terminal.

You have three other options:

• A sysdiagnose. You trigger it on the device itself, for example through AssistiveTouch, and then pull it off. It contains a logarchive plus other diagnostic files, but covers a much shorter period.
• Dedicated tools. Tools such as UFADE by Christian Peter handle collection for you, including on Windows.
• A full file system extraction. You can rebuild the log from the diagnostics and uuidtext folders, plus an Info.plist, in a folder ending in .logarchive.

My preference is log collect first, then a sysdiagnose if you can, because the sysdiagnose contains more than just the log. For the numbers behind that choice, see Apple Unified Log or sysdiagnose?

3. Convert and filter

log show reads a logarchive and exports it. Always export to JSON, because it keeps every field and every microsecond:

log show --info --debug --archive case-001.logarchive --style json 

Do not search the full export. An iPhone logarchive in my tests held more than 23 million events. Start with a time window around the moment you are investigating:

log show --info --debug --archive case-001.logarchive --style json > case-001.json--archive case-001.logarchive --style json \
  --start "2026-09-18 08:00:00" --end "2026-09-18 10:00:00"

Then narrow down by subsystem or category with a predicate:

log show --info --debug --archive case-001.logarchive --style json \
  --predicate 'subsystem == "com.apple.UIKit" AND category == "KeyboardTouch"'

Once you have JSON, you can work in Python, jq, Elasticsearch or your forensic suite of choice. Be careful with spreadsheets: Excel does not keep microsecond precision in timestamps, so keep the original JSON as your reference. The commands I use most are in the CLI cheatsheet.

4. Look for known artifacts

These are the artifacts I have documented and validated on my own reference devices:

Activity	Platform	Documented in
Touch ID unlock	macOS	#16
Touch ID, password and failed match	macOS	#26
Touch ID, passcode and Home button	iOS 12	#10
Screen touches	iOS	#14
On-screen keyboard	iOS	#17
Volume buttons	iOS	#8
Airplane mode	iOS 26	#13
Crown and side button	watchOS	#18
Emergency SOS	iOS, cross-device	#19
CarPlay connection	iOS	#20
Dialed phone number	iOS	#24
Unlock retention, busy vs idle iPhone	iOS 26	#28

Lionel Notari keeps another good collection at ios-unifiedlogs.com. Whichever source you use, an artifact documented on one iOS version is a lead on another version, not a fact. Reproduce it on a reference device running the same version before you rely on it.

5. Interpret the entries as a sequence

Finding the right log line is the easy part. Explaining what it proves is where reports go wrong. I use the Anchored Log Reconstruction (ALR) method, built on these principles:

1. Read the log by evidential strength, not by timestamp. The less aware the user was that an action would be logged, the harder the entry is to dispute.
2. The anchor comes from outside the log. Tie the sequence to something independently verifiable, such as the time of a collision, a time of death or a witness statement.
3. Proximity is not causality. Two entries a few hundred microseconds apart can still be unrelated.
4. Reason backward from a provable endpoint. Start at what you can prove and work back from there, instead of forward from what you expect.

Mistakes I see most often

1. Waiting weeks before acquiring the log.
2. Relying only on a sysdiagnose.
3. Searching the entire log for a keyword without a time window.
4. Ignoring the UTC offset in timestamps.
5. Reading <private> as “nothing happened”.
6. Reporting a single log line as proof of what a person did.

Frequently asked questions

Do I need a Mac?

For log collect and log show, yes. For analysis after the JSON export, no.

Does the device need to be unlocked?

To collect the log from a live iPhone, yes. The device has to be unlocked and paired with the computer.

How much data should I expect?

In my tests an iPhone produced more than 23 million entries over 14 days. Plan your filtering before you open the file.

Can the Unified Log prove who used a device?

Not by itself. It shows what the device did. Linking that to a person requires an anchor from outside the log.

About the author

Tim Korver has worked in digital forensics and incident response in law enforcement for more than 14 years. He developed the Anchored Log Reconstruction (ALR) method and publishes his Unified Log research every Friday on Thesis Friday. All log data on this site comes from his own reference devices.