Start with the app delegate.
AppDelegate.swift, and mark the class with
main.m, because it is now unnecessary. With the use of
@UIApplicationMain, the target now knows the entry point.
Adding your first Swift
When you add your first Swift file (like
AppDelegate.swift above), Xcode will prompt to add a bridging header.
Add the bridging header.
AwesomeApp-Bridging-Header.h is the place where you add your existing .h files, exposing them to Swift (as and when needed).
1. Using Objective-C in Swift
We come to the first of the 2 important parts in interoperability.
To use your existing Objective-C, there are a few things to do:
- Bridging header to expose the Objective-C classes
- Declare nullability in the Objective-C files
We have mentioned (1) in the section above.
For (2), the reason is because Swift is strict on nullability. Can an object be optional, or never?
In Objective-C days, way before Swfit was born, nullability was never explicit. You would have seen
EXEC_BAD_ACCESS, and many times the reason is because the object is nil, when is should not be.
Swift make our code safer with explicit nullability.
Hence, you need to make Objective-C code be explicit, so that Swift can use safely:
nullable- An optional
nonnull- Never an optional
- Otherwise, they are implicitly unwrapped optional (crash if nil!)
There are also 2 convenient macros to help you:
NS_ASSUME_NONNULL_END. Any properties between the macros are considered
2. Using Swift in Objective-C
This is the second part, if you still need to write more Objective-C.
To use the new Swift code in existing Objective-C, you have to
This will expose all Swift code.
Don’t be alarm that you cannot find the aforementioned .h file in your project. It is a auto generated header from your Swift code.