Swift Mistakes
Even though I’ve been keeping up with Swift blog posts, my first Swift app was a port of an old and crusty Objective-C code base, and I carried over a lot of old habits. In looking back over it, I found many small- to medium-sized changes that make the code cleaner and more Swifty. Maybe I can help you avoid similar mistakes.
[…]
Sadly, you can’t make protocol conformances
private, but otherwise you should be usingprivate extensions wherever you aren’t required to make them public.[…]
There are certainly cases where direct comparison to
nilare appropriate, but Swift’s language features make it pretty rare in my experience.[…]
Since you can extend any type, it’s convenient to make extension files for your utilities on
CGRect,CGPoint,UIInterfaceOrientation, and other types that couldn’t be extended when they were lowly C structs. So don’t litter your main code files with one-off domain-specific utilities on system types. Put them in a separate file and write a couple of unit tests just for that file.
At first, I didn’t think too much of this bridging header. Sure, I want to access my Objective C files from Swift. Which ones? Why not all of them?
[…]
My takeaway is to accept that it is fundamentally unsafe to interface with Objective C classes whose headers have not been audited for nullability.
