It’s not just hype or a phase — this is the future of making applications on Apple platforms

Thomas Ricouard
Jul 14 · 4 min read
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.

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.

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 Grid/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.

Better Programming

Advice for programmers.

Thomas Ricouard

Written by

📱 🚀 🇫🇷 [Entrepreneur, iOS/Mac & Web dev] | Now @glose 📖 | Past @google 🔍 | Co-founded few companies before, a movies 🎥 app and smart browser one.

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade