Introduction

NSZombie is an Objective-C debugging feature that helps you catch messages sent to objects that have already been deallocated. Instead of freeing the object normally, the runtime turns it into a zombie object so the crash report can tell you what dead object was touched.

What problem it helps diagnose

A classic Objective-C memory bug is "message sent to deallocated instance." Without special tooling, the app often crashes in a confusing way because the memory for that object may already be reused for something else.

With zombies enabled, deallocated Objective-C objects are not immediately reclaimed in the usual way. They become placeholders that remember the original class. If code later sends a message to that dead object, the runtime reports a zombie access and tells you which type was involved.

That turns a vague crash into a much more actionable debugging signal.

How to enable it

In Xcode, you typically enable zombies from the scheme diagnostics for the app you are running. Under the hood, the well-known environment variable is NSZombieEnabled=YES.

The workflow is simple: run the app with zombies enabled, reproduce the crash, and inspect the console or debugger output. The message usually names the deallocated object class and the selector that was sent afterward.

A small example

The following Objective-C example shows the kind of bug zombies are meant to expose. The exact crash timing depends on runtime behavior, but the pattern is the key idea: a pointer is used after the object lifetime has ended.

1@interface Worker : NSObject
2- (void)run;
3@end
4
5@implementation Worker
6- (void)run {
7    NSLog(@"running");
8}
9@end
10
11void example(void) {
12    Worker *worker = [[Worker alloc] init];
13    __unsafe_unretained Worker *dangling = worker;
14    worker = nil;
15
16    // In real buggy code the object may be deallocated before this call.
17    [dangling run];
18}

Without zombies, that kind of bug may appear as a hard-to-read memory crash. With zombies, the runtime can stop and tell you that a message was sent to a deallocated Worker.

What zombies do not do

NSZombie is for debugging, not for fixing the root cause. The actual bug is still a lifetime problem such as over-release in manual memory management, a broken ownership rule, misuse of __unsafe_unretained, or an object being referenced after its owner goes away.

Zombies also do not belong in production. Because deallocated objects are kept around for diagnosis, memory usage rises sharply. That is acceptable for debugging sessions and unacceptable for normal app execution.

ARC, retain cycles, and zombies

Under ARC, you can still hit zombie-style bugs. ARC prevents many manual retain and release mistakes, but it does not protect you from every lifetime error. For example, a non-owning reference may outlive the object it points to.

At the same time, do not confuse zombie crashes with retain cycles. A retain cycle keeps an object alive too long, so it never becomes a zombie in the first place. Zombies help when the object died too early and someone still talks to it afterward.

Common Pitfalls

• Treating NSZombie as a production feature instead of a debugging aid.
• Forgetting that enabling zombies increases memory usage significantly.
• Assuming ARC makes zombie-related bugs impossible.
• Using zombie reports to patch symptoms instead of tracing the ownership bug that caused the dead reference.
• Confusing over-retention problems with zombie problems, even though they are opposite lifetime failures.

Summary

• 'NSZombie helps diagnose messages sent to deallocated Objective-C objects.'
• It works by turning freed objects into zombie placeholders during debugging.
• The main value is better crash information, especially the original object class.
• Zombies are useful in development only because they increase memory usage.
• The real fix is to correct the ownership or lifetime bug that caused the dead reference.