Objective-C iOS Development for Legacy & Enterprise Apps · Lesson

Bridging Swift to Objective-C

Learn to make Swift code accessible from Objective-C through the auto-generated Objective-C generated header.

Bridging Swift to Objective-C is a free Objective-C iOS Development for Legacy & Enterprise Apps lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Objective-C iOS Development for Legacy & Enterprise Apps learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Swift to Obj-C: The Bridge

Welcome! In mixed-language projects, you often need Swift code to talk to Objective-C code. This lesson focuses on making your modern Swift classes and methods accessible to older Objective-C files.

This "bridging" allows you to gradually introduce Swift into an existing Objective-C codebase or have parts of your app written in different languages.

The Auto-Generated Header

When you add Swift files to an Objective-C project, Xcode automatically generates a special header file for you. It's named ProductModuleName-Swift.h.

This header acts as a translator, exposing your Swift code to the Objective-C world. You don't create it; Xcode does all the work! You just need to import it.

Exposing Swift Classes

For an Objective-C file to "see" a Swift class, that Swift class must inherit from NSObject. This is a fundamental requirement for Objective-C compatibility.

Without inheriting from NSObject, your Swift class won't appear in the auto-generated bridging header.

Using @objc for Visibility

The @objc attribute explicitly marks a Swift declaration (class, method, property, initializer) as available to Objective-C.

Classes that inherit from NSObject and are not final automatically expose their members.
You might need @objc for specific members if your class doesn't inherit from NSObject (e.g., via a protocol) or for properties/methods that require KVC/KVO compatibility.

A Simple Swift Class

Here's a Swift class, MySwiftGreeter, that inherits from NSObject. Its name property and greet() method will be automatically exposed to Objective-C.

We can optionally use @objc(MySwiftGreeter) to specify the Objective-C name, though it's often inferred.

import Foundation

class MySwiftGreeter: NSObject {
    @objc var name: String

    @objc init(name: String) {
        self.name = name
        super.init()
    }

    @objc func greet() -> String {
        return "Hello from Swift, \(name)!"
    }
}

Importing the Swift Header

To use your Swift classes in an Objective-C file, you simply need to import the auto-generated bridging header. Replace ProductModuleName with your project's actual module name.

This import should be in your Objective-C .m implementation file, not in a .h header file, to avoid circular dependencies and unnecessary exposure.

// In MyObjectiveCFile.m
#import "YourProjectName-Swift.h"

// Now you can use MySwiftGreeter
// ...

Using Swift in Obj-C

Once the bridging header is imported, your Objective-C code can create instances of Swift classes and interact with their exposed properties and methods, just like any other Objective-C object.

Note: This code snippet shows how it would look in a project. Running it directly requires a full Xcode project setup with both Swift and Objective-C files.

#import <Foundation/Foundation.h>
#import "MyProjectName-Swift.h" // Your project's auto-generated header

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // Create an instance of the Swift class
        MySwiftGreeter *greeter = [[MySwiftGreeter alloc] initWithName:@"Coddy"];

        // Call a method on the Swift object
        NSString *greeting = [greeter greet];
        NSLog(@"%@", greeting);

        // Access a property
        NSLog(@"Greeter's name: %@", greeter.name);
    }
    return 0;
}

Swift & Obj-C Type Map

When bridging, Swift types are automatically mapped to their closest Objective-C equivalents:

Swift String maps to NSString*
Swift Int, Double, Bool map to NSNumber*
Swift Array maps to NSArray*
Swift Dictionary maps to NSDictionary*

This allows seamless data exchange between the two languages.

Customizing Obj-C Names

Sometimes, Swift's inferred Objective-C name for a class or method might not be ideal, or it might conflict. You can provide a custom Objective-C name using @objc(NewName).

This is especially useful if you need to match existing Objective-C naming conventions or avoid clashes with existing Objective-C symbols.

import Foundation

@objc(LegacyGreeter) // Renames MySwiftGreeter to LegacyGreeter for Obj-C
class MySwiftGreeter: NSObject {
    @objc var name: String

    @objc(initWithPersonName:) // Custom name for initializer
    init(name: String) {
        self.name = name
        super.init()
    }

    @objc(sayHello) // Custom name for method
    func greet() -> String {
        return "Hello from Swift, \(name)!"
    }
}

Bridging Limitations

Not all Swift features can be directly exposed to Objective-C. Keep these limitations in mind:

Swift Structs & Enums: Unless they have raw values and conform to @objc, they aren't directly visible.
Generics: Swift generics are not exposed.
Global Functions: Only methods within NSObject-derived classes are bridged.
Tuples: Swift tuples have no Objective-C equivalent.

Focus on classes, methods, and properties that mirror Objective-C's object model.

Bridging Knowledge Check

Which of the following is REQUIRED for a Swift class to be accessible from Objective-C code via the auto-generated bridging header?

Bridging Swift to Obj-C

You've learned how to make your Swift code available to Objective-C! Key takeaways:

Xcode generates a ProductModuleName-Swift.h header.
Swift classes must inherit from NSObject to be seen by Objective-C.
The @objc attribute explicitly exposes members or renames them.
Swift types like String, Array, and Dictionary are automatically mapped to their NS counterparts.

This bridging is crucial for maintaining and evolving mixed-language iOS projects!

Frequently asked questions

Is the “Bridging Swift to Objective-C” lesson free?

Yes — the full text of “Bridging Swift to Objective-C” is free to read here on the web, and the Objective-C iOS Development for Legacy & Enterprise Apps course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Objective-C iOS Development for Legacy & Enterprise Apps course, upgrade to CoddyKit PRO.

What will I learn in “Bridging Swift to Objective-C”?

Learn to make Swift code accessible from Objective-C through the auto-generated Objective-C generated header. You practise Objective-C iOS Development for Legacy & Enterprise Apps with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Objective-C iOS Development for Legacy & Enterprise Apps?

No prior experience is required. Objective-C iOS Development for Legacy & Enterprise Apps on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Bridging Swift to Objective-C” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Objective-C iOS Development for Legacy & Enterprise Apps lesson?

Yes. Every Objective-C iOS Development for Legacy & Enterprise Apps lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

Bridging Objective-C to Swift
Bridging Swift to Objective-C
Creating Objective-C Frameworks
Handling Nullability and Type Mapping Across the Bridge

← Back to Objective-C iOS Development for Legacy & Enterprise Apps