Top 60 Objective-C Interview Questions (2026)

Objective-C is an object-oriented language that adds Smalltalk-style messaging to C. It's a strict superset of C, so any C code compiles as Objective-C, and it was Apple's primary language for building iOS, macOS, watchOS, and tvOS apps before Swift.

You'll still find it across huge production codebases, SDKs, and frameworks, which is why iOS teams hire people who can read and maintain it. Its distinctive traits are a dynamic runtime and message passing rather than direct method calls.

In Objective-C you send a message to an object rather than calling a method directly. The runtime looks up which method actually runs at send time, using the object's class and the selector, so the binding is dynamic, not fixed at compile time.

That's why you can send a message an object learns to handle at runtime, and why sending a message to nil is safe. The bracket syntax [object doSomething] is the message send.

Nothing happens, and the send returns a zero value: nil for object returns, 0 for numeric returns, and a zeroed struct for struct returns. There's no crash and no exception, unlike calling a method on null in many other languages. This is deliberate runtime behavior, and the returned zero is well defined.

This is deliberate and idiomatic. It lets you skip a lot of nil checks, but it also hides bugs when a method silently does nothing because its receiver was unexpectedly nil.

id is a generic pointer to any Objective-C object. A variable typed id can hold any instance, and the runtime figures out which method to call when you send it a message, so id is how Objective-C does dynamic typing.

You lose compile-time type checking with id, so use a concrete type like NSString * when you know it. id is right for containers and generic APIs where the exact class varies.

@interface declares the class: its superclass, properties, and method signatures. It's the public contract, traditionally in a .h header. @implementation contains the actual method bodies, traditionally in a .m file.

Splitting them lets other files import only the header and know how to use the class without seeing its internals. Private methods can live in the .m without appearing in the header.

NSString is immutable: once created, its characters can't change, and any method that looks like it edits the string actually returns a new one. NSMutableString is a subclass that can be modified in place with methods like appendString: and replaceCharactersInRange:, so you build it up step by step without allocating a fresh object each time.

Reach for NSString by default because immutability is safer to share; use NSMutableString when you're building a string in steps. The same pattern repeats across the Foundation collections.

NSArray is an ordered collection of objects; NSDictionary is an unordered collection of key-value pairs. Both are immutable, with NSMutableArray and NSMutableDictionary as the changeable versions. They store objects only, so numbers and booleans get wrapped in NSNumber.

Literal syntax makes them concise: @[a, b] for arrays and @{key: value} for dictionaries. Keys in an NSDictionary are copied and must conform to NSCopying.

@property declares an object's public attribute and tells the compiler to synthesize a getter, a setter, and a backing instance variable for it. Reading self.name calls the getter; assigning self.name = x calls the setter.

Attributes in parentheses control the details: nonatomic or atomic for thread safety, and strong, weak, copy, or assign for memory behavior. Dot syntax is just sugar for the method calls.

strong retains the object, keeping it alive while the property holds it. weak does not retain and is set to nil automatically when the target deallocates, which breaks retain cycles. copy stores an immutable snapshot. assign is a plain assignment with no memory management, used for primitives.

The everyday rules: strong for owned objects, weak for delegates and back-references, copy for NSString and block properties, assign for scalars like NSInteger and BOOL.

BOOL is Objective-C's boolean type with values YES and NO. On most modern platforms it maps to the C99 bool, but historically it was a signed char, so it could hold values other than 0 and 1.

The practical advice: use YES and NO, and don't compare a BOOL directly to YES, because any nonzero value is truthy but only 1 equals YES. Test the value itself: if (flag), not if (flag == YES).

self refers to the current object, so [self method] starts method lookup on the object's own class. super sends the same message but starts the lookup in the superclass, which is how an override calls the inherited behavior.

The classic use is in an init or a subclass override: call [super init] first, then add the subclass's own setup.

alloc allocates memory for a new instance and zeroes its instance variables; init sets up that instance's starting state and returns it. You pair them as [[Class alloc] init] because allocation without initialization gives you a half-built object.

Custom initializers follow the init prefix (initWithName:) and should call the superclass initializer first. Many classes also offer convenience constructors like [NSString stringWithFormat:].

instancetype is a return type that means an instance of the receiver's class. In an initializer or factory method it tells the compiler the exact type coming back, so the result stays type-checked instead of degrading to the untyped id.

