SwiftUI, but not all at once
This piece looks at what it actually took to bring SwiftUI into a very large consumer app, instead of the usual small demo-project version of the story. The main takeaway is that the hardest part was not the framework itself so much as the people, product planning, and long tail of existing UIKit code that already worked fine.
The team ended up avoiding a full rewrite and only used SwiftUI for new features, especially ones targeting newer iOS versions. That let newer engineers move faster without forcing longtime UIKit developers to rebuild stable screens for no clear user benefit. Feature flags and version-based rollouts also mattered, since a big app cannot assume everyone is already on the latest iPhone software.
The article also says SwiftUI adoption came with extra design-system work, because UIKit components could not just be dropped into the new setup. Still, by 2026 the framework sounds much more mature: faster prototyping, better state handling, easier testing, and stronger cross-platform reuse. At the same time, UIKit still has advantages for things like very large lists, custom layouts, and tighter scroll control.
Comment: It has a very specific “the future is here, but unfortunately it has to coexist with the entire past” energy.
