100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Classes and Objects in Objective-C

How Objective-C classes are declared with @interface/@implementation, and how objects are created via alloc and init.

OOP in Objective-CIntermediate9 min readJul 10, 2026
Analogies

Classes and Objects in Objective-C

A class in Objective-C is a blueprint that bundles state (instance variables and properties) with behavior (methods) into a single named type, declared with @interface ClassName : SuperClass ... @end and implemented with @implementation ClassName ... @end. An object is a concrete instance of that blueprint created at runtime, and every object you create ultimately descends from NSObject, the root class that supplies baseline behavior like memory management hooks, description, and isEqual:.

🏏

Cricket analogy: Like the BCCI's central contract template that lists every player's required attributes, batting average, fielding position, contract grade, before a specific player like Virat Kohli is signed onto it, an @interface defines the blueprint before any Person object is created.

Declaring a Class: @interface and @implementation

A class declaration lists its superclass, its properties, and the signatures of its instance methods (prefixed with a minus sign) and class methods (prefixed with a plus sign) inside @interface...@end, while @implementation...@end supplies the actual method bodies matching those signatures. Every class Objective-C developers write, unless there is a specific reason not to, should ultimately inherit from NSObject either directly or through an intermediate superclass, since it is NSObject that provides alloc, init, and the fundamental object lifecycle machinery the runtime depends on.

🏏

Cricket analogy: Like a scorecard header listing a player's name and role before the ball-by-ball commentary describes what actually happens, @interface lists a class's method signatures before @implementation supplies what each method actually does.

Creating Objects: alloc, init, and self

An object is created in two distinct steps combined into one idiomatic call, [[Person alloc] init]: alloc asks the class to allocate enough zeroed memory for a new instance and returns a pointer to it, while init, called on that fresh instance, sets up its initial state and returns self, the pointer to the object that received the message. Inside an init method, self refers to the instance currently being initialized, and the standard pattern self = [super init]; if (self) { ... } return self; ensures the superclass's own initialization ran successfully before this class configures its own instance variables.

🏏

Cricket analogy: Like a stadium first allocating an empty seat block for a new corporate box (alloc) before an usher actually furnishes it with chairs and a scoreboard feed (init), object creation first allocates memory before init configures it.

objectivec
// Car.h
#import <Foundation/Foundation.h>

@interface Car : NSObject

@property (nonatomic, copy) NSString *make;
@property (nonatomic, assign) NSInteger topSpeed;

- (instancetype)initWithMake:(NSString *)make topSpeed:(NSInteger)topSpeed;
- (void)describe;

@end

// Car.m
#import "Car.h"

@implementation Car

- (instancetype)initWithMake:(NSString *)make topSpeed:(NSInteger)topSpeed {
    self = [super init];
    if (self) {
        _make = [make copy];
        _topSpeed = topSpeed;
    }
    return self;
}

- (void)describe {
    NSLog(@"%@ has a top speed of %ld mph.", self.make, (long)self.topSpeed);
}

@end

// usage
Car *car = [[Car alloc] initWithMake:@"Aston Martin" topSpeed:200];
[car describe];

NSObject's own -init returns self and does very little else, so most custom classes override init (or a designated initializer like initWithMake:topSpeed:) to configure their own state, but they should still call [super init] first so any setup NSObject or an intermediate superclass performs happens before subclass-specific configuration runs.

Never call [Person new] and [[Person alloc] init] on the same object, and never call alloc without immediately following it with an init call; an allocated-but-uninitialized object has zeroed memory and can behave unpredictably if you send it messages before it's properly initialized.

  • A class is a blueprint declared with @interface...@end and implemented with @implementation...@end.
  • An object is a runtime instance of a class, created via [[ClassName alloc] init].
  • Nearly every Objective-C class ultimately inherits from NSObject, the root class.
  • alloc allocates zeroed memory for a new instance; init configures that instance's initial state.
  • self inside an instance method refers to the specific object that received the message.
  • The pattern self = [super init]; if (self) {...} return self; is the standard initializer idiom.
  • Instance methods use a minus sign (-) prefix; class methods use a plus sign (+) prefix.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#ObjectiveCStudyNotes#ClassesAndObjectsInObjectiveC#Classes#Objects#Objective#Declaring#OOP#StudyNotes#SkillVeris