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

From Apple’s SwiftUI homepage: https://developer.apple.com/xcode/swiftui/

I believe that SwiftUI is the biggest shift in the Apple developer’s ecosystem since the inception of the iPhone and UIkit.

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.

A List is a UITableView on iOS/iPadOS (and I guess NSTableView or NSOutlineView on macOS).

And the NavigationView is backed by the UINavigationController .

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 ScrollView and 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 SwiftUI components.