Introduction

For iOS 5 era development, the best practice was already shifting toward ARC for new code, but many projects still used manual retain-release. If you are working in manual memory management, the core rule is simple: if you own an object because you created it, copied it, or retained it, you are responsible for releasing it later.

The Ownership Rule

Under manual retain-release, you own an object when you receive it through methods such as:

• 'alloc'
• 'new'
• 'copy'
• 'mutableCopy'
• 'retain'

Example:

NSString *name = [[NSString alloc] initWithString:@"Ava"];
// use name
[name release];

The release call is required because the code created an owned object.

Objects You Do Not Own

If a method returns an autoreleased object, you usually should not release it yourself.

NSString *message = [NSString stringWithFormat:@"Hello"];
NSLog(@"%@", message);

Here, you did not create or retain the string, so you should not call release on it.

Properties Matter

Property attributes express ownership intent. In manual memory management, a retained property is commonly declared like this:

@property (nonatomic, retain) NSString *titleText;

And in dealloc:

1- (void)dealloc {
2    [_titleText release];
3    [super dealloc];
4}

This keeps the property and deallocation logic aligned.

Avoid Over-Retain and Over-Release

Two classic mistakes are:

• Releasing an object you do not own
• Forgetting to release an object you do own

The first causes crashes. The second causes leaks.

That is why older Objective-C codebases often follow a strict ownership checklist rather than relying on memory-management intuition.

ARC Versus Manual Memory Management

By the iOS 5 timeframe, ARC was already the preferred choice for new code when the toolchain allowed it. ARC removes most direct retain, release, and autorelease calls by letting the compiler insert them automatically.

So the best-practice answer is:

• New code: prefer ARC
• Legacy non-ARC code: follow ownership rules rigorously and consistently

Understanding retain-release still matters because many older APIs, code samples, and legacy projects reflect those rules directly.

It also matters when reading old Objective-C explanations, because many "best practice" recommendations from that period were really ownership-rule reminders written for non-ARC codebases.

Example of a Balanced Pattern

1- (void)loadData {
2    NSMutableArray *items = [[NSMutableArray alloc] init];
3    [items addObject:@"One"];
4    [items addObject:@"Two"];
5
6    self.data = items;
7    [items release];
8}

This is correct because:

• 'items was created with alloc, so it is owned locally'
• Assigning to a retained property transfers ownership to the property
• The local ownership is then released

That pattern, create then hand off then release local ownership, is one of the most common manual-memory-management flows in older iOS code.

Common Pitfalls

• Releasing autoreleased objects that you never owned.
• Forgetting to release retained instance variables in dealloc.
• Mixing ARC and manual memory management rules mentally and applying the wrong one.
• Calling release too early while another part of the code still assumes ownership.

Summary

• In manual memory management, ownership determines whether you must release.
• If you alloc, copy, or retain, you must later release or autorelease.
• Do not release objects you did not own.
• Use ARC for new code when possible.
• For legacy iOS 5 era code, consistency with the ownership rules is the real best practice.

That consistency is what keeps old Objective-C code stable. It is also what makes old bugs easier to reason about.