Introduction

Objective-C inherits most of its variable declaration and definition rules from C, but it adds classes, instance state, properties, and file-level implementation structure. The correct location for a variable depends on what owns that state and how long the value is supposed to live.

Local Variables Belong Inside Methods

If a value is needed only during one method call, declare it locally inside that method.

1- (void)printTotal {
2    NSInteger count = 3;
3    CGFloat price = 19.5f;
4    CGFloat total = count * price;
5    NSLog(@"Total: %f", total);
6}

These variables:

• are visible only inside the method or block
• are created for that call
• are usually the clearest place for temporary calculations

If a value does not need to outlive the method, it usually should not be an instance variable or global.

Instance Variables Store Per-Object State

If the value belongs to each object instance, use an instance variable or, more commonly in modern Objective-C, a property backed by an instance variable.

Classic ivar style looks like this:

1@interface CartItem : NSObject {
2    NSString *_name;
3    NSInteger _quantity;
4}
5@end

Those variables exist as long as the object exists. They are appropriate when multiple instance methods need to read or update the same state.

Properties Are the Usual Public Interface

Modern Objective-C usually exposes object state through properties rather than raw ivars.

1@interface CartItem : NSObject
2
3@property (nonatomic, copy) NSString *name;
4@property (nonatomic, assign) NSInteger quantity;
5
6@end

@implementation CartItem
@end

The property declares the interface, and the compiler handles the backing ivar and accessor methods. This is usually the best choice when outside code needs controlled access to instance state.

So in practice:

• use ivars or synthesized storage for the state itself
• use properties for the interface to that state

File-Level Variables and static

If a variable belongs to the whole implementation file rather than to one object, declare it outside methods and classes.

A true global definition looks like this:

NSInteger GlobalCounter = 0;

That variable is visible across files if declared with extern elsewhere. Often that is more visibility than you actually want. A safer default is file-private state with static:

static NSInteger FilePrivateCounter = 0;

That limits visibility to the current .m file.

You can also use a function-level static variable when the value should persist across calls but remain hidden inside one method:

1- (void)incrementCallCount {
2    static NSInteger callCount = 0;
3    callCount += 1;
4    NSLog(@"Calls: %ld", (long)callCount);
5}

This persists between method calls even though it is declared inside the method.

Declaration Versus Definition

A declaration tells the compiler that a variable exists. A definition actually allocates storage for it.

When a global must be shared across files, define it in one implementation file and declare it with extern elsewhere.

// CounterStore.m
NSInteger GlobalCounter = 0;

// CounterStore.h
extern NSInteger GlobalCounter;

That pattern prevents multiple-definition linker errors while still making the variable available where it is needed.

Common Pitfalls

• Putting temporary values in ivars when a local variable would be clearer.
• Using globals for data that really belongs to one object instance.
• Exposing raw ivars when properties would provide a cleaner interface.
• Forgetting that a function-level static keeps state across calls.
• Defining the same global variable in more than one file instead of defining once and declaring with extern.

Summary

• Put short-lived temporary values inside methods as local variables.
• Put per-object state in instance variables or, more commonly, properties.
• Use file-level static for implementation-private shared state.
• Define globals once and use extern declarations when cross-file access is truly necessary.
• Choose the location based on ownership, visibility, and lifetime rather than habit.