Monday Quick Read: Working with Both Swift and Objective-C?
Here are a few things that help me manage the interoperability challenges
Hey iOS developer! 👋
Happy to announce the start of a new series - Monday Quick Read - where I'll be sharing my personal experiences and thoughts on software development, specifically iOS.
These will be short posts covering a variety of topics, such as how to handle sudden App Store review rejections or how to avoid feeling overwhelmed by new iOS releases.
Most importantly, my regular issues of the Curated iOS newsletter are here to stay, and the next one will arrive this Wednesday!
The first topic in the new series is about managing the interoperability challenges when working with both Swift and Objective-C in the same codebase.
Happy Monday!
If you’re working on an iOS app that was introduced a long time ago, there’s a good chance your codebase consists of both Swift and Objective-C. It’s neither good nor bad, it’s just how it is, and we need to cope with it.
In many cases, rewriting the app from scratch isn’t feasible for a number of reasons: lack of development resources, tight deadlines for delivering new features, or simply not wanting to break what’s already working. This means teams may be working with legacy Objective-C code alongside newer Swift code for a long time. And here’s the tricky part: mixing both languages can lead to unexpected crashes and bugs.
We need to understand that having Objective-C in 2024 is not the end of the world, even though Swift was introduced 10 years ago and SwiftUI 5 years ago. Plenty of big companies still have lots of Objective-C code in their apps, like Medium (check issue #15 - Engineering blogs).
Here are a few common challenges I’ve encountered and how I’ve learned to manage them:
Mastering the Bridging Header
Xcode helps set up the Bridging Header without much hassle, but it’s up to us to import all the necessary Objective-C headers. I keep the Bridging Header clean to avoid unnecessary clutter.
Handling Nullability
Objective-C doesn’t have Optionals. To handle them safely in Swift, we need to properly annotate Objective-C objects with nullable and nonnull.
Using Swift Types with Objective-C
Some Swift types, like structs, aren’t available in Objective-C. When I need Swift objects to be exposed to Objective-C, I use classes with the @objc attribute to ensure compatibility.
Managing Runtime Crashes
Objective-C isn’t as strict with type checking, so bridging objects to Swift can cause runtime crashes. Extra caution is needed when moving data between the two languages.
Deciding When to Refactor
Sometimes, it’s better to keep working Objective-C code rather than refactoring and introducing new bugs. I try to be very cautious when rewriting code to Swift.
If you look at job offers, many still require Objective-C knowledge at a basic level, like being able to read and maintain the code. I hope you won’t need to, but now you’re better prepared.
If you’ve enjoyed this article - hit the Like button and subscribe, if you haven’t already!
Stay tuned for more in the upcoming issues. Until next time!
Artjoms