Return instancetype from init methods and class factory methods. The compiler then flags misuse of the returned object at compile time.

An instance method acts on a specific object and is declared with a minus sign: - (void)greet. A class method acts on the class itself and is declared with a plus sign: + (instancetype)new. You call class methods on the class, instance methods on an instance.

Class methods are common for factory constructors and utilities that don't need an instance, like [NSDate date].

A selector is the name of a method as a lightweight runtime value of type SEL. @selector(doWork:) gives you the selector for a method, and you can pass it around and invoke it later with performSelector: or store it for delegation and target-action.

Selectors are just names, not implementations. Two unrelated classes can share a selector and each provides its own method for it, which is what makes dynamic dispatch flexible.

NSLog prints a formatted message to the console, like printf but for Objective-C. The %@ specifier prints any object by calling its description method, so %@ works for NSString, NSArray, your own classes, and more.

Other specifiers carry over from C: %d for int, %ld for long, %f for double. Mismatching a specifier and its argument is a frequent crash source.

A class inherits from one superclass, named after the colon in @interface Child : Parent. The subclass gets the parent's properties and methods, can add its own, and can override inherited methods. Objective-C is single inheritance only; protocols cover the multiple-interface need.

NSObject sits at the root of almost every class and provides basics like isEqual:, description, and the memory-management methods.

isKindOfClass: returns YES if the object is an instance of that class or any subclass of it, so it respects the whole inheritance chain. isMemberOfClass: returns YES only for that exact class and treats subclasses as a no, which makes it far stricter and much less commonly the one you actually want in real code.

Use isKindOfClass: almost always, because it respects the class hierarchy. isMemberOfClass: is for the rare case where you need the exact type and want to exclude subclasses.

Fast enumeration is the for (Type *item in collection) loop for iterating arrays, sets, and dictionaries. It's concise and efficient because the collection hands items to the loop in batches under the hood.

The one rule: don't mutate the collection while enumerating it, or you'll trigger an exception. Collect changes and apply them after the loop, or iterate a copy.

description returns an NSString that represents the object, and it's what %@ and the debugger's po command print. NSObject's default gives you the class name and address, which isn't useful, so you override it to show meaningful state.

Override description for readable logs and debugging. debugDescription is a separate hook the debugger prefers if you want different output there.

ARC, Automatic Reference Counting, is a compiler feature that inserts retain and release calls for you at compile time based on how you use objects. It isn't a garbage collector: there's no runtime scanning, just the same reference counting you'd write by hand, added automatically.

When an object's retain count drops to zero, it's deallocated immediately. You declare ownership with strong, weak, and unsafe_unretained, and ARC does the rest. Retain cycles still need your attention because ARC can't detect them.

retain increases an object's reference count by one; release decreases it by one; when the count hits zero the object is deallocated. autorelease marks an object to be released later, when the current autorelease pool drains, so you can return an object without leaking it.

The rule of thumb was: if you created an object with alloc, new, copy, or retain, you owned it and had to balance it with a release. ARC now writes these calls for you, but the model is what interviews probe.

A retain cycle happens when two objects hold strong references to each other, so neither's count ever reaches zero and both leak. The classic case is a parent holding a child strongly while the child holds the parent strongly, often through a delegate.

Break it by making one reference weak, usually the back-reference. Delegates are almost always weak for exactly this reason, and blocks that capture self use a weak-self pattern.

Delegation lets one object hand off decisions or events to another. You define a protocol of callback methods, add a weak delegate property typed to that protocol, and call the delegate's methods at the right moments. UIKit uses it everywhere: table views, text fields, scroll views.

The delegate property is weak to avoid a retain cycle, and you guard optional methods with respondsToSelector: before calling them.

A protocol declares methods a class can adopt. By default the methods are @required, so an adopting class must implement them or the compiler warns. Marking a section @optional means classes may skip those, which is why delegate methods are usually optional.

Because optional methods might be missing, you check respondsToSelector: before calling one. A class states adoption in angle brackets: MyClass : NSObject <SomeProtocol>.

A category adds methods to an existing class, even one you don't have the source for, without subclassing. It's how teams extend NSString or UIView with helper methods that read like they belong to the class.

The limits matter: a category can't add instance variables or stored properties, and if two categories define the same method the winner is undefined. For added state you use associated objects via the runtime.

