Declarative UI — a new way of building mobile apps

Mobile apps have been around for a while, and it's fair to say that they are here to stay, at least for a few more years. This has led to the appearance of more and more frameworks and tools for building them.

Today we are going to focus on the UI side, as there's a paradigm shift happening nowadays when it comes to building the interfaces of our apps. This transition consists of moving from traditional imperative programming to declarative programming. But before diving into the details, let's see what declarative programming actually means.

Declarative programming

First of all, it's a programming paradigm that focuses on describing the desired end result and how that should look instead of listing all the execution steps that would lead to that result. This means that it doesn't express the control flow but only the desired outcome.

A more popular programming paradigm is the imperative one, which describes a step-by-step way of achieving the desired result. In other words, it's the opposite of the declarative one, and it has instructions that are changing the state of a program.

Ok, enough with the theory, let's see some…

Examples 🎯

A cute comparison would be the following:

• imperative: when you write the recipe for a dish with step-by-step instructions: 
  • mix 100g of flour with two eggs
  • stir the mix 
    etc.
• declarative: when you're describing the dish: 
  • chocolate muffins.

Again, we have "how" versus "what". 

One of the best programming comparisons that we can take is between UIKit and SwiftUI since they are both on the same platform: iOS. UIKit is the traditional well-established framework that's around for quite some time, while SwiftUI is the new guy in town, hoping to bring a new style to the table.

Let's see how we can create a custom screen using both of them. We will take as an example a simple confirmation screen from our app Raindrops.

Firstly, let's see how the UIKit approach looks, taking the programmatic way, without Xibs or a Storyboard.

UIKit code sample example

As we can see, the imperative approach would be to create instances for each UI element and perform mutations on them until we get to the final design. Then we also have to manually add all the constraints.

Now it's time for the SwiftUI version.

SwiftUI code sample example

In contrast, the declarative approach specifies from the start a blueprint that contains all the needed setup instead of starting from base instances and mutating them.
It doesn't mean that we cannot change the UI dynamically, but the difference is that every time we want to change an element, the framework takes care of redrawing everything to match the new blueprint.

As we can see, there is far less code needed in the second example, which is the declarative one. Let’s check them side by side.

 

SwiftUI was released in 2019 along with iOS 13 while UIKit is available since iOS 2 😅 it doesn't mean that the former is better; it's just newer, and it has a different approach, as we could see in the examples above. However, there are quite a few advantages that the declarative UI style brings:

• The syntax is shorter and pretty clean, so the overall development speed is higher.
• You cannot modify the UI from multiple places. There has to be a single source of truth for every component.
• UI elements can be easily reused and composed together. Maybe that's why Google named their framework Jetpack Compose?

Nonetheless, it is difficult to change how you write code, but when did anything great come easy?

Now we understand the main idea, and we saw what we could do on the iOS side.

What about other platforms?

A few paragraphs above, you could see a shy reference to Jetpack Compose. If you didn't guess it yet, it's Google's counterpart to SwiftUI, and it is based on Kotlin.

We must say that Jetpack Compose is not officially released yet, it’s only in Beta. So, if on the iOS side it's debatable if you should start a project with SwiftUI or not, on Android I would recommend you to stick to the XMLs for now, at least until Compose is officially released.

Of course, this article would not be complete without mentioning two of the most popular hybrid-app frameworks out there: React Native and Flutter. Interestingly enough, they both started with a declarative UI approach built around states.

Image source: Flutter.dev

A simple mathematical formula that would describe that would be: UI = f(state), where f represents the build methods. If something changes the app's state (you flip a switch, for example), the UI will be redrawn based on f and the new state. Since they don't have an imperative alternative, we're not going to share more code examples here.

So what should we take away?

Declarative UI takeaways

Declarative programming is here to stay... As much as I would like to end it with that rhyme, let's add one more thing. Apple and Google are trendsetters in mobile app development because they are the owners of the most popular mobile operating systems on the market. Since they are both working so much lately on their own declarative UI frameworks, it's clear that they want to push things in that direction, or, at least, to give developers another solid option. The community will have the last word eventually, but looking at the increase in popularity of all these new frameworks, they are off for a good start.

About the author:
Dan is the Head of Mobile Development at Wolfpack Digital and aims to bring value to the world in areas like programming, fitness, and personal development. Dan likes to push technologies to the limits and to create exciting products that change people’s lives for the better but are also beautiful in their own way. He's a very competitive person who loves challenges and contests, taking them in various fields like mathematics, tennis, or even driving. Besides this, he believes that people can actually love what they do (or do what they love) and we can enjoy life in a productive way too.