Every iPhone carries a "black box" called sysdiagnose — a system diagnostic archive that Apple engineers reach for first when something goes wrong. Squeeze two volume buttons and the side button for about a second, and iOS quietly records one in the background. Once compressed it is still hundreds of megabytes, packed with ioreg, smcDiagnose, taskinfo, crash reports, and battery-chemistry data.

The catch: it was never meant for you. Unpacked, it is thousands of files and tens of thousands of lines of plain text. The value you want is buried on line 10,000 of IODeviceTree.txt or inside some NVMe controller node in IOService.txt. Even an experienced developer needs ten minutes just to find it.

Device Status⁺ turns that wall of text into a screen of readable cards — entirely on-device, without uploading a single byte. This guide walks through how its Diagnostic Log Analyzer works, from capturing a sysdiagnose to reading the cards, and why it won't crash your phone doing it.

What is Device Status⁺?

Device Status⁺ is a free system-monitoring app by Space-Time Transformation Technology Co., Ltd. It requires iOS 17.0+ and runs on iPhone, iPad, Mac (M-series), Apple Vision Pro, and Apple Watch. Alongside real-time CPU, memory, storage, battery, and network dashboards, it ships a dedicated Diagnostic Log Analyzer for sysdiagnose archives and a Battery Log Analyzer for daily battery analytics (covered in a separate guide).

Everything described below happens locally. The import screen states it plainly: "All processing happens on-device. Nothing is uploaded."

What Exactly Is a sysdiagnose?

A sysdiagnose is a point-in-time snapshot of the entire system. Triggered by the hardware key combo, it collects:

• ioreg device tree dumps (IODeviceTree.txt, IOService.txt)
• SMC (System Management Controller) readings and smcDiagnose
• taskinfo process snapshots
• Aggregated crash reports (.ips)
• Battery-chemistry plists and NAND wear snapshots
• Network, Wi-Fi, and Bluetooth state

The result is a sysdiagnose_YYYY.MM.DD-...tar.gz that, extracted, can contain 2,400+ entries with PAX extended headers. On a memory-constrained iPhone, the obvious approach — "read it all into memory, then decompress" — blows up with an OOM. So the analyzer does not do that.

Step 1: Capture the sysdiagnose

The hardest part is not the analysis. It is getting the file. Device Status⁺ ships an illustrated guide (LogCollectionGuideView) that walks you through every tap:

1. Press and hold both volume buttons + the side button for about one second, release after the haptic — this triggers the sysdiagnose.
2. Keep using the phone normally and wait roughly 10 minutes for collection to finish.
3. Open Settings → Privacy & Security → Analytics & Improvements → Analytics Data and search for sysdiagnose.
4. Open the file → Share → Save to Files → back in Device Status⁺, tap + to import.

To shave the "find the entry" step to nothing, the guide offers two one-tap shortcuts: install a Shortcut (iCloud link) and jump straight to the Analytics & Improvements pane via a Shortcuts scheme.

Step 2: Import without the memory crash

This is where the engineering earns its keep. The SysdiagnoseArchiveExtractor runs a two-stage streaming pipeline that chews through an 800 MB archive with only a few kilobytes of buffer memory.

Stage 1 — gunzip. Using zlib with inflateInit2(16 + MAX_WBITS) for gzip-aware decoding, the input file is mmap-ed (paged in on demand, never resident) and output is written to a temporary .tar in 64 KB blocks. Peak memory is just the buffer.

Stage 2 — untar. A hand-written state machine parses USTAR / GNU / PAX headers entry by entry and writes each one to disk. It supports GNU long filenames (the L type), per-entry and global PAX extended headers (x / g), and base-256 size fields. The archive is never held in full.

The robustness details matter just as much:

• Disk-space pre-check. After gunzip, once the exact .tar size is known, the analyzer checks volumeAvailableCapacity for "one tar + a safety margin" before proceeding — no half-extracted archive blowing up your storage.
• Path safety. isSafeRelativePath rejects absolute paths, embedded \0, and .. traversal. Nothing writes outside the sandbox.
• Integrity checks. CRC and ISIZE validation is left to zlib; a truncated or corrupt gzip surfaces as a readable error (inflateFailed / truncatedArchive), not a silent hang.
• Temporary .tar always cleaned. A defer removes it win or lose, so no hundreds-of-megabytes garbage is left behind.

During extraction the UI shows a progress overlay that distinguishes "decompressing gzip (expanded N MB)" from "extracted N files" — giving you certainty it is actually working.

One-tap import via the Share Extension

