Jetpack Compose & SwiftUI

Hello everyone! It has been 6 months since I started working as an Android developer at Peakup. The progress was very good. We had published 5 solid Android applications on the Google Play Store. You can take a look at the list of our applications here. Our latest "Permission Management" Android application was released on October 12 "It was uploaded to the Google Play Store and became ready for use in 2019. From this date (I wrote the article 1 month later), I started coding iOS versions of the applications I wrote on the Android side with XCode.

As you know, Android and iOS systems are quite different from each other. The development process for these systems varies even more. Transitioning meant tackling a new language, a new IDE, new UI elements, a new design approach, and new user behaviors - quite a list! Honestly, I felt like a fish out of water initially. Thanks to the similarities between Swift and Kotlin, I had a bit of luck with the programming language, but sadly, the same can't be said about the interface. iOS uses a drag-and-drop method without messing with the code; Android is the exact opposite, without any drag and drop. I hoped SwiftUI would be my lifesaver, but that turned out to be wishful thinking. It leaves me wondering, 'Should we start with SwiftUI or not?' And now, should Jetpack Compose on Android come in and complicate things even further?

SwiftUI

Hey! I've been diving deep into iOS learning; I started Googling things like, 'What do I need to know for iOS?', 'Got sick from iOS.', 'iOS mindset', 'I want to be iOS.', 'Bring iOS to us.', 'iOS system requirements'… So, yeah, I went down a real research rabbit hole. 🤗 In June 2019, at WWDC, Apple launched a new UI framework called SwiftUI. This framework really simplifies UI design; once you check out the related documents and various examples online, you'll see how it speeds things up significantly and is super practical. Plus, it's easy to learn. Pumped with excitement, I thought, 'Since Apple has dropped such a solid UI framework, no one's going to bother with the Storyboard system anymore.' So, I kicked off my first iOS project using SwiftUI.

After I started working on the project, I realized that since SwiftUI was so new, there weren't many documents or examples available yet. Despite being out for just four months, many classes had already been deprecated, and they hadn't replaced them with stable, working codes - including some methods described in the documents. Of course, by 2024, there are dozens of apps on the Apple Store using SwiftUI, but back then, I could hardly find the information I needed.

For instance, I had to use the WKWebView component in the app I was writing. I was curious about how to implement it with SwiftUI. I wanted to capture the changing URLs within WKWebView, but couldn't quickly find a solution. By the time I got an answer on Stack Overflow (ios - SwiftUI WKWebView detect url changing - Stack Overflow), it was already too late.

I've never been one to take the easy way out, but I also don't like things taking longer than they should.

I finally managed to sort things out with WKWebView after a lot of effort, but even moving from one page to another in SwiftUI was a challenge because you had to wrap all your views in a NavigationView. Fitting the page I created with WKWebView into that structure didn't seem feasible. Maybe it was just my inexperience. That was just one of the many issues I faced. Despite my heart and mind sticking with SwiftUI, I reluctantly switched back to using Storyboards for the time being. Some Quora questions and articles also seemed to support this view. The app I built with the Storyboard system took two weeks. In the one week I spent on SwiftUI, I hadn't made even a quarter of that progress.

I'd like to give a small code example:

import SwiftUI

struct AlbumDetail: View {

var album: Album

var body: some View {

List(album.songs) { song in

HStack {

Image(album.cover)

VStack(alignment: .leading) {

Text(song.title)

Text(song.artist.name).foregroundStyle(.secondary)

}}}}}

This is the DeclarativeUI structure you're familiar with. Its conciseness, clarity, simplicity, and transparency literally dazzled me. For more detailed information about SwiftUI, I invite you to check out Apple's documentation. I was just wishing for such a smooth system on Android when, in October 2019 at the Android Dev Summit, they introduced a new UI Framework called Android Jetpack Compose.

Android Jetpack Compose

"It's a Declarative UI Toolkit inspired by technologies like React, Litho, Vue.js, and Flutter." - Check out the Compose introduction video.

