{"id":43192,"date":"2024-05-10T14:26:38","date_gmt":"2024-05-10T18:26:38","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=43192"},"modified":"2024-05-30T09:51:34","modified_gmt":"2024-05-30T13:51:34","slug":"swift-proposal-objective-c-implementations-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/05\/10\/swift-proposal-objective-c-implementations-in-swift\/","title":{"rendered":"Swift Proposal: Objective-C Implementations in Swift"},"content":{"rendered":"

SE-0436<\/a> (via Becca Royal-Gordon<\/a>):<\/p>\n

Swift has always had a mechanism that allows Objective-C code to use Swift types: the @objc<\/code> attribute. When a class is marked with @objc<\/code> (or, more typically, inherits from an @objc<\/code> or imported Objective-C class), Swift generates sufficient Objective-C metadata to allow it to be used through the Objective-C runtime, and prints a translated Objective-C declaration into a generated header file that can be imported into Objective-C code. The same goes for members of the class.<\/p>

This feature works really well for mixed-language apps and project-internal frameworks, but it’s poorly suited to exposing private and especially public APIs to Objective-C.<\/p>

[…]<\/p>

We propose adding a new attribute, @implementation<\/code>, which, when paired with an interop attribute like @objc<\/code>, tells Swift that it is to implement a declaration it has imported from another language, rather than creating a new declaration and exporting it to<\/em> that language.<\/p>

Specifically, in this proposal, @objc @implementation<\/code> allows a Swift extension<\/code> to replace an Objective-C @implementation<\/code> block. You write headers as normal for an Objective-C class, but instead of writing an @implementation<\/code> in an Objective-C file, you write an @objc @implementation extension<\/code> in a Swift file. You can even port an existing class’s implementation to Swift one category at a time without breaking backwards compatibility.<\/p><\/blockquote>\n

This has been a long time coming<\/a>, and it seems like a great idea. This also makes it possible to implement a base class in Swift and then subclass it in Objective-C.<\/p>\n\n

Steve Troughton-Smith<\/a>:<\/p>\n

No joke, @_objcImplementation<\/code> has immediately become my favorite way to port ObjC classes to Swift bit by bit. I’m now using it in Pastel to push the last remaining bits of ObjC out of the codebase. It’s basically header-driven-Swift, which is kinda neat.<\/p><\/blockquote>\n\n

Previously:<\/p>\n