Wednesday, June 8, 2016

Swift Mistakes

Zev Eisenberg:

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 using private extensions wherever you aren’t required to make them public.


There are certainly cases where direct comparison to nil are 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.

Daniel Jalkut:

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.

Comments RSS · Twitter

Leave a Comment