This framework first hit the scene at Google I/O 2019, but it was pretty much up in the air back then because it wasn't something we could actually use yet. We couldn't try it out, and we could hardly guess what it was; they only showed us a few lines of code. They were like, 'We're working on this, this is the future, just giving you a heads-up.' Then, at the Android Dev Summit on October 23, 2019, they officially unveiled it, showing us what it could do. They really got us excited by saying we could download Android Studio 4.0 and start experimenting with Jetpack Compose.

From what we've seen, Compose is going to speed up our work a lot, making UI design much easier; it'll produce more readable, quicker to understand code that won't leave us wondering 'What was the coder thinking?' when we revisit it a few months later. It seems like it will nicely reduce the clutter of XML files. I can't wait to try it out and dive right in. Still, a part of me is like, 'Don't rush it, it might not be stable; when it is, it'll be the talk of the town and stuff of dreams.' Now, let me show you a code example of Compose to wrap this up.

It's so cool how you just write 'Text', open the parentheses, put in your text, and bam - it instantly turns into a TextView in the preview. I'm really curious about the underlying mechanics, and I just want to grab the developers and ask, 'How did you manage this in such a clunky Android system?'

To get more detailed information about Android Jetpack Compose, I'm adding a link to some documentation and tutorials here. Does the syntax look familiar? As you can see, Android's Jetpack Compose View Toolkit also has a DeclarativeUI structure, just like SwiftUI.

Differences

Yeah, the similarities are astonishing. Almost eerily so. Honestly, it feels like I could just copy-paste and change three to five letters, and bam - I'd have the interfaces done for both sides. And they'd be responsive, fitting every device.

As for the ties with legacy code:

• In SwiftUI, you can still use UIViewand UIViewRepresentableclasses, but fundamentally, SwiftUI is built on a new Viewprotocol. The UIViewRepresentable class acts as a bridge to use old UIKit-based components within SwiftUI. Instead of a UIViewController, SwiftUI lives inside a UIHostingController.
• Jetpack Compose operates entirely with Composablefunctions and doesn't use the old Android XML-based layout system.

SwiftUI Classes and Composable:

• In SwiftUI, structs are used and these structs implement the View protocol. (They use protocol composition instead of inheritance.)
• In Compose, Composablefunctions are used to define UI components. These are done with functions, not classes, and they truly have no connection to classes. With these functions, you can build an entirely new UI structure.

Coding Requirements:

• In SwiftUI, the body: View { } block is a mandatory structure that must be defined for every View.
• In Compose, the definition of a Composablefunction is enough to render a piece of UI, and there's no specific pattern requirement.

View Layouts:

• Both platforms support vertical (Column and VStack) and horizontal (Row and HStack) layouts. Aside from the naming of these layout structures, there are no significant functional differences between SwiftUI and Compose (as expected in a Declarative UI structure).

SwiftUI leans more towards a "Learn once, write everywhere" philosophy rather than "Write once, run everywhere," while Compose offers a truly reusable logic. Compose is open source, unlike SwiftUI.

Common Features

1. You can create custom view objects with both technologies. Each framework adopts a component-based approach, which simplifies the creation of reusable UI components.
2. One of the best features of these toolkits is their preview services. SwiftUI comes with a live preview, and thanks to SwiftUI’s preview, you can even interact with it. Android Studio also offers a live preview with Compose Preview.
3. SwiftUI requires macOS Catalina and iOS 13, while on the Compose side, you need Android Studio 4.0 and your app must target API Level 21 or higher.

The differences and similarities could go on and on. Let’s leave it here for now, and we’ll update this as the toolkits evolve.

Now, a deep question I’m curious about and you might be too if you’ve read this far: Why would two giant companies, one after the other, release new UI Toolkits and Frameworks with a DeclarativeUI structure? What’s up with DeclarativeUI anyway? Let’s talk about that in the next article.

The original version of this article is published on Medium