Lessons in SwiftUI
Article Summary
Kari Grooms from Vrbo's iOS team discovered SwiftUI wasn't just a learning curve—it was a complete rethink of how to build mobile UIs. Her team's migration revealed surprising gotchas that most tutorials won't tell you.
When Vrbo (part of Expedia Group) decided to adopt SwiftUI after WWDC 2020, they expected modern declarative UI benefits. What they got was a masterclass in framework limitations, testing challenges, and the messy reality of UIKit/SwiftUI coexistence in production apps.
Key Takeaways
- SwiftUI code is dramatically shorter: same UI requires 10x less code than UIKit
- iOS 13 lacks critical components like LazyStacks, forcing UICollectionView workarounds
- View modifier order matters: background before size styling breaks button rendering
- SwiftUI Previews failed due to naming collisions and Carthage framework path issues
- Hybrid wrapping creates Inception-like nesting: Views within UIViews within Views
SwiftUI delivers massive code reduction but requires careful architecture decisions around testing, iOS version support, and strategic UIKit interoperability for production apps.
About This Article
Kari Grooms' team ran into a wall with SwiftUI. It was missing key components that UIKit had, like UISearchController and UIImagePickerController. So even after iOS 14 added LazyVStack and LazyHStack, they had to keep using UICollectionViews.
Vrbo built a ButtonViewModel architecture that pulled view logic out of SwiftUI Views. This let them unit test button configuration, styling, and state management without needing to create actual SwiftUI components.
The team cut down their button code significantly while handling four button styles, multiple sizes, inverse variants, icon modes, and dark mode support. All of it was testable through the ViewModel without poking around inside the views.