Building Your App UI: SwiftUI vs Jetpack Compose (Part I)

Native mobile app development has changed fast in recent years. Both Apple and Google launched new frameworks for building user interfaces on iOS and Android: SwiftUI and Jetpack Compose.

These are not just new tools. Unlike the older native frameworks, SwiftUI and Jetpack Compose take a whole new approach. They move UI building from imperative to declarative programming.

What does this mean for mobile developers and app founders? What are the benefits and drawbacks? And when is the right time to make the switch? At Wolfpack Digital, we ran a meetup where two of our senior mobile engineers, Roxana and Dan, dug into these questions.

Roxana and Dan, senior mobile software engineers, at the Wolfpack Digital app UI meetup at our Wolfden.

We cover it all in this two-part series. But first, some theory.

A bit of theory: imperative and declarative programming

Imperative programming is a clear sequence of instructions. It tells the computer what to do, when, and in what order. Think of it like a recipe: step-by-step directions to reach a result.

Declarative programming describes the desired result instead. The code stays abstract, so the programmer can express the goal more directly.

Let's see an example.

Question: how do I get from my place to yours?

Imperative solution:

• Go out to the main road and take a left.
• Follow street X until you reach street Y.
• Turn right, go straight, then take a right at the first light.
• Continue on this street, then take your next left.
• My house is the pink house on the left.

Declarative solution:

• Here is the address: 37 Emil Racovita, Cluj-Napoca, Cluj, 400165.

Of course, the declarative way assumes you have a GPS device to reach that address. That device is the abstraction layer. Inside, it uses sensors and rules to build the path for you, much like the imperative list of steps.

So the two terms are not opposites. The declarative approach is simply the easier one for the programmer, with one more layer of abstraction.

How it applies to mobile UI development

When building native iOS and Android apps, developers have long had imperative frameworks for the UI. With the new frameworks, we now also have a declarative UI option. Let's take them one by one.

iOS: UIKit and SwiftUI

On the iOS side, there is UIKit. It has been around since 2008, when the first iOS SDK shipped. UIKit lets you build interfaces that handle touch and show UI elements like buttons, text, and shapes. It started in Objective-C, and after Apple announced Swift in 2014, it became available in Swift too.

There are two main ways to build a UI with UIKit:

• Using the Interface Builder in Storyboards and XIB files.
• Programmatically, writing everything in code.

Things changed in 2019 when Apple launched SwiftUI, a new framework based on declarative programming. Apple has shipped a new version every year since, so the framework keeps maturing.

SwiftUI takes a more reactive approach than UIKit. Instead of defining views by size, stacking, and transforms, SwiftUI is based on states you change as needed. When a UI element has a new state, the framework rebuilds it from that state.

Unlike UIKit, there is no interface builder for SwiftUI. You use the programmatic approach in Swift. But you get a live preview of each element, so you see how it looks and behaves in real time.

SwiftUI promises more clarity and faster development. We will dig into code examples, pros, and cons in part two.

Android: XML layouts and Jetpack Compose

Now let's look at the Android side.

The first official Android SDK shipped in 2008 with a different approach to UI than iOS. It was, and still is, based on XML files. Developers define UI components there, group them, and access them from Java, and later Kotlin, code. You can also create UI elements directly in Java or Kotlin.

As you might guess, this is an imperative approach. Every change on the screen must be triggered by code. The XML layouts offer different root components, like ConstraintLayout or LinearLayout, but the approach stays imperative.

This was your only option until 2021, when Google launched the first official version of Jetpack Compose. Alpha and beta versions came earlier.

Compose is much closer to SwiftUI than XML Views were to UIKit. It follows the same reactive, state-based approach. When the data changes, Compose updates the screen automatically through recomposition. It watches the mutable data and recreates the UI elements from it.

The similarities do not stop there. Jetpack Compose keeps Android development consistent by using Kotlin, just as you use Swift across iOS. It also offers a live preview for your new components, just like SwiftUI.

Is your Android app still based on Java? You can use Compose components in a Java app, but you cannot build them in Java. Jetpack Compose supports only Kotlin, so it taps into all of Kotlin's powerful features.

Which one should you choose?

Now that we have seen where native mobile UI development is heading, should you use these frameworks for your current or next mobile app?

As you might expect, it depends on several factors. SwiftUI and Jetpack Compose come with big promises. They are also still maturing, so they carry some quirks and trade-offs.

In the second part of this series, we cover the advantages of these declarative UI frameworks, their drawbacks, what to watch for, and how to adopt them. Stay tuned.

Building a mobile app and not sure which path fits? Explore our product design services and our work.

Roxana and Dan presenting the app UI meetup organized by Wolfpack Digital.