A class extension is an anonymous category, @interface MyClass (), declared in the .m file. Unlike a normal category it can add instance variables and private properties, and the compiler requires its methods to be implemented in the main @implementation.

Use an extension for a class's private surface, properties and methods only that class should see. Use a category to add methods to classes you don't own or to split a large class across files.

A block is a chunk of code you can pass around like an object, Objective-C's version of a closure. It captures variables from its surrounding scope, so it's ideal for completion handlers, callbacks, and enumeration. The caret syntax ^{ ... } defines one.

By default a block captures a const copy of a local variable, so changing that local afterward doesn't affect the block. Mark a variable __block to let the block modify it and see later changes.

A block strongly captures any object it references, including self. If self also holds the block, for example as a stored completion handler, you get a retain cycle: self keeps the block, the block keeps self, neither deallocates.

The fix is to capture a weak reference. Create __weak typeof(self) weakSelf = self, use weakSelf inside the block, and often re-strongify it at the top of the block so it can't vanish mid-execution.

An autorelease pool holds objects marked autorelease and sends them release when the pool drains. The main run loop wraps each iteration in a pool, so most code never touches pools directly.

You add an @autoreleasepool block inside a tight loop that creates many temporary objects, so they're freed each iteration instead of piling up until the loop ends. Long-running background threads also want their own pool.

NSMutableString is a subclass of NSString, so a strong NSString property can be handed a mutable string. The caller could then mutate it behind your back and change your object's state unexpectedly. copy takes an immutable snapshot at assignment, so later mutations can't reach you.

The same reasoning applies to NSArray, NSDictionary, and NSSet properties. For a genuinely immutable value handed in, copy is nearly free because immutable objects return themselves.

Adopt the NSCopying protocol and implement copyWithZone:. Inside it, create a new instance and copy over the relevant properties. Then callers can send copy to your object and get an independent duplicate.

Decide between a shallow copy (copy the references) and a deep copy (copy the referenced objects too). NSCopying is also what lets your objects be dictionary keys, since keys are copied.

If two objects are equal by isEqual:, they must return the same hash. Break that and the objects misbehave in NSSet and NSDictionary, showing up twice or failing lookups. The default isEqual: compares pointer identity, so override both together for value equality.

Base hash on the same immutable fields you compare in isEqual:. Don't include mutable fields, or an object's hash changes while it sits in a set.

NSException signals programmer errors: out-of-bounds access, unrecognized selectors, broken invariants. In Cocoa you generally don't catch these; you fix the bug. NSError represents expected, recoverable failures like a missing file or a network timeout, passed back by reference.

So the convention is: NSError for conditions you handle at runtime, NSException for bugs. Methods take an NSError ** out-parameter and return NO or nil on failure.

GCD is Apple's concurrency framework built on dispatch queues. You submit blocks to queues and the system manages threads for you. The main queue runs UI work on the main thread; global concurrent queues run background work; serial queues run one block at a time for safe state access.

The everyday pattern is do heavy work on a background queue, then hop back to the main queue to touch the UI.

UIKit and AppKit aren't thread-safe. Touching views, layers, or the run loop from a background thread causes undefined behavior: glitchy rendering, crashes, or state corruption. The main thread owns the UI and the main run loop.

So background work stays off the main thread to keep the interface responsive, and any UI change dispatches back to the main queue. Getting this wrong is one of the most common iOS bugs interviewers screen for.

atomic, the default, makes the synthesized getter and setter thread-safe at the level of a single access, so you never read a half-written value. nonatomic drops that guarantee and is faster.

atomic protects one get or set, not a compound operation, so it isn't real thread safety for your logic. Most properties are declared nonatomic for speed, with genuine synchronization handled separately when needed.

KVC lets you read and write an object's properties by string name instead of direct accessors, using valueForKey: and setValue:forKey:. The runtime finds the matching getter, setter, or instance variable. It's the plumbing behind bindings, Core Data, and many generic APIs.

The cost is losing compile-time checks: a wrong key fails at runtime, not compile time. Use KVC for genuinely dynamic access, not as a substitute for normal property calls.

KVO lets one object watch another's property and get notified when it changes. You register with addObserver:forKeyPath:options:context: and respond in observeValueForKeyPath:. It's built on KVC and works only for KVC-compliant properties.

The sharp edges: you must remove the observer before it deallocates or you crash, and untangling context pointers across a class hierarchy is fiddly. Many teams prefer notifications or block-based APIs for that reason.

