Swift TIP: objc and dynamic

Although the original intention of Swift language is to get rid of the heavy historical burden and constraints of Objective-C, it is undeniable that after more than 20 years of baptism, the Cocoa framework has long been indelibly marked by Objective-C. Countless third-party libraries are written in Objective-C, and this accumulation cannot be underestimated by anyone. Therefore, in the initial version, Swift had to consider compatibility with Objective-C.

Apple allows us to use both Swift and Objective-C in the same project. In fact, the Objective-C files and Swift files in a project are in two different worlds. In order to connect them, we need to add some bridges.

First, by adding the {product-module-name}-Bridging-Header.h file and filling in the name of the header file you want to use, we can easily use Objective-C code in Swift. In order to simplify this setting, Xcode will even actively pop up a box to ask whether to automatically create this file when you import an Objective-C file for the first time in a Swift project, which is very convenient.

But if you want to use Swift types in Objective-C, things are a little more complicated. If it comes from an external framework, then the framework and the Objective-C project are definitely not in the same target, and we need to import the external Swift module. This is actually the same as using the original Framework of Objective-C. For a project, there is not much difference whether the external framework is written in Swift or Objective-C. We use @import, which was newly introduced in 2013, to import the module:

 @import MySwiftKit;

After that, you can use this framework written in Swift normally.

If you want to use the Swift source files in the same project in Objective-C, you can directly import the automatically generated header file {product-module-name}-Swift.h to complete it. For example, if the project target is called MyApp, we need to write

 # import   "MyApp-Swift.h"  

But this is just the beginning of the story. Objective-C and Swift use two completely different mechanisms at the bottom. Objective-C objects in Cocoa are based on the runtime. They follow KVC (Key-Value Coding, which stores object information in a dictionary-like manner) and dynamic dispatch (Dynamic Dispatch, which determines the specific implementation of the actual call when the call is run). In order to pursue performance, Swift will not decide these at runtime unless there is a special need. In other words, the members or methods of Swift types are determined at compile time, and there is no need to search them at runtime, but they can be used directly.

Obviously, the problem is that if we use Objective-C code or features to call pure Swift types, we will fail because we cannot find the required runtime information. The solution is also very simple. In the Swift type file, we can add the @objc modifier to the declaration of any place that needs to be exposed to Objective-C (including classes, properties, methods, etc.). Note that this step only needs to be performed on types that do not inherit from NSObject. If the class you write in Swift inherits from NSObject, Swift will automatically add @objc to all non-private classes and members by default. This means that for a subclass of NSObject, you only need to import the corresponding header file to use this class in Objective-C.

Another function of the @objc modifier is to redeclare the name of the method or variable for the Objective-C side. Although the automatically converted method name is good enough in most cases (for example, it will convert methods like init(name: String) in Swift to -initWithName:(NSString *)name), sometimes we still want to use a different method name or class name in Objective-C than in Swift, such as a class like this in Swift:

 class My Class {
 func sayhello(name: String) {
 println( "Hello, \(name)" )
 }
 }

My class().Say hello("Xiao Ming")

Objective-C cannot be called using Chinese, so we must use @objc to convert it to ASCII before accessing it in Objective-C:

 @objc (MyClass)
 class My Class {
 @objc (greeting:)
 func sayhello(name: String) {
 println( "Hello, \(name)" )
 }
 }

In this way, we can call code like [[MyClass new] greeting:@"XiaoMing"] in Objective-C (although it is not fun at all compared to before). In addition, as mentioned above and in the Selector section, even for subclasses of NSObject, Swift will not automatically add @objc to methods or members marked as private. If we need to use the dynamic features of these contents, we need to manually add @objc to them.

Adding the @objc modifier does not mean that the method or property will become dynamically dispatched. Swift may still optimize it to a static call. If you need the same runtime features as dynamic calls in Objective-C, you need to use the modifier dynamic. Generally speaking, it should not be used when developing apps, but when performing some "black magic" such as dynamically replacing methods or deciding the implementation at runtime, we need to use the dynamic modifier. In the subsequent KVO section, we will mention an example of using dynamic.