SwiftUI Framework is Awesome!

Introduction

Being an iOS developer working on Apple platforms has been a great ride over the years. Depending on when you started, there are some features newer developers will take for granted, e.g., iOS 5 added support for automatic reference counting. Developers who began their journey on iOS 6 or iOS 7 did not need to handle memory manually. Of course, tutorials and StackOverflow answers still had code snippets with manual memory management, but they faded over time.

A couple of things changed the iOS developer landscape; another good example is AutoLayout addition in iOS 6. At first, people hated it (along with Storyboards), and some still hate it to this day. Still, overall new developers that were starting to learn iOS development did use the power of AutoLayout to adapt to the growing amount of screen sizes.

This pattern happens every few years, and it's interesting to watch how to evolves. There will always be developers who will hate new stuff (Objective-C vs. Swift, Storyboards vs. XIB vs. coded UI). You can easily skip learning about it; if you never learned Storyboards, there's a small incentive to do it now as it's unnecessary for future UI development on Apple platforms.

SwiftLang

Another excellent example of significant changes on Apple platforms is the language changes; no one expected Apple to release Swift in 2014. It was a mind-blowing moment in every Apple developer's life. What happened after the announcement wasn't surprising; if you see how Apple released technologies over the years, Swift 1 was a barebones version that was hard to use.

Pretty much no senior developer would use it for a paid production project. Swift 2 fixed some of the issues, but it was still complicated to write. There was too much influence from Objective-C and NSStuff. Swift 3 was the first version where developers started to build production projects, the syntax was a lot cleaner, and it felt almost like a proper language. It took three iterations to get to an API and syntax that looks and feels good. After that, up until Swift 5.5, language improved rapidly with some of the long-expected features (async/await 👀). Swift development is the same as with other stuff Apple released; it took a few iterations to get it right, but after that, adoption rate took off, and developers are enjoying working with it. Even some hardcore Objective-C developers and fans started to switch to Swift as it's just a lot more modern language with lots of features.

Combine framework

Another framework that deserves a short mention is Combine. The Combine framework released in iOS 13 provides a declarative Swift API for processing values over time. This changes how developers work with async code (one of the worst things modern devs face). Up until now, there were a couple of options, use callback handlers and face callback hell. Another option was to use some external library that implements promises (e.g., Promises) or reactive extensions (e.g., RxSwift).

Using external libraries means APIs need adapting (or implementation) to work. In some cases, you would get out-of-the-box extensions for Apple native APIs, but it was always limited. Combine solves all of these issues; there's no need for external libraries, and you get a lot of native APIs that were exposed using Combine. To my surprise, Combine has worked well ever since the release, but then again, comparing SwiftUI/Swift with Combine is not a fair comparison as Combine is a lot simpler to pull off.

A new kid on the block is async/await, which is even more remarkable. Still, due to limitations, it's not usable on older versions of iOS, meaning proper adoption will have to wait for another major iOS release.

What is SwiftUI framework?

Apple platforms have seen lots of game-changing releases over the last 5-7 years, but probably the most important one (next to Swift language) is the declarative UI framework named SwiftUI. It completely changes how the approach to app building, state management, and more importantly, there's no need to worry about how to glue stuff together. You worry about how UI should look; it is a significant switch in UI development, especially since it's cross-platform in the Apple ecosystem. Nowadays, it's possible to build an iOS/macOS/iPadOS app with the same codebase (minor changes to some platform specifics).

Now we get to a significant point here; Apple developers like to hate things until they love them (except for Xcode, we'll always hate it). The same thing is happening to SwiftUI; it's a fantastic new UI framework that changes pretty much everything. The first release in iOS 13 was missing many APIs, and there were weird bugs and issues all around. iOS 14 fixed some of the problems, introduced new issues, broke down already working code, and added new APIs. Overall, it's still a mess, and if you try to build with it, be ready to debug (a lot).

After all of that, we come to iOS 15, where SwiftUI APIs are a lot more complete, async/await with all of the Task APIs makes it a lot more enjoyable to code. It's possible to see an old pattern here, avoid the first two versions and give Apple time to polish and fix issues. SwiftUI provides the ability to iterate fast and preview your UI and animations in real-time as you change code, a completely different mindset when building components. All of this together creates an excellent environment for modern and fast-paced mobile development.

To infinity and beyond 🚀

All of this is pretty much an introduction to the future of Apple platforms. Today when more and more apps are cross-platform, it's essential to provide desktop apps and mobile apps. Usually, this is done by making the Electron app and calling it a day, but this will never be as good as native feeling, especially to users that used quality native apps (take a look as 1Password 8 Beta Electron version backlash). Apple did a good thing here, as it's possible to build a single codebase with a single framework. Stakeholders will find this option more interesting as it requires less work and code for more platform coverage.

Many developers still hate SwiftUI and show its broken sides (looking at you, iOS Twitter community). Still, if you forget about that and look at what good stuff others developed with SwiftUI, you'll be impressed. Newcomers and older developers will accept SwiftUI as standard for UI in the next two to three iterations; it's bound to happen; there's nothing that can stop this. UI iteration speed is a lot faster than working with UIKit, the codebase is a lot cleaner, and it uses newer paradigms that are easier to understand (declarative UI). All of that, plus being cross-platform, will change everything; it's just a question of when stakeholders will start to demand SwiftUI for their projects and when new developers will learn SwiftUI without UIKit.

The same thing happened with Swift 3; stakeholders heard there was a new kid on the block and started to demand apps being done in Swift even when Objective-C was still heavily used, why you ask? Speed of development, developer satisfaction, being future proof, but in the end, it's all about the speed of iteration. It's just a question when will the same thing happen to SwiftUI, and it's fast approaching. Even today, you'll find developers writing Objective-C code due to some requirements or preferences; the same thing goes XIBs, Storyboards, and other features. Still, their numbers will go down with time, and you'll see a new generation of iOS developers who know only Swift and SwiftUI.

The End

Looking back at my 6-7 years of life as a professional developer working on Apple platforms, it's easy to see how much it improved; to say it's impressive would be an understatement. Currently, this period might be the best time to start iOS development as it's terrific and will only get better. Of course, this is a bit tricky, depending on where you are and what you are working on. You maybe have a low deployment target in your apps and can't use any of the newer features, you might be maintaining projects (even in Objective-C), and there's no way to get time to rewrite or upgrade.

It's hard to build an app just for the latest version of iOS. Still, then again, everything depends on what you are working on, and remember, even big companies with lots of developers are getting there (e.g., Twitter app iOS requirement is iOS 14+, what's your reason for not dropping iOS13 yet?). Developers like to think their code has to look the best, and it has to support all different versions and phones, but in the end, that's not what matters; people are using your apps and not looking at how you did it. They do not care; they want the product to work as imagined. What's underneath is irrelevant (sometimes developers have a hard time accepting this).

All of this brings us to the last point for this article, or rather to the title, SwiftUI framework is awesome! It brings everything you could need to build a modern-looking app (code-wise) that's working cross-platform. It will just get better, and as more of the community adopts it will only get more powerful and flexible. There's no reason to worry if you did not look at a single code of SwiftUI up until now. Today, it's tough to follow all the changes and work on projects simultaneously, but with iOS 15 and new and polished SwiftUI APIs, this will probably be the best time to start.