You can skip the Files round-trip entirely. The sharelog extension recognizes a sysdiagnose_*.tar.gz straight from the Analytics Data list. Crucially, the extension does no parsing — its memory budget is far too small to inflate a sysdiagnose. It only copies the file into the App Group container (ShareInbox/), writes a pending signal to App Group UserDefaults, and wakes the host app via the devicestatus URL scheme. The host then runs the memory-heavy extraction. The result feels like one tap.

Step 3: Read the device overview

SysdiagnoseOverviewParser pieces together the device's identity from three sources:

• The first Properties: {…} block in remotectl_dumpstate.txt → model, OS, serial number, UDID, ChipID, SoC platform, region code…
• "product-name" in ioreg/IOService.txt → marketing name (e.g. iPhone 17), with a built-in ProductType→name fallback.
• The root folder name → capture timestamp (supporting both +0800 offset and local-time formats).

Every field keeps both its raw key and a friendly label (e.g. ChipID / 33104), so you can cross-check a card against the original log line.

Step 4: Explore the seven categories

This is the core product decision: no raw text dumps, only the key metrics extracted from each file as cards. SysdiagnoseCategoryConfig maps the thousands of files into seven mutually exclusive categories, listing only files that have a dedicated extractor. That is why the badge number equals the number of cards you will actually see — you never tap in and find nothing.

The details only an insider would extract

• Battery chemistry (ACAM). It parses com.apple.batteryintelligence.batteryalgorithms-OnDeviceACAM-state.plist into three cards:
  • Battery Identity — cell serial number, whether it is original, charge-voltage limit.
  • Active Material — active-material retention (QLi / Qn / Qp: the usable fraction of lithium ions / anode / cathode).
  • Aging & Resistance — SEI growth, crack / phase-change loss, electrode resistance. These are the microscopic-health metrics that normally live only in Apple's internal tools.
• Storage hardware (NVMe + NAND). From the NVMe controller node in IOService.txt it pulls cell type (SLC / MLC / TLC / QLC), page size, firmware version, read/write Operations and Errors. From ASPSnapshots/asptool_snapshot.log it pulls NAND boot / power-cycle counts, lifetime read/write amounts, wear leveling, and Band distribution. In other words: which NAND cell type you have, how much it has been written, and how much life remains.
• Chip identification. The chip-id in IODeviceTree is little-endian hex; the extractor converts it to the engineering-friendly "T number" (e.g. T8130), translating opaque hex into a readable silicon codename.

Extraction techniques worth knowing

• Big files bypass the preview cap. taskinfo, IODeviceTree.txt, IOService.txt, and asptool_snapshot.log sit far beyond the 4,000-line preview limit. Extractors read the full file before parsing, so the power-draw ranking, chip nodes, NVMe controller, and NAND health are never missed.
• Multi-file folding. Daily battery-cycle CSVs (BDC_Daily_*.csv) collapse into one "battery cycles" card (latest value); every .ips crash folds into one aggregated "crash reports" card.
• Cross-file correlation. Cycle count is read both from SMC's current B0CT value and from BDC history, then compared.

History and persistence

Each import lands under Application Support/SysdiagnoseCases/<serial_timestamp>, with metadata in SysdiagnoseHistoryStore. Re-importing the same archive reuses the existing extraction (deduped by caseId). The list supports swipe-to-delete and clear-all, and reopens instantly — because it re-parses only the overview, never re-runs the extraction.

Three promises built in

1. Fully offline, on-device. From decompression to extraction, no network request is made.
2. Readability over performance. The endpoint of every parse is a card, not the raw text. Original fields are retained for cross-checking but hidden by default.
3. Production-grade robustness:
   • Path-traversal protection, disk-space pre-check, tar-header validation, guaranteed temp cleanup.
   • File-render guardrails: SysdiagnoseFileContent caps text at 512 KB / 4,000 lines and CSV at 1,000 lines; extractors read full files as a fallback, so a single file can never blow up memory.
   • Human-readable error translation (turning inflateFailed into "the archive is damaged or the download was incomplete").
   • Cross-launch path compatibility (handling both new relative paths and legacy absolute sandbox paths).

Final thoughts

The Diagnostic Log Analyzer does not try to show all 2,000+ files in a sysdiagnose. It answers the questions you actually ask — What hardware am I running? Is my battery healthy? How worn is my storage? Why did it crash recently? — and gives you clean, shareable, verifiable answers.

Capture is guided, import is one tap, decompression never starves memory, and the screen shows only cards. For the long-term companion — daily battery-health trends from Analytics logs — see the Battery Log Analyzer guide.