การเชื่อม Swift กับ Objective-C

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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!