Objective-C and Swift Interoperability

Analogy categoryAnalogies

Bridging Two Languages in One Project

Most real-world iOS and macOS codebases are not purely Objective-C or purely Swift; they are mixed-language targets that grew over a decade of framework evolution. Xcode makes this possible through two mechanisms: a bridging header (an Objective-C header you list under 'Objective-C Bridging Header' build setting) that exposes your own Objective-C classes to Swift files in the same target, and an automatically generated '-Swift.h' header that exposes your Swift classes to Objective-C files. Neither mechanism requires manual glue code for ordinary classes and methods; the compiler generates the translation layer, but only for constructs that exist in both languages.

🏏

Cricket analogy: It's like a franchise in the IPL fielding both overseas players and domestic players on one team sheet — the bridging header is the team manual that translates each side's terminology so a South African pacer and a Mumbai-raised batter can read the same match plan.

Exposing Objective-C to Swift

For Objective-C APIs to feel natural in Swift, you annotate them with nullability qualifiers and, when needed, a custom Swift name. Wrapping a header's declarations in NS_ASSUME_NONNULL_BEGIN / NS_ASSUME_NONNULL_END tells the Swift importer that pointers are non-optional by default, and you mark individual exceptions with 'nullable' or explicitly with 'nonnull'. Without these annotations every Objective-C pointer type imports into Swift as an implicitly unwrapped optional, which defeats much of Swift's null-safety and forces callers to guess whether nil is a legitimate value. NS_SWIFT_NAME lets you rename an Objective-C method or class to match Swift naming conventions, for example turning 'initWithFrame:style:' into a Swift initializer with labeled parameters that read naturally.

🏏

Cricket analogy: It's like a scorer explicitly marking a delivery as a 'no-ball' rather than leaving it ambiguous — NS_ASSUME_NONNULL_BEGIN is the default assumption that every ball is legal unless flagged otherwise, so the scorebook (Swift's type system) doesn't have to double-check every single delivery.

objectivec

// PersonAPI.h
NS_ASSUME_NONNULL_BEGIN

@interface Person : NSObject

@property (nonatomic, copy) NSString *name;
@property (nonatomic, copy, nullable) NSString *middleName;

- (instancetype)initWithName:(NSString *)name
                    lastName:(NSString *)lastName
    NS_SWIFT_NAME(init(name:lastName:));

- (nullable NSString *)greetingForLocale:(NSString *)localeIdentifier;

@end

NS_ASSUME_NONNULL_END

// Swift call site:
// let person = Person(name: "Ada", lastName: "Lovelace")
// let greeting: String? = person.greeting(forLocale: "en_US")

Lightweight Generics and Swift Collections

Objective-C's lightweight generics, written as 'NSArray<NSString *> *' or 'NSDictionary<NSString *, Person *> *', exist purely as compile-time annotations — the runtime still stores an untyped NSArray under the hood — but they matter enormously for interoperability because Swift uses them to import the collection as a properly typed '[String]' or '[String: Person]' instead of a useless '[Any]' or '[AnyHashable: Any]'. Omitting generics on a public Objective-C API is one of the most common reasons Swift call sites end up littered with forced casts like 'as! [String]', which silently crash if the assumption is ever wrong.

🏏

Cricket analogy: It's like a scorecard that labels a column 'Sixes' rather than just 'Numbers' — without the label, anyone reading the sheet has to guess whether a given number means runs, balls faced, or boundaries, exactly how an untyped NSArray forces Swift to guess at contents.

A public Objective-C API without lightweight generics annotations forces every Swift consumer to insert 'as!' or 'as?' casts on the collections it returns. Adding '<NSString *>' style generics costs nothing at the call site in Objective-C but eliminates an entire class of Swift crashes.

Calling Swift from Objective-C

The reverse direction — Objective-C code calling into Swift — requires the Swift declaration to be representable in Objective-C's object model. Marking a Swift class 'final' by default excludes it from the generated '-Swift.h' header unless it inherits from NSObject and its members are marked '@objc'; classes that don't subclass NSObject are invisible to Objective-C entirely. Within an '@objc'-annotated class, methods, properties, and initializers that use only Objective-C-compatible types (classes, NSString, primitive numeric types, optionals of object types) get exported automatically; anything using Swift-only constructs is silently omitted from the generated header, which is a common source of 'why can't Objective-C see this method' confusion.

🏏

Cricket analogy: It's like a domestic player being eligible for international selection only after fulfilling residency and board-registration requirements — a Swift class needs to subclass NSObject and carry '@objc' before it's 'selected' into the Objective-C header, no matter how good the code is.

Swift structs, enums with associated values, generics, tuples, top-level functions, and protocol extensions have no representation in Objective-C's runtime and are never exported to '-Swift.h', even with '@objc'. Design the Objective-C-facing surface of a Swift module around plain classes, protocols conforming to '@objc', and Foundation types.

Bridging headers expose your Objective-C code to Swift files in the same target; the generated '-Swift.h' header exposes '@objc'-annotated Swift to Objective-C.
NS_ASSUME_NONNULL_BEGIN/END sets a default of non-optional pointers, with 'nullable' marking explicit exceptions — omitting this makes every Swift-imported pointer an implicitly unwrapped optional.
NS_SWIFT_NAME renames Objective-C declarations so they read idiomatically in Swift, such as converting selector-style names into labeled initializers.
Lightweight generics on NSArray/NSDictionary let Swift import strongly typed collections instead of forcing 'as!' casts at every call site.
A Swift class must subclass NSObject and be marked '@objc' to appear in the generated header at all.
Swift-only constructs — structs, enums with associated values, generics, tuples, protocol extensions — have no Objective-C representation and are silently omitted from the bridge.
Interoperability failures are usually silent (a missing method, an unexpected optional) rather than compiler errors, so annotate deliberately rather than relying on defaults.