Objective-C Quick Reference

Analogy categoryAnalogies

Core Syntax at a Glance

Objective-C interface declarations live in .h files and start with @interface ClassName : SuperClass, listing properties and method signatures, while the implementation in the matching .m file starts with @implementation ClassName and contains the actual method bodies. Method signatures use a minus sign for instance methods and a plus sign for class methods, with colon-separated, labeled parameters such as - (void)setTitle:(NSString *)title forState:(UIControlState)state, which reads almost like a sentence describing what the call does.

🏏

Cricket analogy: The .h/.m split is like a team sheet published before the match, listing the squad and roles, versus the actual on-field performance recorded afterward, one declares intent, the other records what happened.

Common Foundation Types and Literals

Objective-C's literal syntax makes Foundation collections quick to write: @"a string" creates an NSString, @[obj1, obj2] creates an NSArray, @{key: value} creates an NSDictionary, and @42 or @3.14 box primitive numbers into NSNumber. Mutable variants (NSMutableArray, NSMutableDictionary, NSMutableString) allow in-place modification, while their immutable counterparts (NSArray, NSDictionary, NSString) are safer defaults for properties since they can't be changed out from under you after creation.

🏏

Cricket analogy: An immutable NSArray is like a finalized scorecard once the match ends, fixed and official, while a mutable NSMutableArray is like the live scoreboard during play, still being updated ball by ball.

objectivec

// Literals
NSString *name = @"Ada";
NSArray<NSNumber *> *scores = @[@95, @88, @76];
NSDictionary<NSString *, id> *user = @{ @"name": name, @"age": @29 };
NSNumber *count = @(scores.count); // boxing an expression

// Mutable variants
NSMutableArray *tasks = [NSMutableArray array];
[tasks addObject:@"Write tests"];
[tasks removeObjectAtIndex:0];

// Fast enumeration
for (NSString *task in tasks) {
    NSLog(@"%@", task);
}

Property Attributes and Common Idioms

Property declarations combine atomicity (atomic is the default, nonatomic is faster and standard for UI-thread-only properties), ownership (strong, weak, copy, assign), and access (readwrite, readonly). A property like @property (nonatomic, copy) NSString *name; is the idiomatic default for a string, while @property (nonatomic, weak) id<SomeDelegate> delegate; is the idiomatic default for a delegate reference to avoid retain cycles. Blocks are typically declared with copy since, historically, block storage needed to be explicitly moved from the stack to the heap, and copy remains the conventional attribute even though ARC now handles this automatically in most cases.

🏏

Cricket analogy: Choosing nonatomic over atomic for UI properties is like a scorer updating a scoreboard without pausing play to double-check every entry against a second official, faster, and safe enough when only one thread of play is happening at a time.

Quick default cheat sheet: NSString/NSArray/NSDictionary properties → copy. Delegates → weak. Blocks stored as properties → copy. Plain objects you own and control → strong. Primitives (int, BOOL, CGFloat) → assign (the implicit default for non-object types).

@interface/@implementation split declarations (.h) from method bodies (.m); minus is instance methods, plus is class methods.
Literal syntax (@"...", @[...], @{...}, @42) quickly creates NSString, NSArray, NSDictionary, and NSNumber instances.
Prefer immutable types (NSArray, NSString, NSDictionary) for properties; use mutable variants only when in-place modification is needed.
Default property attributes: copy for strings/arrays/blocks, weak for delegates, strong for owned objects, assign for primitives.
nonatomic is the standard choice for properties accessed only on the main thread; atomic adds overhead most apps don't need.
Fast enumeration (for (Type *x in collection)) is the idiomatic way to iterate Foundation collections.
readonly/readwrite controls external mutability of a property independent of its internal storage.