Uploaded image for project: 'Swift'
  1. Swift
  2. SR-104

Improve Crash-Safety when Importing Objective-C Code Without Nullability Attributes



    • Type: Improvement
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Component/s: Compiler
    • Labels:



      Objective-C code that does not yet include nullability annotations should generate warnings for unsafe accesses in order to prevent runtime crashes.


      Swift code accessing Objective-C methods can easily crash. If the Objective-C code does not include nullability attributes, it is brought as Implicitly Unwrapped Optional (IUO) into Swift. If the value of the IUO is accessed, and it is nil at that time, a crash occurrs. These unsafe accesses do not produce compiler warnings and can not be identified by only looking at the according Swift code. So these problematic places are not easy to track down in a code base.

      Short example:

      // Objective-C  
      - (NSString *)giveMeAString { return nil; }  
      // Swift  
      func thisWillCrash() {  
         let string = someObjectiveCObject.giveMeAString()  
         let length = string.length // crash  

      Use cases

      This affects all uses of Objective-C code from Swift, may it be the System SDK, an integrated Framework, or the same application's code.

      Very important would be the use case of an application that is written in Objective-C where Swift code is added. The new Swift code (e.g. in an extension to an Objective-C class) is bound to call a lot of the application's old Objective-C code.


      func someSwiftFuncInAnExtension() {

      In a call like that it is not immediately obvious if myDataModel , someProperty or someMethod is written in Objective-C and missing nullability annotations. Swift should help with writing safe code and be supportive at gradually migrating an application to Swift.

      Proposed solution

      Additional warnings shall be added when implicitly unwrapping an IUO that was inferred from a lack of nullability information in the Objective-C API.


      // Objective-C  
      - (NSString *)giveMeAString { return nil; }  
      // Swift  
      func someFunction() {  
         let string = someObjectiveCObject.giveMeAString()  
         let length = string.length // warning  
         let length2 = string!.length // no warning  
         if let unwrappedString = string { // no warning  
             let length3 = unwrappedString.length

      Detailed design

      • Create 2 separate warnings when implicitly unwrapping an IUO that was inferred the from a lack of nullability information in the Objective-C API - one for "system" and the other for "user" frameworks
      • The warning levels shall be NO , YES and YES_ERROR
      • The warning for "system" frameworks shall default to NO , the one for "user" frameworks to YES
      • Xcode Fix-It in case of a compile error

      Impact on existing code

      The new warnings will not harm productivity. If a project has "Treat warnings as errors" activated, and there are issues with "user" frameworks, that warning could be selectively deactivated if fixing the errors would take too much time.


          Issue Links



              fabb Fabian Ehrentraud
              1 Vote for this issue
              3 Start watching this issue