Fundamentals of Memory Management

Mobile operating systems impose strict constraints on application memory usage. When an app's memory footprint approaches the system limit, the OS issues low-memory warnings. Failure to free up unused resources—such as objects or variables that are no longer needed—can lead to the application being terminated by the system. In Objective-C, memory management specifically applies to objects that inherit from NSObject. Primitive data types (int, char, float, struct, enum) are handled by stack allocation and do not require manual management.

Every Objective-C object contains an internal reference counter, typically a 4-byte integer. This counter tracks the number of owners holding a reference to the object. When an object is initialized using alloc, new, or copy, its reference count starts at 1. If the count drops to 0, the system reclaims the memory immediately. Conversely, as long as the count is greater than 0, the memory remains allocated.

To manipulate this lifecycle, developers send specific messages to objects:

• retain: Increments the reference count by 1 and returns the object reference.
• release: Decrements the reference count by 1.
• retainCount: Returns the current value of the reference counter.

When an object's count reaches zero, the system automatically invokes the dealloc method. It is common practice to override dealloc to release specific resources held by the object. However, [super dealloc] must be the very last call in this overridden method. Explicitly calling dealloc is forbidden; accessing memory after an object has been deallocated results in a "dangling pointer" error and application crashes.

Xcode Configuration for MRR

To implement manual memory management (MRR), Automatic Reference Counting (ARC) must be disabled. This is usually set during project creation by unchecking the "Use Automatic Reference Counting" option.

For debugging, enabling "Zombie Objects" in Xcode's scheme settings is highly recommended. By default, accessing freed memory does not immediately crash the app. Enabling this feature flags accessed deallocated objects as "zombies," allowing developers to trace the exact source of invalid memory access.

Core Memory Management Rules

The governing principle of memory management is ownership: an object must not be deallocated while it is still needed. This logic relies on a balance of increments and decrements.

1. The Creation Rule:
If you create an object using alloc, new, copy, or mutableCopy, you own it and are responsible for releasing it (via release or autorelease). If you did not create the object, you should not attempt to release it.

2. The Retain Rule:
If you take ownership of an object by sending it a retain message, you must relinquish that ownership with a corresponding release or autorelease when you are finished with it.

In summary, every operation that increases the reference count must be matched by a corresponding operation that decreases it.

Implementing Setter Methods

When a class contains a property that points to another Objective-C object, the setter method must handle memory management correctly to prevent leaks or dangling pointers. Consider a class with a member variable Device *_activeDevice.

The correct implementation for the setter involves:

1. Checking if the new value is the same as the existing one (self-assignment).
2. Releasing the old object.
3. Retaining the new object and assigning it to the instance variable.

- (void)setActiveDevice:(Device *)newDevice {
    if (newDevice != _activeDevice) {
        [_activeDevice release];
        _activeDevice = [newDevice retain];
    }
}

Consequently, the dealloc method must release the owned property:

- (void)dealloc {
    [_activeDevice release];
    [super dealloc];
}

Property Attributes

The @property directive allows developers to synthesize accessor methods with specific memory management semantics.

Memory Management Parameters:

• assign: Performs a simple direct assignment. This is the default for non-object types (like CGFloat or NSInteger) and is used for delegate properties to avoid retain cycles.
• retain: Releases the old value and retains the new value. Used for Objective-C object properties.
• copy: Releases the old value and creates a copy of the new value. This is standard for NSString properties to ensure immutability.

Read/Write Permissions:

• readwrite: Generates both getter and setter methods (default).
• readonly: Generates only a getter method.

Atomicity:

• atomic: Ensures thread-safe access to the property (default), but incurs a performance penalty.
• nonatomic: Removes the thread-safety guarantee for significantly faster performance. This is preferred for UI applications.

Accessor Names:

• setter=: Customizes the setter method name.
• getter=: Customizes the getter method name (useful for boolean properties).

Resolving Circular References

Circular references, or retain cycles, occur when two objects hold strong references to each other. For example, if Object A retains Object B, and Object B retains Object A, their reference counts will never reach zero, causing a memory leak.

Forward Declaration (@class):
To allow classes to reference each other in header files without causing circular import dependencies, use the @class directive. This tells the compiler that a symbol is a class name without loading its full definition. In the implementation file (.m), the #import statement should be used where methods or properties of the class are actually accessed.

Solution:
To break a retain cycle, one side of the relationship must use a weak reference. In MRR, this is achieved by using the assign property attribute instead of retain for the "back pointer" (usually the child pointing to the parent).

Autorelease Pools

The autorelease mechanism provides a way to defer the release of an object. Sending an autorelease message adds the object to the innermost active NSAutoreleasePool. When the pool is drained or destroyed, it sends a release message to every object within it. This does not change the reference count immediately; it simply shifts the responsibility of the release call to the pool.

Creating Pools:
Modern Objective-C (iOS 5.0+) uses the block syntax:

@autoreleasepool {
    // Code creating autoreleased objects
}

Legacy code (pre-iOS 5) used NSAutoreleasePool instances:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// Code
[pool drain];

Usage Patterns:
Instead of manually allocating and immediately releasing an object:

Device *device = [[Device alloc] init];
[device release];

Its often convenient to use autorelease for temporary objects:

Device *device = [[[Device alloc] init] autorelease];

Furthermore, class factory methods typically return autoreleased objects, allowing the caller to use the instance without worrying about ownership transfer:

+ (id)createDevice {
    return [[[Device alloc] init] autorelease];
}

Any object not created explicitly via alloc, new, copy, or mutableCopy is generally autoreleased. Examples include convenience constructors like [NSNumber numberWithInt:] or [NSString stringWithFormat:].