SwiftUI vs Jetpack Compose: Pros and Cons (Part II)
Dan
Mobile Developer
Reading time: 6 min
Updated: Jul 2, 2026
Key takeaways
- SwiftUI and Jetpack Compose let you achieve more UI with far less code than UIKit or XML.
- Both offer live previews and a reactive, state-based approach in a single language.
- Trade-offs include backward compatibility limits and edge cases that still need the old frameworks.
- Both interoperate with UIKit and XML, so you can adopt them one screen at a time.
- They fit 80 to 90 percent of cases well; the safest path is a gradual, screen-by-screen migration.
Looking to build a mobile app that lasts? Then it pays to pick the right tools for the job. In the first part of this series, we explored the options for building native mobile app UI on iOS (UIKit and SwiftUI) and Android (XML layouts and Jetpack Compose).
We saw that Apple and Google both shipped new declarative UI frameworks. Each one promises to improve your app development experience.
Are they ready and worth it? Should you switch? This second part digs into the pros and cons of each framework, with integration examples and tips.
Did you miss the first part? Read it here.
Let's start with the iOS side.
The good, the bad, and SwiftUI
- Declarative framework
- Launched in 2019, updated every year
- Programming language: Swift
- Way of use: programmatic UI plus live previews
The first strong point of SwiftUI is that you achieve more with less code. Let's see a quick example.
What we want to build: a reactive label that updates as you type in a text field.
UIKit code:
SwiftUI code:
Not a big difference? Actually, it is a huge difference. We explored this in more depth in a dedicated guide to declarative UI.
Another great thing about SwiftUI is live previews. You see the UI component in real time and run it in a local context. That is a step up from UIKit, where code changes did not always reflect in Storyboards or XIB files.
SwiftUI also takes a more reactive approach than UIKit, with native support for it. You get property wrappers like @State, @ObservedObject, and @StateObject that your UI observes. When something changes, the engine rebuilds the layout for you, so you do not have to do it by hand.
In short, SwiftUI makes it much simpler to get into iOS development and build impressive interfaces, even without much iOS experience. So what is the catch?
As with any newer framework, there is room to grow, and you accept some trade-offs. One is backward compatibility. SwiftUI supports iOS 13 and above, and each new SwiftUI version is incompatible with older iOS releases. In the first few years, that slowed adoption.
As you go deeper, you see SwiftUI still leans on UIKit in many cases. For example, you cannot fully customize the NavigationBar or TabBar from SwiftUI alone. On iOS 13, lists still use UITableView. The TextEditorView cannot change its white background. The fixes for all of these rely on UIKit code, as shown below.
Popular components like ScrollViews have no delegates in SwiftUI, so you cannot read contentOffset or velocity. A workaround is to use a GeometryReader to read sizes. And to use popular libraries like Google Maps, which lack a SwiftUI API, you rely on UIViewRepresentable.
Finally, navigation looks simple with NavigationView and NavigationLinks. But it couples navigation with the UI, which makes the flow harder to control than an MVVM-C approach in UIKit. A hybrid path worked well for us: build SwiftUI views, load them into UIHostingControllers, and present them the old-fashioned way.
Now let's look at the Android side.
Jetpack Compose
- Declarative framework
- Launched in 2021 and updated regularly since
- Programming language: Kotlin
- Way of use: programmatic UI plus preview
- Backward compatible down to Android 5.0
Google describes Compose as a modern toolkit that simplifies and speeds up UI development on Android, with less code, powerful tools, and intuitive Kotlin APIs.
Let's see how much of that holds up. Since Compose is very similar to SwiftUI, we will skip the shared parts like live previews and the declarative model.
To test Google's claim of "less code," look at a common task: a scrollable dynamic list.
Doing that with XML layouts requires the following:
- A layout for the RecyclerView (the list itself)
- Layouts for each list item
- An Adapter and ViewHolder to bind layouts with data
- Configuring it all in a Fragment or Activity
Creating the same list with Compose looks like this:
Compose clearly needs less code and less time once you know it. That makes it easier to learn and to reuse UI code. And it is all in Kotlin.
So what are the downsides?
Navigation is similar to SwiftUI. You specify destinations inside composable functions, which couples the UI with the navigation logic. You can also send data between screens only as String arguments in route paths, so passing other data types is tricky. You either use a shared ViewModel or convert your data to JSON and pass it as one big string.
Some components are not supported yet, such as autosize text, flow layouts, scrollbars, and snapping. Check the roadmap for what is coming.
On performance, you may notice longer load times on older devices, especially if your app mixes XML layouts and Compose. APK size and build times also grow in a mixed app. Both improve once you fully convert to Compose.
Speaking of mixing, how do you make the new frameworks work with the old ones?
Interoperability
The great news is that SwiftUI and Jetpack Compose work alongside the older frameworks. That makes them easier to try and adopt over time.
SwiftUI integration
The first case you will meet is adding SwiftUI to a UIKit project. A dedicated component called UIHostingController lets you create a ViewController whose root view is a SwiftUI view. See the example below.
To go the other way and add a UIKit library to a SwiftUI project, you have two options:
- UIViewRepresentable for views
- UIViewControllerRepresentable for view controllers
Jetpack Compose integration
To add Compose to an XML-based app, use the dedicated ComposeView component in your XML layouts.
To use an XML layout inside a composable, use the AndroidView component. It inflates a layout and shows it in its body.
Should you use SwiftUI and Compose now?
Based on the examples above, they are a great choice for most cases. Development is faster, the code is easier to read, and you use one language across the whole app. For 80 to 90 percent of situations, they make things easier and more enjoyable.
Still, remember the edge cases. For 10 to 20 percent of your app, SwiftUI and Compose may need workarounds and bug fixes. Speed will lag during the learning phase. The bigger the app, though, the better the return, since things speed up once your team gets used to the frameworks.
The safest way to adopt them is to add one screen or component built with SwiftUI or Compose to an existing app. If it does not go well, you can revert quickly. If it looks promising, keep going and migrate step by step.
Technology keeps moving forward, and these declarative UI frameworks are part of that. They are not flawless, but they bring real advantages, so they are worth considering for your next mobile app.
We hope this series gave you insight into how to build your mobile app's UI. Thanks to our two mobile engineers, Roxana and Dan, for sharing their knowledge.
Ready to build your next app? Explore our product design services and our work.
