Should A Swift Class Be Prefixed To Avoid Potential Objective-C Compatibility Collision Issues

Question

To provide cross compatibility, Swift allows for the generation of a bridging header so that Objective-C can communicate with Swift classes.

Due to Swift's wonderful namespacing we no longer need to worry about prefixing our Swift files as they are namespaced by their containing framework. A UIView for instance is implicitly namespaces as UIKit.UIView.

Now that Apple are pushing frameworks, I was wondering what the best practices are to avoid header collision when there exists two swift bridging headers with the same symbols.

An example: Say we have two frameworks that have declared a Swift class called Downloader. The Downloader provides the interface: downloadWithURL(url: NSURL)

Generating a bridging header will yield a Downloader-Swift.h file for both of these frameworks. Thus causing a collision. What are the best practices to avoid this?

Answer 1

According to Apple's engineers the <#Module Name#>-Swift.h header uses a macro that mangles the name so as to avoid conflicts (see WWDC video Swift Interoperability In Depth, beginning at 45 min, 40 sec). They gave an example of a Document Swift class:

SWIFT_CLASS("_TtC5MyApp10Document")
@interface Document : UIDocument
// rest of the interface...

To your Swift code, the class will be available as MyApp.Document, if MyApp is the module it is in. So, if you have two Swift classes of the same name coming from different modules – say, one is your own and the other from an open source Swift framework SomeFramework – they will be available to your Swift code as MyApp.Document and SomeFramework.Document...

On the Obj-C side, however, importing these two classes into the same lexical scope leads to Duplicate interface definition for class 'Document' compiler error. That's just Obj-C... In the vast majority of cases, though, this will not be an issue since you can still import these two classes across the app as long as they do not trespass each other's territory. Indeed, how often would you want to use MyApp.Document and SomeFramework.Document in the same module of your app? As we are moving into swifter times, I'm not sure this particular issue warrants a particular strategy, compared to so many urgent issues, such as, multicore, distributed, functional, haptic, anticipative, wearable, autonomous, etc...