ios-logging

iOS Production Error Observability

Production-grade skill for eliminating silent failures in iOS apps. Most production errors don't crash — they vanish through try?, Task {}, .replaceError(), and print()-only catch blocks.

AI coding assistants systematically generate observability-blind code because their training data is overwhelmingly tutorial code: print(error) in every catch block, try? everywhere, Task {} with no error handling, no crash SDK integration, no privacy annotations, and zero consideration for MetricKit or PII compliance. This skill intercepts those patterns and enforces observable error handling from the start.

Logging is the key to debugging. When a bug appears in production across thousands of devices, you can't attach a debugger. Remote logging through crash reporting SDKs transforms a 3-day debugging mystery into a 15-minute investigation. This skill enforces observable error handling: every error is logged with os.Logger (with privacy annotations), reported to a remote crash/analytics SDK, and surfaced to the user or operator.

Three non-negotiable rules:

1. No print() in production code — use Logger with privacy annotations
2. No catch block without observability — every caught error must be logged; unexpected errors must also be reported to a remote crash SDK
3. No try? on operations where failure matters — use do/catch for network, persistence, auth, and user-facing operations

Expected vs unexpected errors — don't flood your crash dashboard

Not every caught error is a bug. Reporting every error to the crash SDK makes dashboards useless because real signals drown in noise. Split errors into two buckets: