Why You Should Consider SwiftUI for Your Next Project
It’s not just hype or a phase — this is the future of making applications on Apple platforms
It’s even greater for AppKit developers, because, not only can you run your iPad apps on macOS, but now you can also make a new macOS target using a new UI Toolkit in a modern API and a declarative design pattern.
Yes, it’s in beta, it’s early days. Some people will tell you that you should not waste your time learning something that is not production-ready yet, because you can’t make “apps” with it for now.
However, It’ll give you a head start for the years to come. You’ll get familiar with a whole new way of architecting your app. If you’re already familiar with reactive/declarative programming, such as React, you’ll most likely be fine.
But if you’re not, you have to know that you’re not giving orders to your UI anymore. You describe it and then you update your states to make things happen and update your components.
But SwiftUI’s groundbreaking approach is not only about the design pattern. It’s the fact that, for the first time, we have a unified UI Toolkit for all Apple platforms, and it’s above any current API.
“SwiftUI is an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift. Build user interfaces for any Apple device using just one set of tools and APIs” — From Apple’s official SwiftUI introduction.
Of course, UIKit nor AppKit are instantly deprecated. Apple doesn’t actually mention that. But personally, I can see it happening during the next decade; it’ll be a slow trend of components being introduced or migrated to SwiftUI.
For now, as SwiftUI lacks numerous native components that decades-old frameworks provide, Apple makes it very easy to expose anything you need from UIKit or AppKit to SwiftUI. You can follow their tutorial here.
A the moment, a lot of components in SwiftUI are backed by their UIKit and AppKit counterparts.
List is a
UITableView on iOS/iPadOS (and I guess
NSOutlineView on macOS).
NavigationView is backed by the
But that means that you should see everything in SwiftUI as a contract (actually everything is a protocol in SwiftUI).
The fact that the underlying implementation of
NavigationView is a
UINavigationController, is an implementation detail.
Now that Apple provides a common UI language across all its platforms to push and pop views, they can, in the future, provide a new implementation/behavior without breaking anything in your app code.
SwiftUI is one layer above the current UI frameworks while still allowing to implement anything you want because it has a very efficient custom drawing API.
If something you need doesn’t exist, such as a
UIPageViewController, you can bind it from
UIKit, but you could also reimplement it quite easily with
GeometryReader as a native high-order component.
I’m not saying that you should reinvent the wheel, I would be the last person to do that, but it’s just that
SwiftUI already provides you with the tools you need to implement anything you want.
And it’s flexible enough. I guess Apple strongly emphasizes the UIKit binding/representable because they don’t want to scare people away due to the lack of native
In my opinion, SwiftUI’s abstraction level for high-order components will allow Apple to iterate much faster on SwiftUI API. And all the primitives we’re currently lacking (like a
CollectionView) will come in time.
But What About My New Project?
In my opinion, if you are starting a new application project in September or during the next year, there is almost no reason not to leave it to Xcode 11 default, which is now SwiftUI.
Of course, it depends on your user target, and, right now, a lot of applications will still need to support iOS 11 and 12, and maybe even iOS 10.
But if you want to ship it fast, if targeting 80% of the iOS ecosystem is enough, then you should definitely go with SwiftUI (once you’re comfortable with it). It’s a future proof framework and it’s faster to iterate on your concept, ideas, and design because of the live preview and declarative API.
And anything you miss from the old days you can import from UIKit with very few lines of code.
If you’re like me, with a big application as your day job which needs to support iOS 10, 11 and 12, well, you can totally ship some new and shiny iOS 13-only features made in SwiftUI.
There is no reason to wait, SwiftUI is here to enjoy now!
Thanks for reading.