One of Apple's latest announcements at WWDC 2019 is a big one for developers: With Xcode 11 (currently in beta, and available to download via Apple's developer portal) comes SwiftUI, a declarative syntax tool for creating native app user interfaces with little actual coding. But what does that actually mean for tech professionals trying to build apps within the Apple ecosystem?

From the jump, SwiftUI does a lot right. It’s fast, produces clean and concise code, and is just plain easy to use. (One caveat: Xcode 11 beta is only usable with the macOS 10.15 Catalina beta, so you won’t be able to use SwiftUI unless you’re on Catalina.)

Apple's engineers consider SwiftUI the next paradigm of coding. It’s not necessarily a “new” idea, though; really, this is another version of the same ‘ol visual coding paradigm that engineers have been kicking around for decades.

Where SwiftUI differentiates itself is its ability to return code that’s extensible, endlessly editable, easy to read and understand, and concise. Apple’s shining example is table view, which is now distilled to a basic 20 lines of code. For anyone who has ever tried their hand at table views for iOS, this latest tweak is a welcome change from the seemingly endless code you had to write just to see something.

And that’s the code; actually creating a user interface is a drag-and-drop affair, much like Interface Builder is already. With SwiftUI, however, we no longer have to rely on XIB files and Storyboards with tenuous connections to code files. SwiftUI packages it all together.

In essence, what we have here is a high-quality UI builder that's also quite dogmatic. Apple, like any platform provider, has some distinct views on how an interface should look and operate, and SwiftUI adheres to those concepts strictly (it’s also Swift-only; no Objective-C interoperability here).

SwiftUI doesn’t handle the logic of your app; packages or functions that manage anything beyond UI updates must be written separately. Apple compares what SwiftUI spits out to code that someone is reading and explaining to you: It's easier to read than traditional code, but won’t allow you to create a complex function with ease. In other words, you'll need to write anything with some programmatic "heft" to it.

SwiftUI is intended to make cross-platform apps look great across Apple’s platforms and screens. It is easy to manage across those platforms, and allows for unique features such as adding menus to a macOS version of a mobile app, or creating a new layout for your watchOS app without spinning up a whole new project.

The Bigger Impact of SwiftUI

There are two potential impacts of SwiftUI on the broader developer ecosystem. First, it takes dead aim at apps such as Sketch, which often produce usable code based on designs that are hard to manage in Xcode. Second, it sets us up for a version of Xcode for iPad, which will likely be SwiftUI as a standalone app.

So who should care? Today, anyone building a new Apple app should really look to SwiftUI first. Not only is it far easier than the “old” method of using storyboards and linking buttons or text fields to your code files, it’s meant for streamlined creation of cross-platform apps, which Apple tells us is the future. And it accomplishes that feat with a greater degree of ease than anything before it.

Developers with existing apps may not worry too much if they’re comfortable with what they’ve created. It’s possible to make your apps SwiftUI-ready via a slight redesign, but you’re basically using old files and frameworks as universal code; that's fine, but probably only worth the risk if you want to make your app cross-platform and easier to maintain.