Combining SwiftUI & UIKit in a major production app

Last updated: 3 months ago

We, a social network with native apps for all platforms, are planning a rewrite of our UI layer to happen in early 2020 in order to align the look and feel of all native apps via a shared design system.

With the recent advent of SwiftUI, we ran into the uncomfortable question of whether we really want to rewrite our whole UI (350+ screens) using UIKit, because:

  • We're confident that very soon SwiftUI will be the standard for Apple UI
  • This UI rewrite of ours is meant to last
  • We want to keep a modern codebase down the road that makes us an interesting employer with an up-to-date technology stack

In short, we felt that rewriting the app with UIKit now would only lead to another rewrite 2 years down the line.

While SwiftUI is a fantastic new technology, it still lacks a fair amount of functionality and is prone to a variety of subtle and not-so-subtle bugs.

Thus, we decided for a half-way solution where only a limited part of the UI is implemented in SwiftUI but then hosted in UICollectionViewCells. This can be the base for future refactoring such as replacing collection views with List. This also exempts us from many of the problems affecting the current List / NavigationView (and so on) implementations.

Based on these experiences, this talk explains how we managed to integrate SwiftUI optimally in a UIKit oriented project. It will describe best practices and point out pitfalls, such as managing interoperability between two very different layout systems (SwiftUI & Autolayout).

It will also give the key learnings that we made, talk about performance optimizations, and generally give you an idea of how useful it is to run SwiftUI & UIKit side by side in a production app. We will also briefly showcase how SwiftUI greatly improves unit tests for us.

In the end, you should be able to introduce SwiftUI into your codebase in a reasonable manner, knowing that a major production app does so without (hopefully) any issues.

As explained above, while already in progress, this project is not done yet. By the time of UIKonf it will (hopefully) be done. There is a small chance that the content of the talk will be the opposite: A plea not to use SwiftUI & UIKit in the same project, and a lament on all the things we shouldn't have done. Either way, in both cases the talk should be entertaining and educational.