Challenges of mixed SwiftUI and UIKit codebases in iOS Apps
Imagine you are a software engineer, or you really are. You create iOS apps on a daily basis. You use only the latest and finest trends in mobile development, such as SPM, Swift Data, and, of course, SwiftUI. Life couldn’t be better. But reality is cruel. And in real life you probably need to maintain and develop an application that was written several years ago when these technologies didn’t exist at all.
Due to your natural curiosity and desire to build top-notch products, you still strive to integrate the best approaches in your app. The Medium iOS team is not an exception. And given that our codebase dates back to 2013, it has a bunch of UIKit views.
In this post, I’d like to cover some differences SwiftUI and UIKit interactions, pitfalls, and things to consider before making the decision to upgrade your views from UIKit to SwiftUI.
- Integration Complexity & Code Duplication
Integrating SwiftUI views into a UIKit project might not be as seamless as anticipated. SwiftUI uses a different approach with its declarative syntax and layout system compared to UIKit’s imperative approach. SwiftUI views can be embedded within UIKit using UIHostingController. One of the most common problems we faced is sizing, especially for cells (showing SwiftUI view as UITableViewCell or UICollectionViewCell when they don’t have fixed dimensions).
When it comes to scroll tracking, SwiftUI and UIKit have different API and approaches for this. The differences start even in details like scroll offset. In UIKit, it has a negative value, while in SwiftUI, it is positive.
To solve the abovementioned issue about cells sizing, we sometimes have to implement the same view twice — once in SwiftUI, and once in UIKit. Given that we try to use reusable design components, this adds complexity during development and even more when we need to make changes in these components.
This becomes even more serious when we talk about things like PostPreview, which is an essential component of the Medium app.
2. Navigation and View Controllers
SwiftUI has its own navigation system (NavigationStack, NavigationSplitView) that might not directly align with UIKit’s navigation controllers and your current architecture, leading to difficulties in managing navigation between SwiftUI and UIKit views. This also includes data passing, which might require additional transformations and efforts.
We mostly use UIKit for app-wide navigation and SwiftUI for local navigation inside features (when possible).
3. Compatibility and Stability
SwiftUI is continuously evolving with updates, and it might have compatibility issues or stability concerns when used within a UIKit-based app, especially when dealing with older iOS versions. In our case, the minimum supported iOS version is iOS 16, which makes things easier, but when we started, it was iOS 13, and we had to write version-specific code to support it. For example, we still barely use SwiftUITextField. Initially, it was because of a lack of managing-focus functionality. But even today it doesn’t fully fit our needs.
4. Tooling and Debugging
Debugging mixed SwiftUI and UIKit codebases can be challenging due to the different frameworks’ behaviors and lifecycles. E.g. compared to UIKit, SwiftUI’s view debugging shows too many layers and is flat/degraded.
5. Performance
Depending on the complexity of the app and the way SwiftUI and UIKit views interact, there might be performance implications due to the differences in rendering and layout systems.
For example, we had an issue with scroll performance when rendering the list of responses. This happened because we were using a UILabel for displaying an NSAttributedStringin the SwiftUI list. We were able to solve this issue by migrating to a newer SwiftUI SDK, like a native SwiftUI Text with AttributedString .
Working with the latest and greatest also has drawbacks; sometimes the new technology has limited support for features you need. Before iOS 15, SwiftUI offered very few text formatting tools. This caused issues with rendering highlights in the Medium iOS app.
At the 2024 WWDC, Apple introduced some cool features related to UIKit and SwiftUI working together like animations and transitions, but they still can’t solve all issues.
Using SwiftUI in UIKit sometimes requires hard decisions and not the most beautiful code, but step by step, day after day, it moves your codebase to a better state, and future you will be thankful for this (sometimes challenging) work you do today.
