Article: The iOS Crash We Could Not Reproduce

The article recounts an investigative journey into a peculiar iOS crash that resisted local reproduction attempts. The application in question was a large-scale consumer product that experienced the crash on only a subset of executions, making it difficult to reproduce consistently. The crash was reported through a SIGBUS signal, which is a low-level invalid memory access signal, but it did not provide a clear indication of the faulty variable.

The final code change was minor, yet finding it required transforming a vague SIGBUS report into a series of controlled experiments. Throughout the investigation, various factors such as object lifetime, SwiftUI view model ownership, shared mutable state, and Foundation behavior were considered, but none led to a definitive cause.

The team first addressed common issues like zombie objects, exception breakpoints, and ownership around the affected screens. They also made defensive improvements, including tightening observable object ownership, reviewing reference types for identity semantics, clarifying synchronization, and making UI-related concurrency more explicit.

While these changes resulted in a reduction of the overall crash rate, the original crash signature persisted in production, indicating that the defect had not been fully resolved. The turning point came when a QA engineer discovered a way to trigger the crash by repeating the affected flow. This provided a practical test oracle, allowing the team to validate their changes more effectively.

The investigation process involved iterative changes, IPA builds, and repeated attempts on the affected device. After several rounds of experimentation, the failure surface narrowed down to a single file, where the culprit was identified: a line of code converting HTML data into an attributed string. Despite its seemingly innocuous appearance, this operation proved to be the root cause of the crash.