Choosing Between SwiftUI and UIKit
Article Summary
Joel from OkCupid's engineering team built the same login flow twice—once in SwiftUI, once in UIKit—to support millions of users across iOS versions. Here's what he learned about making them coexist.
When SwiftUI launched, OkCupid faced a dilemma: adopt the new framework without abandoning users on iOS 12 and older. Their solution? Build features side-by-side in both frameworks, sharing business logic while maintaining backwards compatibility. This deep dive covers the technical approach, shared view models, and hard-won lessons from production implementation.
Key Takeaways
- UIHostingController bridges SwiftUI views into UIKit hierarchies with version checks
- Shared LoginViewModel eliminates duplicate business logic across both frameworks
- UIViewRepresentable wraps UIKit components for reuse in SwiftUI views
- Custom transitions require explicit zIndex and withAnimation() wrapping to work correctly
- Adding weak_framework SwiftUI linker flag prevents crashes on iOS 12
OkCupid successfully runs SwiftUI and UIKit side-by-side by sharing view models and business logic while duplicating only the UI layer, enabling gradual adoption without dropping older iOS support.
About This Article
OkCupid's LoginSample project had to work with UIFont and UIColor across both frameworks. SwiftUI's Font and Color types don't accept UIKit equivalents directly, so conversion logic was needed.
Joel used toll-free bridging to cast UIFont as CTFont and initialize SwiftUI's Color with UIColor. He also built convertible protocols with default implementations to handle trickier properties like stack view alignment.
The team got nearly identical login views working on both frameworks by putting all type conversions in the shared LoginViewModel. This meant they didn't have to maintain separate design specs for UIKit and SwiftUI.