5 Reasons Why iOS Developers Should Switch to SwiftUI 

5 Reasons Why iOS Developers Should Switch to SwiftUI

Why We Like Building iOS Apps With SwiftUI

It’s been a year since the introduction of SwiftUI — and if you’re an iOS Developer, now is probably a good time to start considering it as a viable option for building your next app. On its initial release, it was a hard sell to anyone who needed to support older versions of iOS or who didn’t want to deal with the aches and pains of adopting a brand-new framework, even though it offered a graceful, elegant way to build out User Interfaces (UI). But, after giving it some time to mature, and the widespread adoption of iOS 13, SwiftUI deserves a serious look when making your next app.

Better UI structure, I do declare!

ezgif.com-optimize.gif

Apple has taken a new approach with SwiftUI — offering a declarative solution to building out your User Interface. Traditionally, using UIKit and AutoLayout, we’re used to seeing an imperative approach at building UI.

If you’re unsure of the difference, think of declarative as telling something what to do, and imperative as how to do it.

For example, if I were to hail a cab and tell the driver where I was going taking an imperative approach, I’d say something like, “Accelerate slowly and take the first left turn, drive for 5 minutes and take a right turn on 99 street. Drive for 2 minutes, and stop at building #3905.” With a declarative approach, I’d say, “Go to 3905 99 street”.

The imperative approach in iOS development often results in complex, hard-to-read files, filled with overloaded, and overridden methods — even for the simplest screens within your app. With SwiftUI, we’re able to build clean UI that’s easy for people to understand even if they aren’t familiar with Swift or iOS development.

For things like project handoffs and onboarding new developers, this is a huge win. You’re also getting the added benefit of not having to worry about breaking constraints, and ambiguous layouts like you do with AutoLayout. Your layout either works, or it doesn’t.

Faster app development

Because you’re using a declarative approach with SwiftUI, you write less code, which in-turn means less development time. Animations, transitions, data flow and a host of other things have all been simplified to be easier to digest and implement. Things that used to feel clunky and verbose are now clear and concise.

On top of this, Xcode includes a Canvas/Live Preview feature for SwiftUI projects which allows you to see UI changes without having to compile an app every single time you want to see changes made in your app. Canvas allows you to see multiple device previews at once, eliminating the time-consuming process of firing up a simulator each time you need to see your UI on a different device.

No longer do you have to worry about storyboard, .xib files, .nib files, and the headache of Interface Builder — SwiftUI does away with these, providing one simple source of truth. By removing all the complexity surrounding compiling and viewing UI, along with the time saved from writing less code, you’re able to deliver a product a lot faster.

Seamless framework integration

swift2.jpg

Run into something you need from UIKit that isn’t in SwiftUI? No problem! Apple has provided the ability to implement UIKit elements in your SwiftUI project through the use of UIViewRepresentable and UIViewControllerRepresentable protocols. It also works the other way around — you can build SwiftUI views in an existing UIKit project.

Not only does this provide the flexibility of picking and choosing the best parts of each framework where you see fit, you’re able to minimize the risk associated with switching your project structure and development process. The transition from one framework to another comes with a lot less stress, and is less abrasive than having to choose one or the other.

Modern layout options

One of the most impressive things about SwiftUI is how the core layout elements operate. Apple has done away with layouts like UITableView, UICollectionView, UIStackView, and replaced them with Stacks and Lists. These components are incredibly flexible, predictable, and require a lot less energy to produce great results. You’re no longer plagued by having to track down broken constraints, worrying if you’ve pinned a child element to its parent improperly, or the gotchas that come along with AutoLayout.

These components in themselves are quite powerful, but paired with the newest SwiftUI features shown at WWDC2020, the layout system has become even more robust and impressive. Apple has added support for lazy-loading Grid elements, which can adapt the number of columns in a grid to fit the space available, as well as lazy-loading Stack components for building highly-customized, scrollable layouts.

A lot of these features would be an enormous undertaking if you tried to implement them in UIKit, and it would be hard to match how well they work in SwiftUI. The layout system feels more present-day CSS on the web — it’s modern, responsive, and easily translatable to multiple device sizes and types.

It’s only going to get better

Going forward, SwiftUI will be the future of development not only for iOS, but all Apple platforms. macOS, watchOS, tvOS all currently support SwiftUI development, and Apple has put a lot of time and effort into it — it’s not going away any time soon. Things like WidgetKit, the API used to develop the all-new widget feature on iOS 14 is currently only being made available to SwiftUI.

It’s an exciting time to make mobile apps, and with such a rapid progression of SwiftUI in such a short time, the future looks very bright. You can see more of the latest and greatest features that have been added to SwiftUI here.

Let’s work together

We’re addicts for the high we get when launching apps we’re proud of. If you’re ready to dig in and make some magic together, drop us a line.