What's SwiftUI and Should I use it?

SwiftUI is Apple's new development language and paradigm for building applications for its desktop and mobile platforms. In this article I'll discuss at a high level what SwiftUI is and how businesses and developers should think about its adoption in their development planning process.

What is Swift UI?

SwiftUI is a new technology Apple iOS and macOS developers can use to create native applications for Apple platforms. As the name implies, developers must use the Swift programming language to create applications with SwiftUI.

SwiftUI has the potential to dramatically improve developer productivity, reduce the cost of developing native applications for Apple platforms, and make it far easier than before to target multiple device platforms with substantially the same codebase.

What SwiftUI is Intended to Replace

Before SwiftUI, Apple developers used different technologies to create Mac and iOS software: AppKit for macOS; UIKit for iOS and other Arm-based platforms. These two incumbent app development kits are significantly different from each other, and the vast majority of iOS developers have not developed the skills to build macOS applications.?

SwiftUI unifies application development techniques and syntax across all of Apple's many device platforms, opening new opportunities for iOS developers while potentially expanding Apple's macOS software catalog--win/win!

In addition to unifying skills and techniques across Apple's platforms, SwiftUI has other, more tactical benefits that improve developer productivity and reduce development costs. One of those benefits is declarative syntax, which I'll discuss next.

Declarative Syntax

A key design underpinning of SwiftUI is that it has a?declarative?syntax, which reduces developer workload and reduces development cost.?

But what does declarative syntax mean, and why is it better??

Put simply, the code (syntax) of SwiftUI describes?what?the the UI should present--not?how?UI elements should be constructed. The?how?part is left to the runtime system.?

This paradigm shifts a great deal of work from the developer to the underlying UI subsystem--saving time and money, and reducing the occurrence of UI bugs.?

In a non-declarative syntax such as UIKit, UI code tediously describes both what?andhow every UI component is constructed.?The?how?part can be quite verbose to write, and is potentially a source of difficult to find bugs.?

This is best illustrated with a short example. In UIKit (the older syntax), the following code adds a button to the center of the screen, and prints something to the console when the user taps the button. Notice that the code is?very?explicit and verbose.

let b = UIButton()
addSubview(b)

