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.
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.
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.
Additional warnings shall be added when implicitly unwrapping an IUO that was inferred from a lack of nullability information in the Objective-C API.
- 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
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.