TL;DR: Flutter is likely to benefit as Apple developers see that they can use the same declarative UI techniques as SwiftUI but also run their code on many more platforms, including Android, Windows, Web, and IOT.

This article was originally published on the Very Good Ventures blog.

On June 3 at WWDC ’19 Apple made a lot of big announcements, but an important one that didn’t quite make the top news headlines was the release of SwiftUI, a new declarative UI framework for building iOS (and iPadOS/macOS/watchOS/tvOS) apps. Of course, for software developers this was probably the most exciting news of all. After all, how many of us can actually afford the new Mac Pro?

The reason why developers are so excited is that Apple has finally joined the modern era of declarative UI programming. Apple developers had to sit on the sidelines as the likes of React Native and Flutter showed off their ability to drastically improve code simplicity and reduce development times with hot reloading. Apple developers also sighed as Google announced Jetpack Compose, a new declarative UI framework for Android, at I/O ’19. So when Apple made the SwiftUI announcement it was rightly met with collective gasps and cheers in the audience.

What we are witnessing is a continuation of the declarative UI programming revolution that was popularized by React. Thanks Facebook! That needs to be recognized and applauded. Flutter also deserves credit for getting us to this point. Flutter is one of the top 10 most-starred repos on Github, was recently ranked the #3 most loved framework in the 2019 Stack Overflow developer survey, and is the #1 fastest-growing skill among software engineers by LinkedIn. As an experienced native iOS developer who converted to Flutter 2 years ago and never looked back, I have a vested interest in watching the Flutter community succeed. So how should we interpret the SwiftUI announcement?

What is declarative UI programming anyway?

For those new to the topic, I want to briefly describe what declarative UI programming actually is. So, it turns out that writing UI code is arguably the most complicated part of any modern application. Today’s mobile/desktop/web apps have to be responsive, handle device rotation, dynamic font sizes, light/dark mode, different themes, user customizations, role-based permissions, feature-flagging, and A/B testing. Now throw a couple of animations on top of all that. Oh yeah, and make everything delightful. And finish it by yesterday.

Before declarative UI programming, you would typically write your code in the following fashion: Handle the login button. Show the busy spinner. Call the backend. Hide the busy spinner. Redirect to the home screen. Show a popup on failure. In this “imperative” paradigm, you directly change individual parts of your UI in response to various events. Seems simple, but as an app gets more complex, it gets harder to update without things breaking unexpectedly. Things get complicated real fast. It becomes difficult to see the relationship between events and handle edge cases. That’s why sometimes you see apps in bizarre, inconsistent UI’s. It is the result of a combination of states that the developers did not expect.

When imperative UI programming goes wrong.

In contrast, in a “declarative” paradigm, the user interface is “declared” as a function of some data that represents it. That data is called state. As that state changes, the UI updates automatically. So, using the same example above: If no user, show login. If user, show home. If busy, show spinner. If failure, show error. The difference is that all the different states are accounted for in one place, preventing unexpected or inconsistent results. The result is usually:

Vastly reduced complexity

Fewer lines of code

Improved code quality

Reduced development times

It’s no wonder that developers love it. So Apple joining the party is kind of a big deal. It validates the declarative paradigm for the whole Apple community.

What does this mean for Flutter?

I love Flutter. It took what React Native started and ran with it. With its native performance, zero dependencies on native platform UI components, and ability to support iOS, Android, Mac, Windows, IOT, and Web, I am convinced that it is the best choice for modern application development. I am also amazed at how it has captured the mindshare of beginners and experienced native mobile developers alike. I do want to see it succeed.

In the immediate term, SwiftUI will probably reduce the incentive for Apple-only developers to adopt Flutter. Developers will be able to receive many of Flutter’s benefits including declarative UI architecture as well as hot reload, which will alleviate the pain of Swift’s famously slow compile times. However, since SwiftUI only works on iOS 13 and up, apps will still have to support the old imperative style for several years before fully transitioning. That means potentially maintaining two entirely separate UI codebases for a long time!

With Flutter, Apple developers will see that they can use the same declarative UI techniques they have already learned, but also run their code on many more platforms.

In the longer term I think that Flutter will ultimately benefit from SwiftUI. Inevitably, the pressure will mount on Apple-only developers to port their apps to other platforms such as Android, Windows, and Web. With Flutter, Apple developers will see that they can use the same declarative UI techniques they have already learned, but also run their code on many more platforms. At that point, Flutter will be there waiting with open arms. Interesting in getting a head start? Contact us!