b.heightAnchor.constraint(equalToConstant: 50.0).isActive = true
b.widthAnchor.constraint(equalToConstant: 200.0).isActive = true
b.centerXAnchor.constraint(equalTo: centerXAnchor).isActive = true
b.centerYAnchor.constraint(equalTo: centerYAnchor).isActive = true
b.setTitle("OK", for: .normal)
b.addTarget(self, action: #selector(okPressed), for: .touchUpInside)

@objc func showTOUHelp() {
   print("Do something!"
   
}        

UIKit needs to be told every detail about how to draw the button and where to position it on the screen.

The following SwiftUI code accomplishes the same task. Note how concise this is compared the the above UIKit example.?Even if you're not an iOS developer, this second example probably makes sense.?

Button(action: {
   print("Do Something!")
}) {
   Text("OK")
}

.frame(width: 200, height: 50)
        

This ease of understanding directly translates to reduced learning curve for new developers, long-term productivity, and a lower occurrence of UI bugs.

Declarative Syntax is a Megatrend

Declarative syntax isn't unique to SwiftUI, and arguably SwiftUI wasn't the first framework to adopt it. Declarative is a megatrend being adopted by most if not all major mobile application development platforms.?Other well-known platforms transitioning to declarative UI include:

• Android (Jetpack Compose)
• Flutter
• Xamarin

Where can SwiftUI be Used?

SwiftUI was originally developed to provide a concise syntax for building Apple Watch applications.?As often happens, other product teams at Apple saw SwiftUI's potential for their platforms--and jumped on board.?Over time, SwiftUI has become the future UI design language for?all?Apple device platforms.?

Today SwiftUI can be used to develop software for any of the following platforms: iOS, iPadOS, macOS, watchOS and tvOS.?

SwiftUI does require runtime support by the OS it's deployed to, and thus has minimum device runtime OS requirements of iOS 13, macOS 10.15, tvOS 13.0, and watchOS 6.0.?

Learn once, write everywhere

The vision for SwiftUI is to help developers build better software faster, and solve the current lack of skill portability between the iOS and macOS platforms.

While the tooling is designed to be used across platforms, it's important to understand that SwiftUI is expressly?not?intended as a technology to "write once, run everywhere"– the original tagline for of Java (and other technologies both before and after it).

SwiftUI isn't a "Write Once, Run Everywhere" technology. It's "Learn Once, Write Everywhere" technology.

Apple itself stresses that although the SwiftUI supported platforms are similar, they're not identical. Screen sizes vary (a lot!), and some UI elements are available only on a single platform.?

Apple's intent with SwiftUI is to provide cross-platform developers, not fully cross-platform applications.

But Code Portability is Still Quite Good

Although a single codebase won't typically look perfect without adjustments on different platforms, in practice?a lot?of SwiftUI code will be directly usable on multiple platforms with minimal modification. For example, many UI designs can be almost the same between an iPad and a Mac application–especially when up-front planning is done with cross-platform code re-use in mind!?

Conversely, the UI design for an iPad and Apple Watch app will almost never be very similar, so UI code re-use between them is an unrealistic expectation. However, code behind the UI can still be shared between these device platforms.?

What does SwiftUI mean for traditional iOS/macOS development?

Does SwiftUI mean traditional UIKit/AppKit development is dead??Probably not...at least yet.

The introduction of SwiftUI is analogous to the introduction of Swift itself back in 2014 (has it really been 7 years?!?).?Almost immediately after Swift was introduced, many asked whether Objective-C was dead as a technology. Of course it wasn't dead then--and still isn't. Objective-C is still in use today (especially at big tech firms, for reasons I won't go into fully in this article).

But it's safe to say that Swift has been very successful (even making signifiant inroads at large tech firms at this point), and has become the "go to" language for developers on all of Apple's various platforms.?

On a business and management level, the success and popularity of Swift has significantly diminished the labor pool of qualified Objective-C developers over time--and at this point that trend along is probably by itself a good reason to transition from Objective-C to Swift for those who haven't yet done so.?

I expect similar trends for SwiftUI over the next several years.?SwiftUI almost certainly will overtake UIKit/AppKit as it matures, but there's not an urgent need to rewrite UIKit or AppKit code that's already working in production.

UIKit/AppKit/SwiftUI interoperability

I've discussed SwiftUI as a 100% replacement for UIKit/AppKit--and it certainly can be that even today. A new iPhone application can be built in SwiftUI (and many already have been shipped).?

But SwiftUI can also be blended with UIKit. Why would we want to do that?

• SwiftUI Views can be added to to existing (or future) UIKit applications. This provides a way to on-ramp to SwiftUI over time. For example a new feature could be developed in SwiftUI without changing the existing UIKit application.
• Conversely, UIKit Views can be added to a primarily SwiftUI application. Perhaps the application calls for some feature that UIKit has but SwiftUI doesn't (yet) have. As SwiftUI is still maturing, this isn't uncommon in practice.

Should I Use SwiftUI in my current/next app project?

The obvious questions for many developers and product owners learning about SwiftUI will be, "Should I use SwiftUI for my next app?" and/or "Should I migrate my current app to SwiftUI?"

In the long run, the answer for virtually all Apple native development will be "yes". Apple has articulated a vision that virtually all last-mile UI development will be done with SwiftUI at some point.?The real decision is probably whether SwiftUI should be adopted?now.

Like any new technology adoption question, the answer is specific to product design requirements, the organization's risk tolerance and the development team's skills.?When considering this question, I think of it in these terms:

SwiftUI is a good candidate now when

• This is a green field, new application, and the UI requirements fit into SwiftUI's current capabilities--at least a 90% fit is enough, as the other 10% could met with UIKit interoperability.
• The application is an existing app, it is stable, there are new features that could be built with SwiftUI now, and we can foresee replacing old UI with SwiftUI over time.?
• The SwiftUI minimum OS requirements are acceptable (e.g. iOS 13). Or they will be before the SwiftUI features are shipped.
• The development team has bandwidth and openness to learn a new app development paradigm (i.e. time spent on the learning curve can be budgeted).

It might be better to wait on SwiftUI if

• The features or UI design that's planned (or already built) is highly specialized or calls for too many features that aren't directly supported by SwiftUI.?
• There's a non-negotiable requirement to support older OS versions (e.g. iOS 12 and earlier).
• The development team doesn't have the bandwidth to climb the learning curve for a new app development architecture at this time.
• The organization is very conservative, and is not willing to adopt new technologies until they've proven themselves in the market for many years, have shipped at least three major versions, etc.

Summary

If you made it this far--thank you for reading along!?I hope this has been helpful in?learning what SwiftUI is and considering whether it may fit in your next development project.?

I'm sold on the promise of the technology and like many others love working with it. But also like many others I still spend signifiant time with UIKit--maintaining and extending existing products. I expect a 2-3 year transition period where new products are developed with (mostly) SwiftUI, while existing codebases are maintained in UIKit and slowly morph into SwiftUI apps.

This post originally published at www.cuvenx.com.