Expose a class method that returns the one shared instance, and create it inside dispatch_once so it's built exactly once even under concurrent access. dispatch_once is the standard, race-free way to do lazy one-time setup.

Singletons fit genuinely shared services like a session or a cache. Overusing them creates hidden global state that's hard to test, so reach for them sparingly.

The Objective-C runtime is a C library that turns the language's dynamic features into machine behavior at runtime. Classes, objects, and methods are runtime data structures, and message sends become calls into the runtime that look up and invoke the right implementation.

It's what enables categories, associated objects, dynamic method resolution, introspection like class and respondsToSelector:, and swizzling. You can query and modify the class system while the program runs through functions like class_addMethod and objc_getClass.

The compiler turns [obj doThing:x] into a call to objc_msgSend(obj, @selector(doThing:), x). That function takes the receiver and selector, finds the object's class, searches the method cache and then the class's method lists (walking up superclasses), and jumps to the matching implementation (an IMP).

If no method is found, the runtime gives you resolution hooks before it raises unrecognized selector. The method cache makes repeat sends to the same class fast.

When an object gets a message it doesn't implement, the runtime gives three chances before crashing. First resolveInstanceMethod: can add a method dynamically. Then forwardingTargetForSelector: can hand the message to another object cheaply. Finally the full path builds an NSInvocation and passes it to forwardInvocation:, which needs methodSignatureForSelector: to describe the arguments.

This is how proxies, some mocking frameworks, and higher-order messaging work. It's also the last stop before unrecognized selector.

Swizzling swaps two methods' implementations at runtime using the runtime API, usually in +load or a dispatch_once inside +initialize. It's how you inject behavior into a method you don't own, like logging every viewDidAppear.

The honest senior take: use it rarely. It's global, order-sensitive, and can break when Apple changes internals or two libraries swizzle the same method. Prefer subclassing, categories, or delegation, and reach for swizzling only when there's no seam.

Associated objects let you attach state to an instance at runtime with objc_setAssociatedObject and objc_getAssociatedObject, keyed by a static pointer. They exist to work around the fact that categories can't add instance variables, so a category can still store a value per instance.

You choose an association policy (retain, copy, assign) that mirrors property attributes. Use them sparingly: they're harder to see than declared properties and can surprise the next reader.

+load runs once per class as the class is loaded into memory, very early, before main in most cases, and runs for every class and category that implements it. +initialize runs lazily the first time a class receives a message, and only if you send it one.

So +load is for the earliest possible setup like swizzling, but it's dangerous because ordering across classes isn't guaranteed and it blocks app launch. +initialize is safer for one-time class setup and should guard against running twice for subclasses.

The designated initializer is the one init method that does the full setup and calls the superclass's designated initializer. Other, convenience, initializers funnel through it rather than duplicating setup. The chain guarantees every object is fully initialized exactly once.

It matters for subclassing: a subclass overrides the designated initializer and calls super's, so no matter which convenience init a caller uses, the object ends up correctly built. Breaking the chain leaves objects half-initialized.

Both are non-owning references, so neither keeps the target alive. The difference is cleanup: a weak reference is zeroed to nil automatically when the target deallocates, so accessing it afterward is safe. unsafe_unretained is not zeroed, so after deallocation it's a dangling pointer and using it crashes.

Use weak by default. unsafe_unretained exists for the rare case where the tiny overhead of zeroing weak matters, or for objects that don't support weak references, and it demands you manage lifetime by hand.

A tagged pointer packs a small object's value directly into the pointer bits instead of allocating an object on the heap. The runtime uses it for small NSNumber values, short NSString values, and NSDate, so common small objects cost no allocation and no reference counting.

The upshot for senior work: some pointers aren't real heap addresses, which is why you never rely on pointer equality for value objects and why isa isn't a plain class pointer anymore. It's mostly transparent, but it explains surprising behavior in low-level debugging.

Every Objective-C object starts with an isa pointer that told the runtime which class the object is, which is how message dispatch finds the method lists. On modern 64-bit runtimes isa is a non-pointer isa: a bitfield that packs the class plus reference count bits, weak-reference flags, and deallocation state alongside the class reference.

That packing is why retain counts for many objects live inline rather than in a side table, speeding up ARC. You rarely touch isa directly, and object_getClass is the supported way to read an object's class.

