@objc and dynamic

 

@objc and dynamic

Objective-C runtime visibility and the depths of dynamic dispatch in the modern Swift era.

5 December 2017 ∙ Objective-C Interop ∙ written by Greg Heo

The @objc attribute controls visibility of Swift bits from Objective-C. It’s back under the spotlight with Swift 4 and more specifically the changes in SE-0160, Limiting @objc inference.

What does @objc mean? What about dynamic? How do they work? And what’s different in the post-Swift 4 world?

This article will be a bit different — we’ll compile a simple bit of code and inspect it rather than look at something like Objective-C runtime source code.

Semi-Permeable Membranes

Way back in 2015 I gave a talk titled Switching Your Brain to Swift. Swift 2 was in beta and mixed codebases were all around us.

I used the analogy of a semi-permeable membrane — things make it across the language divide from Objective-C to Swift very easily, but not as easily from Swift to Objective-C.

There are two keywords to keep in mind when dealing with interoperability:

• @objc means you want your Swift code (class, method, property, etc.) to be visible from Objective-C.
• dynamic means you want to use Objective-C dynamic dispatch.

The state of the world circa 2015.

The slightly confusing bit for me was that this scheme conflates the concepts of visibility and dispatch.

In Swift 3 and earlier, dynamic also implied @objc. New in Swift 4, dynamic only means dynamic dispatch and says nothing about Objective-C visibility.

However, there’s no such thing as Swift dynamic dispatch; we only have the Objective-C runtime’s dynamic dispatch. That means you can’t have just dynamic and you must write @objc dynamic. So this is effectively the same situation as before, just made explicit.

That’s really all there is to it. But where’s the fun in that? How does it work under the hood? Can we start to unbox @objc and dynamic?