The Future of Apps :Declarative UIs with Kotlin MultiPlatform (D-KMP) — Part 1/3
The original link
Three articles on the new D-KMP architecture based on declarative UI, Kotlin cross-platform, and MVI patterns.
Part 1: D-KMP Architecture and declarative UI
Kotlin cross-platform and MVI mode
Chapter 3: Stratification and team organization of D-KMP
Last update: April 8, 2021
The year 2020 is not only a year of epidemic, but also a watershed between the past and the future of APP development.
The future of 2021 apps has already begun, with declarative UIs and cross-platforms that will forever change the architecture and implementation of apps. It will be normal to create a multi-platform APP with a native UI that shares 85% of the code. The productivity of development will be greatly increased, while also improving the quality of the APP.
This article introduces the main concepts and how they fit together elegantly.
In the past
This is the way apps have always been developed: most companies develop apps on their own platforms (Android, iOS, Web) without code sharing on the client side.
In order to control the repetition of writing bands on each platform side, most applications tend to be “light clients,” placing most of the business logic and data processing on a single shared server.
This way, the server becomes “UI-oriented.” The architecture would be designed in such a way that most clicks would trigger a call to an API that would return details about the next page to be displayed, a very limited client logic.
Other client logic that requires maintaining the same set of code on each platform is generally avoided unless it leads to a meaningful customer experience.
There have been a few attempts over the years to share code on the client side, but for the most part it has been a failure, eventually reverting to native or platform-only development. Well-known examples include DropBox (by sharing C++ code) and AirBnB (by sharing RN). In other words, there is no technology in place that allows these companies to make a long-term safe investment in shared code.
In the future
In 2020, we saw two important paradigms grow, both almost in parallel: declarative UI and Kotlin cross-platform. This opens up unprecedented opportunities for cross-platform and client-side code sharing to become a preferred option for APP development.
Declarative UIs are ideal for cross-platform architectures because they are stateless and completely decoupled from business logic. By combining declarative UI and Kotlin across platforms, we can safely build an APP with a large amount of client-side shared code (up to 85%) and high performance on their respective native platforms. We can also have UI native to our respective platforms.
Applications can now be “rich client” because the cost of logic on the client side is not as high as it used to be, since each platform no longer needs to maintain the same set of logic. Apps will become very flexible and bring a lot of improvements to the user experience, reducing the need for users to wait when they click on something.
The server can become completely “UI-neutral” and focus on providing common data, removing all redundant logic because data processing and formatting can be done at the client level. This also greatly improves data throughput.
Let’s look at them one by one. Let’s start by defining a few key concepts for the coming new era of APP development.
Three core concepts for future applications
- Declarative UI (Jetpack Compose for Android, Swift UI for iOS)
- KMP (Kotlin cross-platform)
- MVI (model-view-intent)
We call this the D-KMP architecture, which stands for declarative UI and Kotlin cross-platform. The MVI mode is designed to make the two work better together.
D – KMP architecture
It is important to note that the D-KMP architecture shown here is for brand new projects.
We’re not talking about gradually introducing declarative UI and Kotlin cross-platform into an existing project.
Our goal is a clean, robust, timeless architecture that does not compromise with the past and is built on innovative technologies and paradigms.
It is also important to note that D-KMP is not a lib library, but an architecture that relies entirely on the official framework.
Let’s take a closer look at the three core details of the architecture, starting with declarative UI.
Declarative UIs are starting to grow on Android and iOS
Over the course of almost a decade, we began to experience a very important revolution in mobile frameworks. Android and iOS have both started their own new UI toolsets, both declarative and influenced by React and Flutter. They will completely replace the existing way in which individual systems define views.
Google announced Jetpack Compose at Google I/O 2019. Alpha in August 2020, beta in spring 2021, with a 1.0 release expected by the end of 2021.
Jetpack Compose supports Android 5 and above (Target API 21). This means that all of the new Jetpack Compose apis are backward compatible and do not require a new Android version. This is because Jetpack Compose is composed directly on the canvas on the lower version.
Apple announced the Swift UI at WWDC 2019, along with iOS 13. Many improvements have been made this year with the release of iOS 14. Unlike Jetpack Compose, the Swift UI update is bundled with iOS. The new Swift UIAPI is not backward compatible. But considering that all devices that support iOS 13 now support iOS14 as well (unlike usual, Apple didn’t drop any devices this year), it’s safe to use the Swift UI on apps that target iOS14.
Why declarative UI
Jetpack Compose and Swift UI are both frameworks for declarative UIs that simply represent how the UI should be presented in different states, rather than managing state directly. Declarative UIs are becoming more and more popular because you give a framework to React. Js and Flutter, both of which allow people to see how easy it is to interact with stateless components. It was their success that brought Android and iOS into the world of declarative UI.
With Jetpack Compose you can forget about Android’s clunky view system and scary Fragments. With Swift UI you can forget about VC UI Kit and the not-so-flexible StoryBoard. It’s a fresh start. This is the future!
Declarative UIs allow for a complete separation of the UI layout from the ViewModel, since no additional layers of code (using findViewById and @ibOutlet) are required to connect the two. Google’s Leland Richardson wrote a very interesting article on this topic (which I happened to translate, and here is my translation of Jetpack Compose’s underlying implementation).
Jetpack Compose is very similar to the Swift UI. There are some trivial syntactic differences (Kotlin for Jetpack Compose, Swift for Swift UI) and navigation modes, but the idea behind them is the same. In particular, data is delivered exactly the same way to these stateless UI frameworks. This is why the ViewModel is platform agnostic. We’ll talk about that in more detail later.
Declarative UI on the Web side
The most famous declarative UI on the Web is React.js (by Facebook), and it’s the framework that really makes declarative UI successful. This is an industrial-scale framework change, and without the success of React. Js, we might not be able to use declarative UI on Android and iOS by now.
Kotlin provides a very convenient wrapper around React. Js, and we can use Kotlin/React as a declarative UI for the Web. It can be introduced into our D-KMP architecture as a plug-in, just like Jetpack Compose on Android and Swift UI on iOS.
In Kotlin/React, you can reference all existing React. Js components. You can use Kotlin’s advantages over JS. You can also create custom components entirely with Kotlin. See the Kotlin/React documentation for more information.
Perhaps the most interesting addition to Kotlin/React is Compose for the Web, the Web version of Jetpack Compose currently being developed by JetBrains, the creator of Kotlin. If implementing the UI with Kotlin/React requires an additional 15% of the work (versus 85% of KMP’s shared code), Compose for Web makes that much less work, because it’s very similar to Android Jetpack Compose. So we’re really looking forward to it being released.
Desktop side declarative UI
While we wait for the Web version, JetBrains has released Compose for the desktop, which can be used to develop desktop applications for Windows, macOS, and Linux.
On the desktop side, it’s worth noting that the Swift UI already supports macOS. UI written in Swift UI works seamlessly between iOS, macOS, tvOS, and watchOS 6. We also expect Jetpack Compose to be seamless across multiple platforms (Android, desktop, and Web) in the near future.
Imagine a time in the near future when Jetpack Compose and the Swift UI will allow you to develop great apps for all platforms.
Why not a single UI framework for all platforms?
You may be wondering if there is only one set of declarative UI frameworks that will work for all platforms.
In other words, will Jetpack Compose eventually work for all Apple systems (iOS, macOS, tvOS, watchOS), or will Swift UI eventually work for non-Apple devices?
For now, if this is going to happen, it’s not going to be Done by Apple or Google, it’s going to be done by communities or third parties. We’ve already seen Jetpack Compose being brought to the desktop and Web, not by Google but by JetBrains.
Google and Apple will still focus on their own systems. This is actually very healthy for the future of UI. So there are always two separate powerful toolsets competing and innovating.
Now let’s take a look at Kotlin cross-platform: the second article.