Use a concurrent queue with dispatch_barrier for writes. Reads run concurrently with dispatch_sync (or dispatch_async) so many readers proceed at once. Writes use dispatch_barrier_async, which waits for in-flight reads to finish, runs alone, and blocks new work until it completes.

This gives the classic multiple-readers, single-writer guarantee without a lock on every read. It's a common senior design question for a shared in-memory cache.

@synchronized(obj) is the simplest: it takes a recursive lock keyed on an object, but it's relatively slow. NSLock and NSRecursiveLock are explicit lock objects. os_unfair_lock is a fast, low-level lock that replaced the deprecated OSSpinLock. A serial dispatch queue often replaces locks entirely by serializing access.

The senior instinct is to avoid locks where a serial queue or immutable data removes the need, and to pick the lightest correct tool when a lock is genuinely required.

Some Foundation and Core Foundation types are interchangeable in memory, so NSString and CFStringRef can be cast between each other for free. That's toll-free bridging. Because ARC manages Objective-C objects but not CF objects, the cast must state who owns the retain.

__bridge casts without transferring ownership. __bridge_retained (or CFBridgingRetain) hands ownership to CF and you must CFRelease it. __bridge_transfer (or CFBridgingRelease) hands ownership back to ARC. Getting the direction wrong leaks or over-releases.

NSCoding lets an object encode itself into and decode itself from an archive by implementing encodeWithCoder: and initWithCoder:. NSKeyedArchiver writes the archive. NSSecureCoding adds a check that the decoded object is the class you expect, closing a substitution attack in the older API.

Modern code should adopt NSSecureCoding and decode with decodeObjectOfClass:forKey: so a malicious archive can't smuggle in an unexpected class. This matters anywhere you unarchive untrusted data.

In a mixed target, Swift sees Objective-C through an Objective-C bridging header, and Objective-C sees Swift through the generated ProductName-Swift.h header. Swift classes that inherit from NSObject or are marked @objc are visible to Objective-C; not everything Swift offers (generics, enums with associated values) bridges.

Practical seams: nullability annotations (nullable, nonnull) map to Swift optionals, and lightweight generics like NSArray<NSString *> import as typed arrays. Clean interop is mostly about annotating the Objective-C headers well.

EXC_BAD_ACCESS means you touched memory you shouldn't, usually a message to a deallocated object (a dangling pointer, classic in non-ARC or unsafe_unretained code). Turn on Zombies to catch messages to freed objects with a clear log, and run Address Sanitizer for broader memory errors.

Then narrow it: reproduce reliably, read the backtrace for the last valid frame, check ownership around the crashing object, and look for over-release, a raw C pointer outliving its object, or threading that frees an object another thread still uses.

Instruments is the profiler. The Leaks instrument flags objects with no remaining references to them; the Allocations instrument shows growth over time and abandoned memory (retained but unreachable in practice), which is where retain cycles show up. Time Profiler samples the call stack to find CPU hot spots.

The discipline the question needs: measure before changing anything. Reproduce the workload, capture a trace, find the growing allocation site or the hot stack, fix, and re-measure to confirm.

A block starts life as a stack block, allocated on the stack. Sending it copy (or storing it in a strong property, which copies under ARC) moves it to the heap as a heap block so it can outlive the current scope. A block that captures nothing can be a global block with static storage.

This matters when you store a block for later: a stack block used after its scope returns is a crash. Under ARC, assigning to a strong block property copies it to the heap for you, which is why completion handlers survive.

Clarify needs first (auth, retries, caching, concurrency), then layer it: a request-building layer that turns typed requests into NSURLRequests, a transport layer over NSURLSession that returns results via completion blocks or a delegate, and a parsing layer that maps JSON to model objects with clear error handling through NSError.

Keep the transport off the main thread and marshal callbacks back to it, make model objects immutable, and hide NSURLSession behind a protocol so you can inject a fake session in tests. Close on the operational edges: timeouts, cancellation, and retry with backoff.

XCTest is the built-in framework: subclass XCTestCase, write test methods prefixed with test, and assert with macros like XCTAssertEqual and XCTAssertNil. Asynchronous code uses XCTestExpectation to wait for a callback. You run tests from Xcode or xcodebuild in CI.

The design point interviewers probe is testability: inject dependencies (a session, a clock) behind protocols so you can pass fakes, and test behavior at the seams rather than reaching into internals.