Skip to main content

Routing Swift Optional Types to Objective-C



Yesterday I was catching up on some of the recent proposals on the Swift Evolution Github page and seen a very interesting proposal that I thought I would discuss in brief detail.  The proposal is called, "Bridge Optional As Its Payload Or NSNull," and the reason I find it interesting is because the proposal points out some of the subtle differences in in data types between Objective-C and Swift that may not be so obvious to all developers.  The proposal also explains how the Swift team is trying to sheppard the Swift language while still trying to give developers support for using Objective-C right alongside Swift, and this is no easy task.  The proposal was created by Joe Groff, an Apple Engineer, and at the time of writing this, is still under active review from September 2nd til September 8th.


To summarize this proposal best one first must start by reviewing the SE-116 proposal that describes Objective-C and Swift bridging and how to appropriately interpolate types between languages.  For example, if a Swift String was to be bridged to an Objective-C string, it needs to be bridged to NSString, and vice-versa.

var x: Any = "foo" as String
x as? String   // => String "foo"
x as? NSString // => NSString "foo"
x = "bar" as NSString
x as? String   // => String "bar"
x as? NSString // => NSString "bar"

However, when it comes to objects, there was a need to bridge all Swift types to all Objective-C types, not just objects as Objective-C's polymorphism previously allowed for with id mapping to AnyObject.  So, the SE-116 proposal describes that when id objects are imported into Swift they are imported using the Any type instead of AnyObject type to allow for Swift's polymorphism of any type value to be freely mapped making it easier to pass String and Arrays to Objective-C.  Now, what about optionals?  Can optionals be passed to Objective-C, and if they do, what does the value look like since Objective-C does not currently contain this type of functionality?  These are questions that proposal SE-0140 tries to solve.

Proposal SE-0140 says that because the Swift Any keyword can hold any value then it is possible to pass an optional back to Objective-C and most likely Objective-C will not know how to handle this opaque object because it will not be recognized by any of the Objective-C APIs.  The answer then is to map the wrapped value in Swift to the appropriate type in Objective-C or just simply map the value to NSNull if there is no value.  So in conclusion, the reason that I said that this is evidence of the two languages diverging is because these two proposals that I just mentioned are examples of Swift bridging data types to Objective-C where there is no equivalent functionality to how the polymorphism is setup in Swift.  Very interesting to think about in terms of the future of Swift and how things will look a year or two from now.

Let me know if you have any feedback, questions or concerns, thank you!

Member for

3 years 9 months
Matt Eaton

Long time mobile team lead with a love for network engineering, security, IoT, oss, writing, wireless, and mobile.  Avid runner and determined health nut living in the greater Chicagoland area.