iOS-Logsammlung: 7 Wege für das Debugging

Debugging von iOS-Apps: 7 Methoden zum Sammeln von Systemlogs

iOS-Logs erfassen interne App-Ereignisse: Netzwerkanfragen, Fehler, UI-Frieringen und Abstürze. Sie helfen, Probleme ohne visuelle Hinweise präzise zu lokalisieren. Beispiele: EXC_BAD_ACCESS in Pokemon GO, I/O auf dem Hauptthread in Console und CFNetwork-Timeouts in log collect.

Logs werden in Absturzberichte (EXC_BAD_ACCESS, SIGSEGV) und diagnostische Berichte (Leistung, Netzwerk, Speicher) unterteilt. Tester nutzen sie, um Funktionsaufrufe zu überprüfen, Serverinteraktionen zu analysieren und versteckte Bugs aufzudecken.

.ips-Dateien über sysdiagnose

Automatisch generierte Berichte finden sich unter Einstellungen → Datenschutz & Sicherheit → Analyse & Verbesserungen → Analysedaten. Format: event_type_date_time.ips, z. B. AtiClient-2024-08-14-152242.ips.

Berichtstypen:

• CrashReport: Ausnahmen und Signale (nach Bundle-ID, z. B. VKClient).
• JetsamEvent: Entladen aufgrund von RAM-Mangel (Speicherlecks).
• Watchdog: Start-Timeouts oder Hänger.
• SpinReport: Hohe CPU-Auslastung ohne Reaktion (Deadlocks).
• NotificationServiceExtension: Fehler bei Push-Benachrichtigungen.

Manuelle Erzeugung: Gleichzeitig Lautstärketasten + Seitenknopf drücken (1–1,5 s), Datei stacks.

Export über AirDrop. Dateien werden automatisch gelöscht – sofort sammeln.

Anwendungsfälle: Ausfälle ohne Xcode, Speicher-/Netzwerk-Analyse.

log collect CLI: Kommandozeilen-Tool für Archive

Erfordert Xcode Command Line Tools, USB-Verbindung, Terminal. Ermittelt UDID über libimobiledevice.

Sammelt Logs für bis zu 10 Tage (vs. sysdiagnose – Momentaufnahme). Schneller, automatisierbar, Größe steuerbar.

Grundbefehl:

sudo log collect --device-udid <UDID> --last 10m --output iphone_logs.logarchive

Wichtige Parameter:

• --output ~/Desktop/iphone_logs.logarchive — Speicherpfad.
• --last 30m / 2h / 1d — Zeitraum.
• --start "2025-08-20" --end "2025-08-20 14:30:00" — Daten.
• --size 100m — Größenlimit.
• --device-udid A1B2C3D4R5F8G8H8I1J0 — nach UDID (bevorzugt).

Analyse:

log show --archive system_logs.logarchive --predicate 'process == "AtiClient" AND messageType == "error"'

Filter: Prozess, Fehler, Zeitraum.

Vergleich mit sysdiagnose:

| Parameter | log collect | sysdiagnose |

|----------|-------------|-------------|

| Zeit | bis 10 Tage | Tag der Erstellung |

| Automatisierung | CLI | manuell |

| Größe | steuerbar | groß |

| Geschwindigkeit | schnell | 10–15 Min. |

Anwendungsfälle: Instabile Bugs, Leistungstrends, Absturz-Kontext.

Console: Live-Überwachung

Xcode → Fenster → Geräte und Simulatoren → Console öffnen. Filter nach Prozess (z. B. AtiClient). Zeigt Echtzeitdaten: Hang Risk auf dem Hauptthread, libRPAC.dylib-Fehler.

Beispiel-Log:

Hang Risk com.apple.runtime-issues
message: This method does I/O on the main thread...
libRPAC.dylib failure 19:12:18.350727+0300 AtiClient

Export zu .logarchive für Offline-Analyse.

Methoden 4–7: Erweiterte Sammlung

• Xcode Geräte und Simulatoren: Logs nach UDID, Filter nach Subsystem (CFNetwork, Jetsam).

• libimobiledevice: idevicesyslog für Streaming-Logs ohne Xcode.

idevicesyslog -u <UDID>

• os_log im Code: Benutzerdefinierte Logs via os_log_t und os_log-API. Stufen: debug, info, error.

• Instruments: Profiling mit Logs (Time Profiler, Leaks).

Wichtige Erkenntnisse

• .ips für sofortige Ausfälle (CrashReport, Jetsam).
• log collect für Langzeittrends (bis 10 Tage, CLI).
• Console für Live-Debugging von I/O auf dem Hauptthread.
• UDID für präzise Geräteansprache erforderlich.
• Methoden kombinieren: sysdiagnose + log show für vollständige Analyse.

— Editorial Team