Read this post on our new engineering blog!

WWDC 2019 contained one of Apple's most significant announcement since announcing Swift in 2014: SwiftUI. They promised it to be innovative and an effortless way to build user interfaces across all Apple platforms. Me and my two Apple Developer colleagues, forming the team behind the Collect iPhone and iPad application, were super enthusiastic about getting started with this new way of building apps.

Building an app that reaches millions of users with a relatively small team of 3 engineers is challenging. Testing views on iPad, iPhone, and several app extensions take time when done manually. The benefits of using live previews from within Xcode with SwiftUI made us decide to switch gears and adopt early.

Deciding to switch gears and adopt

Switching gears by adopting a brand new language is not easy. It can slow down development because developers need to learn a new language, and it's risky because we're not sure what to expect from SwiftUI. When resources are low, you have to be careful and consider whether the benefits weigh up to the impacts.

Within Collect, we're a meritocracy. We allow individuals to make decisions based on their talent and experiences. Our team builds on trust and honesty: we believe our colleagues are experts in what they do, and they're making the best decision possible. Therefore, it was up to our team of three iOS developers to decide whether or not to adopt SwiftUI.

However, we couldn't just decide and go. Adopting SwiftUI comes with a learning curve that takes time. It has the chance of being unstable, resulting in even more development delays, and we could even conclude, in the end, that it has been too early to start adopting SwiftUI. We had to develop a strong case to convince ourselves that we should begin adopting SwiftUI.

Today's decisions determine our future, and that also holds for the quality of our codebase. Time might be expensive today but even more costly later if we make a wrong decision. We believe SwiftUI is the future. All views we can develop in SwiftUI today will save us from rewriting them later. We took the learning curve for granted as we would run into that sooner or later, and tried to lower the risks by picking a small, isolated feature as a tryout: the new introduction screens. For users on older OS versions without support for SwiftUI, we could show the old designs. The latest introduction screens built with SwiftUI would only be visible for those with iOS 13 and up, for which SwiftUI views are available.

“An exceptionally simple way to build user interfaces”—is that true?

Apple introduced SwiftUI as an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift. A promising way to describe a new language and most-likely not considering any bugs occurring in early versions. Although Apple battle-tested SwiftUI internally by building some of their apps using this new technology, it was far from bug-free when it launched.

Yes, it's much simpler to declare views using the new syntax. However, commonly used UI elements like collection views only became available since iOS 14. Even if you start adopting SwiftUI today, you likely need to support iOS 13 with all its early-day bugs and missing components. Without draining away all the value from the above quote, I'd like to dive into our experiences of adopting SwiftUI for our brand new introduction screens.

The views we had to build were relatively simple on their own. The animation binding them together, however, was much more complicated. A classic 80/20 story arrived: 80% of the feature was easy to build while the last 20% to finish up the details took most of our time.

We managed to build the views relatively quickly. SwiftUI previews work great as long as you're developing in a small project. Segueing into our first conclusion: create your SwiftUI views in a separate project to leverage Xcode Previews. Otherwise, Xcode will generate your previews by building your complete project, making them unacceptably slow.

Secondly, you have to test on many different OS versions. It turned out that a minor iOS 13 version could make a big difference to the rendering of views. Our animation worked great on iOS 13.4 and up but broke on all lower versions. Even updates on iOS 14 broke our views sometimes. You can imagine how testing on all these versions took a lot of our development time.

Lastly, prepare for a new way of developing. We took our time to set up convenience methods to apply brand styling, and we've worked out our vision for developing SwiftUI views. Setting up guidelines takes time but is essential for building a foundation for your team to write consistently in this new UI language.

If I could turn back time?

What if we could travel in time and make the same decision today. Would we change anything? We don't regret adopting SwiftUI this early. We would, however, pick a less detailed view to start developing with it. The learning curve took a lot of time already, and the complicated animations didn't make it any easier.

SwiftUI is still young today and was even younger when announced. Deciding to adopt SwiftUI today is best done if you can drop iOS 13 or leave it out for the views you're going to build. This way, you'll run into fewer bugs from the early days, and you have fewer differences between OS versions to check. Take into account you might need to support two UIs if you're still supporting iOS 12 or lower today.

Word of advice? Make sure to adopt SwiftUI in phases. Don't start rewriting your complete app today but start with a small part of your app. Consider rewriting an existing view so that you can show the older view to older OS versions. Besides, you've already got the business logic, and you only need to focus on writing the UI, making the learning curve a bit less curvy!

The future is bright

Although SwiftUI is still in its early days, the future is bright. The declarative syntax and Xcode Previews make it easier to write views. Apple announced Swift in 2014, and we still have projects with lots of Objective-C code. We need to consider the same time range of adoption for SwiftUI.

It's a matter of time before SwiftUI takes over. We believe that adopting SwiftUI today, in phases, is the best way forward for making SwiftUI the default language to write in.