A (Business Hat) Case Against Adopting SwiftUI Today

A (Business Hat) Case Against Adopting SwiftUI Today


First off, I should note that everything in me wants to write SwiftUI. How could I not? It is a great step forward for UI development and is clearly the future of development for Apple Platforms. In fact, I have two apps in the App Store that are fully SwiftUI. One of which has been using SwiftUI for over a year now.

So why write this post? This post is focused on considerations targeted at established apps. If you are going to start a new project, still think it through since SwiftUI is young, but by all means select SwiftUI in Xcode and party on!

With that said, we need to be careful about chasing new shiny things like this. If the goal of your existing app is to maintain a high velocity of delivering value to your users, then there are some considerations before declaring your whole code base as tech debt 🤪.

SwiftUI is still new

SwiftUI is now over a year old — not a lot of time for a framework to be battle tested and sharp edges worked out. Apple has had some time to improve SwiftUI, and they have done an amazing job at that! But like all new technologies there are still kinks to be worked out. Some things that come to mind:

Migration concerns

I read this blog post on migrations a while back, and it has really stuck with me. Migrations are tricky and harmful if half done or done poorly.

Back in the Swift 2 days, I was working on an Objective-C app. We ended up deciding that all new code should be in Swift. This was exciting for me since I wanted to write Swift as much as possible; however, this turned out to be more of a distraction than anything. We were all actively learning Swift while migrating this existing code base over to Swift. As a result, the code that we produced was a mixture of the different evolving opinions around what was Swifty mixed with Swift that looked like Obj-C when we converted code over. Combine that with pushing it to interop with our opinionated Obj-C architecture and the Swift 3+ changes. The result? Our code base was difficult to move in and buggy to say the least. Ultimately, we ended up distracted from the main goal of quickly delivering stable features to our users and improving the company.

This kind of parallels where SwiftUI is today. We are all figuring out what is SwiftUI-y, converting our UIKit/AppKit code over is not a direct port, pushing SwiftUI to interop with UIKit/AppKit and existing code, and adapting to framework changes as they come up.

Also, when doing a migration like this, you would hope that you can leverage tests as a safety net (even if they are throw away). The testing story for SwiftUI is not that clear right now. The best I can come up with for now is throwing down a safety net of UI snapshot tests to validate that the refactor to SwiftUI is visually correct.

But what about the new widgets?

Yeah hands are tied, use SwiftUI! This will be a nice way to start getting used to SwiftUI development :).


Like I said, SwiftUI is awesome and clearly the future of UI development on Apple’s platforms. As such, we should all be keeping an eager eye on SwiftUI and try and use it where it makes sense. Let’s just be mindful about it becoming a distraction from the reason why we write software — our end users.

p.s. If you are looking for some references, here are some good ones that come to mind:

Thank you for reading!

Feel free to reach out on Twitter — cheers!

rss facebook twitter github youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora