iOS Crash Protection: Motivation, Process, and Implementation

0x1 Why Crash Protection is Needed

In product development, crash rate is a crucial metric that reflects both product quality and the overall technical capability of the team. A lower crash rate not only improves user reputation but also helps team members deepen their understanding of iOS internals, which benefits future development.

0x2 Why This Article Was Written

The author encountered a massive crash incident caused by an erroneous data payload from Facebook's SDK on 2020‑07‑10. The crash surge highlighted the lack of any protection or fault‑tolerance mechanisms in the app, forcing a slow, passive reliance on Facebook’s backend fix. This motivated the author to build a complete crash‑protection system, document existing solutions, and share the knowledge for future reference.

0x3 How to Do It

The original crash scenario was simple: a dictionary parameter from the backend was mistakenly a string, causing a crash during parsing. Adding a layer of parameter validation would have prevented it.

I: Crash Handling Process

The iOS crash handling workflow can be divided into four steps:

Crash Protection – use Hook or similar techniques to validate inputs of container‑like objects before they cause a crash.

Crash Interception – if protection fails, intercept the crash to make it observable.

Crash Reporting – generate useful logs and reports that preserve stack traces.

Post‑Crash Process – handle the crash gracefully to minimize impact on user experience.

II: Crash Protection Techniques

Two main approaches are used:

Non‑memory issues – apply AOP (Aspect‑Oriented Programming) to inject validation.

Memory issues – employ zombie objects to catch use‑after‑free errors.

AOP

AOP is widely used in iOS for method hooking, but it introduces several pitfalls:

Scope impact : Hooking NSArray/NSMutableArray methods caused crashes such as [UIKeyboardLayoutStar release]: message sent to deallocated instance UIKeyboardLayoutStar . The problem stemmed from HookNSMutableArr affecting system classes.

Variable lifetime : In multithreaded scenarios, variables passed to the injected function may be released before the original method runs, leading to double‑free crashes. The recommended fix is to perform hooking under MRC and wrap the hook in an autorelease pool.

Performance overhead : AOP adds an extra method‑call layer, which can degrade performance, especially in high‑frequency crash‑protection paths.

Typical AOP hook implementation:

+(void)hookClass:(Class)classObject isClassMetohd:(BOOL)classMethod fromSelector:(SEL)fromSelector toSelector:(SEL)toSelector {
    Class class = classObject;
    Method fromMethod = class_getInstanceMethod(class, fromSelector);
    Method toMethod = class_getInstanceMethod(class, toSelector);
    // Add before checking
    if (classMethod) {
        class = object_getClass(classObject);
        fromMethod = class_getClassMethod(class, fromSelector);
        toMethod = class_getClassMethod(class, toSelector);
    }
    if(class_addMethod(class, fromSelector, method_getImplementation(toMethod), method_getTypeEncoding(toMethod))) {
        class_replaceMethod(class, toSelector, method_getImplementation(fromMethod), method_getTypeEncoding(fromMethod));
    } else {
        method_exchangeImplementations(fromMethod, toMethod);
    }
}

Calling the original implementation after swapping can be done via the stored IMP pointer, which is faster than the Objective‑C message dispatch.

Zombie Objects

Apple recommends using zombie objects to catch memory‑related crashes. However, enabling zombies in production requires careful handling:

Zombie entry point : Creating zombies in dealloc is discouraged under ARC; the author chose to generate zombies in a custom free function to avoid missing Objc_destructInstance calls.

Memory threshold : Zombies consume memory, so a dynamic threshold must be defined. The author derived formulas: Y = 0.5 * deviceMem – currentAppMem to ensure the app does not trigger a memory‑warning, and: Y = min( (0.5 * deviceMem – currentAppMem), currentAppMem) for the maximum zombie memory usage. A further refinement introduces a factor N to adjust based on online crash statistics: Y = min( (0.5 * deviceMem – currentAppMem), currentAppMem / N ) The value of N can be updated remotely, allowing the app to adapt to different device models and crash volumes.

Update strategy : When a new zombie is added, the system checks the threshold; if exceeded, older zombies are removed. To avoid stale zombies, a LRU‑like cleanup runs every 30 seconds, deleting zombies not accessed within that window.

Instrument tests showed that this zombie management adds negligible memory overhead.

In summary, this article covered the crash‑handling workflow, AOP‑based protection, and zombie‑based memory protection, along with practical formulas and strategies for safe deployment in iOS applications.