All technologies have their advantages and disadvantages, resolve particular problems, but never all of them. Thus, your choice will depend on specific tasks.

Guys from Jetbrains have made an incredible attempt to optimize development costs and reuse the code. Moreover, such reuse is possible not only within one platform but also between different platforms (Android and iOS). If your development team wants to keep native UI for each platform, then Kotlin Multiplatform Mobile is your perfect option.

It is due to the fact that Kotlin Multiplatform doesn’t do UI at all. It, instead, does business logic for Android and iOS apps. Because of the special configuration of the project, it is possible to make a project that will be compiled in the Android library with specific code for Android, and in the iOS framework with the corresponding code for iOS. From a technical perspective, there are no more problems with using the same code on iOS and Android at the same time. When you debug your code, you only need to edit it once, and changes will happen on both platforms. However, on the native side of applications, it would be better not to share the following:

• the whole interface;
• binding the interface to the shared Viewmodel from the shared code library;
• platform-specific features: work with camera, NFC, Touch ID, or Bluetooth.

And in any case, sharing UI code across platforms is not necessary. This usually requires several iterations to make the user UI and behave more natively. This, in turn, requires additional development cycles.

Flutter uses canvas from native SDK of different platforms and draws its UI component on that canvas using Material design specifications. React Native uses native components mapped to js code. React makes it possible to update the application logic without rebuilding and re-uploading to the store (the js code is downloaded from the servers and immediately starts working on the device, without updating the entire application).

As for the business logic, it is also common in Flutter and React native, but written in Dart and JavaScript respectively, which mobile developers accustomed to the native stack are not familiar with. That is, these platforms will require a communication bridge between native and non-native code.

The design consistency for all versions of the operating system and between the operating system is the benefit of Flutter as well. This technology also allows you to easily create your own custom design. It is hardly possible to compare the high development speed and high productivity of Flutter with other technologies, as it is definitely its undoubted advantage.

There are no intermediate layers to deal with in Kotlin Multiplatform Mobile, which virtually eliminates any interop bottlenecks. And because Kotlin Multiplatform works with the native platform ecosystems, developers can use the tools and libraries they’ve always used, including SwiftUI and Jetpack Compose. You may code around the limitations with Kotlin, Swift, or any other language. But in the case of Flutter, we have to stick to Dart only and in React Native we have to stick with js only.

Kotlin Multiplatform doesn’t require a VM, while React Native does. Even though Flutter also doesn’t require a VM in production, you should write in a non-native language in a non-native ecosystem. At the same time, it is very easy to write native code at any level of coding and at any layer of the architecture in Kotlin Multiplatform.

Unlike Flutter or React Native, where you should proceed with their infrastructure, KMM has the power to get integrated with any existing project. ​​Kotlin Multiplatform does not become its own ecosystem but works with ecosystems of the native platform. You may use those tools and libraries you’re used to, including SwiftUI and Jetpack Compose. Any limitations you face can always be coded around using Kotlin, Swift, or any other language that is convenient for solving this specific problem with the least risk.

Implementation of KMM can be carried out step by step, without the need to stop the current development process. We are preparing a roadmap for expanding the use of KMM in the project so that after each step a release to the store can be carried out. It is also important that we are expanding the use of KMM with the current application code, which helps to save the project from new bugs.

In the KMM project, only one specialist is required to make the common code and the native side of its platform, and it will be required to connect a specialist from another platform only to embed UI to existing logic. The code is written only once, which eliminates the risk of having two sets of bugs instead of one, which you will get here.

As a result, the support and development of the application become much cheaper, more efficient, the implementation of various features will also be noticeably faster and at the same time, you will save full nativeness for the developer and user.

Read more about KMM in our blog.

KMP vs Flutter vs React Native was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello! My name is Sergey Panov, and I am a mobile developer at IceRock. Today, I will be using our Campus app as an example to demonstrate profiling and optimization techniques for Jetpack Compose.

Campus is an app that allows students to view their class schedule. Its main feature is the schedule screen consisting of two pagers for weeks and days. When users tried to swipe them, it caused the app to hang, but we managed to fix it.

Here are the topics discussed in the article:

1. Recomposition Counts. Pinpointing Excessive Recompositions.
2. Compose Compiler Metrics. Identifying the Root Causes of Excessive Recompositions.
3. CPU Profiling. Finding “Hot” Methods and Freeing up the CPU.
4. GPU Profiling. Learning Which Components Take a Long Time to Draw.
5. More Tips on Fixing Bugs Identified with Profiling Tools.

Recomposition Counts. Pinpointing Excessive Recompositions

Issue. The first concept we need to highlight is that of recomposition.

Rendering a screen in Compose consists of traversing the graph of composable functions. If a graph node changes its state (i.e. arguments of a composable method, values of MutableState or animations change), the subgraph is updated, that is, the functions are called again. Such an update is called a recomposition.

Recompositions are fast and should not present any issues, but frequent recompositions can cause an app to slow down.

This is a distinctive feature and a pitfall of Compose. After all, a developer can make some mistakes leading to excessive recompositions, for instance, recreate an object instead of reusing it. This results in unnecessary computations and performance issues.

Solution. In large projects, these mistakes might be tricky to detect by the unaided eye, so Android Studio provides our eyes with an aid — a tool called Recomposition Counts.

It can be enabled in Layout Inspector to see how often a composable function is called or skipped. Follow this guide to display these stats.

Application. Let’s use Campus as an example to check whether we have any excessive recompositions. We run the project in the emulator and navigate to Layout Inspector. After we’ve enabled Recomposition Counts, two new columns appear that show the number of recompositions and skips for each composable method. Now we can see that, with each swipe to the next day, ScheduleDayPage and RemoteStateContent methods are recomposed three times instead of one and don’t get skipped at all.

This means that we have managed to pinpoint the issue and identify the method that requires a closer look:

@Composable
fun ScheduleDayPage(
    state: RemoteState<ScheduleDay>,
    onItemClick: (ScheduleDetails) -> Unit,
    viewAds: (ScheduleDay.Lesson) -> Unit,
    clickOnAds: (ScheduleDay.Lesson) -> Unit
) {
    ...
}

Compose Compiler Metrics​. Identifying the Root Causes of Excessive Recompositions

Stable data types​

Issue. To understand why a method can be recomposed multiple times, we need to learn the concept of stability.

Stability allows the compiler to be sure that the type either does not change or notifies the composition when a change occurs. The compiler does not check whether a composable method has changed, if all of its arguments are stable.

Thus, stable data types are such types that either produce immutable instances or notify the composition about their state changes. Besides stable and unstable data types, there is also the third type — immutable. This is a more strict type that ensures that the object does not change at all.

To put it more rigorously, a stable type must satisfy the following conditions:

1. The result of equals will always return the same result for the same two instances.
2. When a public field of the class changes, the composition will be notified.
3. All public field types are stable.

For the third condition to be satisfied, there must be stable types that developers could use to create their own stable data types. Jetpack Compose Compiler considers the following types stable: primitive types, String, function types, enumerations.

To gain deeper insight into the recomposition and stable data type concepts, I recommend reading this article by Denis Golubev. It demonstrates the following example:

// All the class fields are immutable. This is a stable class.
class StableClass1(
    val immutableValue: Int
)

// Composition knows when the state changes thanks to MutableState.
// This is a stable class as well.
class StableClass2(
  val mutableState: MutableState<String>
)

// There are mutable fields. This is an unstable class.
class UnstableClass1(
  var immutableValue: String
)

// A field belongs to an unstable type. This is also an unstable class.
class UnstableClass2(
  val unstableTypeField: UnstableClass1
)

Developers can also mark classes with the @Stable and @Immutable annotations.

Solution. To identify stable and unstable types, as well as skippable and restartable methods, which we detected with Recomposition Counts, we can use the Compose Compiler Metrics tool.

To get stats for the project, we need to add a task into app/build.gradle.kts and run the release build with the respective compiler flag enabled, as described in the article.

As a result, we will see four files in the build/compose_metrics folder that contain the following:

• app_release-classes.txt contains information on class stability:

unstable class MigrationScreen {
  unstable val navController: NavController
  <runtime stability> = Unstable
}
stable class ExpandedStateStrings {
  stable val expandString: String
  stable val collapseString: String
  <runtime stability> = Stable
}

• app_release-composables.txt contains information on whether methods are recomposable or skippable:

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun TopAppBarTitle(
  stable modifier: Modifier? = @static Companion
  stable name: String
  stable date: String
  stable weekName: String?
  stable menuExpanded: MutableState<Boolean>
)

• app_release-composables.csv contains the same details but presented as a table.
• app_release-module.json contains general information on the project:

{
"skippableComposables": 693,
"restartableComposables": 838,
"readonlyComposables": 0,
"totalComposables": 882,
...
}

Application. Let’s get back to Campus: we were interested in the ScheduleDayPage method. To find the information on it, we will check the app_release-composables.txt file:

restartable scheme("[androidx.compose.ui.UiComposable]") fun ScheduleDayPage(
unstable state: RemoteState<ScheduleDay>
stable onItemClick: Function1<ScheduleDetails, Unit>
stable viewAds: Function1<Lesson, Unit>
stable clickOnAds: Function1<Lesson, Unit>
)

As we can see, the method is not skippable and will be recomposed whenever applicable. We can also note that state is not a stable argument.

To fix this, we can annotate RemoteState and ScheduleDay classes as @Immutable after ensuring that these classes will not change after they are constructed.

Do not “slap” this annotation on classes with var fields or fields that contain lists.

This will resolve the issue of class instability, but we are not done with the method just yet. The metric has it marked as skippable, but in Layout Inspector we can still see excessive recompositions.

Unstable lists​

Issue. There is a way to override class stability with annotations, but it does not solve the stability issues with lists, sets, and maps.

Solution. Chris Ward offers a solution to this problem that uses the kotlinx-collections-immutable library, which allows you to specify that a composable method should take an immutable list as an argument.

@Composable
fun StableGrid(
    values: ImmutableList<GridItem>
) {
    ...
}

Unstable lambdas​

Issue. Our ScheduleDayPage class has function arguments as well, which you should be careful with in Compose.

Let’s check out the method initialization part:

@Composable
internal fun ScheduleScreenContent(
    selectedDate: LocalDate,
    onDateSelected: (LocalDate) -> Unit,
    onItemClick: (ScheduleDetails) -> Unit,
    viewAds: (LocalDate, ScheduleDay.Lesson) -> Unit,
    clickOnAds: (LocalDate, ScheduleDay.Lesson) -> Unit,
    scheduleDayForDate: (LocalDate) -> StateFlow<RemoteState<ScheduleDay>>
) {
    CalendarDayPager(
        selectedDate = selectedDate,
        onDateSelected = onDateSelected,
        dayContent = { date ->
            val scheduleDayFlow: StateFlow<RemoteState<ScheduleDay>> = remember(date) {
                scheduleDayForDate(date)
            }
            val scheduleDay: RemoteState<ScheduleDay> by scheduleDayFlow.collectAsState()
            ScheduleDayPage(
                state = scheduleDay,
                onItemClick = onItemClick,
                viewAds = { lesson -> viewAds(date, lesson) },
                clickOnAds = { lesson -> clickOnAds(date, lesson) }
            )
        }
    )
}

Take a look at how we pass functions to our ScheduleDayPage method.

Compose has a concept of unstable lambdas, which has been described in great detail by Justin Breitfeller.

One of the highlights of his article is how the compiler processes lambdas; namely, it creates an anonymous class with an invoke() method to put lambda content in it. In other words, every time we pass a lambda, we create an object of the anonymous class, which does not have a hash that would allow the compiler to compare it at the recomposition stage. So, the compiler thinks that the graph node state has changed and a recomposition is required.

Thus, Compose Compiler Metrics does not mark lambdas as unstable, yet recomposition still takes place.

In addition to passed arguments, lambdas may have external arguments (e.g., context), which might result in differences between the classes generated by the compiler.

Solution. The same article presents four ways to deal with this issue.

1. Method references. By using method references instead of lambdas, we can prevent a new class from being generated. Method references are stable function types and will remain equivalent between recompositions.

// Instead of a lambda…
{ lesson ->
    viewModel.playHooky(lesson)
}
// use a method reference
viewmodel::playHooky

2. Remember. Another option is to remember the lambda instance between recompositions. This will ensure the exact same instance of the lambda will be reused upon further compositions.

// Create a remembered object and pass it on initialization
val playHookyRemember: (Lesson) -> Unit = remember { { viewModel.playHooky(it) } }

Android documentation recommends making use of remember.

3. Static functions. If a lambda is simply calling a top-level function, the compiler considers it stable, since top-level functions do not take external arguments like context.

4. @Stable type in a lambda. As long as a lambda is only capturing other stable types it will not be updated by the compiler on graph recomposition.

var skippedLessons by remember { mutableStateOf(listOf("Biology", "Geography", "Chemistry")) }
Schedule(
    playHooky = { lesson ->
        skippedLessons += lesson
    }
)

Application. Going back to Campus, let’s use this new knowledge to fix incorrect lambda passes like so:

@Composable
internal fun ScheduleScreenContent(
    selectedDate: ComposeDate,
    onDateSelected: (LocalDate) -> Unit,
    onItemClick: (ScheduleDetails) -> Unit,
    viewAds: (LocalDate, ScheduleDay.Lesson) -> Unit,
    clickOnAds: (LocalDate, ScheduleDay.Lesson) -> Unit,
    scheduleDayForDate: (LocalDate) -> StateFlow<RemoteState<ScheduleDay>>
) {
    CalendarDayPager(
        selectedDate = selectedDate,
        onDateSelected = onDateSelected,
        dayContent = { date ->
            val scheduleDayFlow: StateFlow<RemoteState<ScheduleDay>> = remember(date) {
                scheduleDayForDate(date.toLocalDate())
            }
            val scheduleDay: RemoteState<ScheduleDay> by scheduleDayFlow.collectAsState()

           // Lambda is moved to a separate object with ‘remember’
            val viewAdsRemember: (ScheduleDay.Lesson) -> Unit =
                remember(date) { { lesson -> viewAds(date.toLocalDate(), lesson) } }

           // Lambda is moved to a separate object with ‘remember’
            val clickOnAdsRemember: (ScheduleDay.Lesson) -> Unit =
                remember(date) { { lesson -> clickOnAds(date.toLocalDate(), lesson) } }

            ScheduleDayPage(
                state = scheduleDay,
                onItemClick = onItemClick,
                viewAds = viewAdsRemember,
                clickOnAds = clickOnAdsRemember
            )
        }
    )
}

CPU Profiling. Finding “Hot” Methods and Freeing up the CPU

CPU Profiler

CPU profiling has to be the most powerful tool against app hanging. On top of that, optimizing CPU usage of your app has many other benefits, such as faster and smoother user experience and improving battery life of the device.

You can use the profiler to inspect CPU usage of your app and thread activity during interaction with the app.

Application. This article by Takeshi Hagikura is a good guide on getting the CPU profiler up and running. Let’s figure out what these stats are good for using Campus as an example. Run the project in the emulator and go to the Profiler tab.

Once the app is initialized, the CPU, Memory, and Energy graphs will be displayed. We will focus on CPU stats. In its detailed view you should see the following:

To record the stats, click Record, interact with the app for a while, and click Stop.

After the record is created, you should see the following screen showing CPU usage over the recorded interval (1), app interaction stats (2), threads (3), and detailed thread analysis (4).

Flame Chart​

Next, we will focus on the Flame Chart tab, which contains a chart of function calls with associated CPU usage time. This chart helps with identifying the processes that run longer than expected, which we can optimize.

First, in the CPU Usage window, we select the interval that we are interested in. Then we can pinpoint it in the Threads window. Let’s select the most prominent bars.

Here are the values we should focus on:

1. Component draw time. The standard refresh rate for the majority of smartphone screens is 60 Hz. That means that the displayed image is fully updated 60 times a second or every 16.67 milliseconds.

So, for the UI to be smooth, this should be the maximum time for drawing a component. Thus, pay attention to the “hottest” methods.

To calculate the drawing time, consider the proportion of values in Flame Chart to the number of seconds in the selected interval. The exact interval duration can be found in the Summary tab.

2. CPU usage. Try to keep the CPU idle most of the time, let it stay “cool”.

3. Components we can influence. You can select those using the search bar. For instance, if you search for the project name, the profiler will highlight parts of the “flame” with your methods in color and the text in method bars in bold.

4. Methods we can move to another thread. Some intensive tasks can be separated into another thread. For instance, that could be interactions with databases.

Read this article for more details on CPU profiler capabilities.

Application​. Now let’s go back to Campus. In our case we have swipes over the schedule screen that we would like to optimize. Let’s pick one of these in the CPU Usage window and select the main thread in the Threads window. Then we can search for our project: this highlights three methods that take up a lot of CPU time.

We are going to examine just one of them. The WeekPage method takes up a whopping 400 milliseconds in the 4 seconds interval. To calculate it more precisely, we should average over several values. Take note of the approximate value for CPU time used on this method: 95 milliseconds.

@Composable
fun WeekPage(
    startOfWeek: LocalDate,
    selectedDate: LocalDate,
    currentDate: LocalDate,
    onDateSelected: (LocalDate) -> Unit
) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
            .padding(horizontal = 16.dp),
        horizontalArrangement = Arrangement.SpaceBetween
    ) {
        DayOfWeek.values().forEach { dayOfWeek ->
            val date: LocalDate = startOfWeek.plus(DatePeriod(days = dayOfWeek.ordinal))

            val simpleDateFormat = SimpleDateFormat("EE", Locale.getDefault())
            val dayOfWeekName = simpleDateFormat.format(date.toJavaDate()).uppercase()

            val shape = RoundedCornerShape(8.dp)
            Box(...) { ... }
        }
    }
}

Looking at our code, we can see an obvious flaw: SimpleDateFormat is initialized in the loop body for each Row. We can fix this by moving the initialization away from Row and by using remember.

After the fix, let’s check the results. By doing this, we reduced the time it takes to draw WeekPage to 60–70 milliseconds (the image shows an interval of about 1 second):

System Trace​

You can also get CPU usage stats focused on composable methods only. To do so, use the Jetpack Compose Composition Tracing tool.

Jetpack Compose Composition Tracing is available starting with the following versions:

• Android Studio Flamingo Canary 1,
• Compose UI 1.3.0-beta01,
• Compose Compiler 1.3.0.

Compose Composition Tracing can display composable functions of Jetpack Compose in System Trace Android Studio Flamingo. Follow the instructions in the article by Ben Trengrove and install the appropriate version of Android Studio, then add the dependency into app/gradle.kts.

Application. Select the System Trace configuration in CPU profiler, click Record, interact with the app for a while, and click Stop.

After the record is created, you should see the following screen:

When checking the system trace, you can view trace events in the thread timeline to see the details on the events occurring in every thread.

We have several new tabs: Display (1), Frame Lifecycle (2), CPU Cores (3), and Process Memory (4). The Threads tab looks a bit different and displays a chart of composable function calls now.

These tabs show activity for each core, the size of physical memory that the app uses currently, and more.

The Threads tab displays a call chart, while the detailed thread stats also show Flame Chart, where only composable method stats are shown.

In Threads, you can click a method to search for it across the entire recorded interval and see how many times the thread was called and the average time spent for each call.

Read the official documentation for more details on System Trace capabilities.

GPU Profiling. Learning Which Components Take a Long Time to Draw

Another important profiling tool is the GPU profiler.

The documentation states that the Profile GPU Rendering tool displays a scrolling bar chart showing the time it takes to render frames of the user interface against the reference value of 16.67 milliseconds per frame.

To use this profiler, you will need a device running Android 4.1 (API level 16) or later. A guide on enabling it is available in the documentation.

The green horizontal line represents the value of 16.67 milliseconds. To reach 60 frames per second, the vertical bar for each frame has to remain below this line. Every time a bar goes above this line, the animation may stutter.

The documentation describes bar color coding.

Application. Using Campus as an example we can take note of prominent blue, light green, and dark green bars.

This shows us that creating and updating lists (blue bars) takes long, which could be because we have many custom views or onDraw methods do some intensive work. Processing onLayout and onMeasure methods (light green bars) takes a long time as well, which might indicate that a complex view hierarchy is drawn. On top of that, a lot of time is spent on animators performed for the views and on handling input callbacks (dark green); view bindings during scrolling, such as RecyclerView.Adapter.onBindViewHolder(), also typically occur during this segment and are the most common source of slowdowns in it.

The next image shows a chart of the app after various optimizations described above.

The results show that there is still room for optimization.

More Tips on Fixing Bugs Identified with Profiling Tools

I gathered a few tips from the official documentation and this article by Mukesh Solanki.

1. Always use remember in composable methods. Recomposition can occur at any time for a number of reasons. If you have a value that is supposed to survive a recomposition, remember will help you keep it that way.

2. Use lazy layouts only when necessary. Using LazyRow for a list of five items can slow rendering down significantly.

3. If at all possible, refrain from using ConstraintLayout. Use Column and Row instead. ConstraintLayout is a system of linear equations, which requires more computations than generating elements one after another.

Read more about design in our blog.

Optimize or Die. Profiling and Optimization in Jetpack Compose was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I will tell you about the approaches we use at IceRock. Our company specializes in outsource development of mobile apps, so we constantly look for new ways to speed up the development and enhance tried-and-true workflows.

Why a Prototype is Better than a Screen Map

Before we start the development, we prepare one or several prototypes of the future app. This is more efficient than going straight to design or starting to develop the app right away.

A screen map is a set of images showing all app screens and their relationships. It visualizes the flow of the screens, but it doesn’t allow you to get a feel for the result and understand how usable the interface will be. In other words, it is less illustrative.

Clickable prototypes are more informative. We divide prototyping into two parts: we use a “wireframe prototype” before the design, and a “design prototype” after. A wireframe prototype is a schematic prototype that helps us understand the navigation and functionality aspects of an app. A design prototype is a product assembled once the UI design is complete. It is used to demonstrate the future app to the customer, for marketing purposes, and sometimes for testing. It also shows the developers how the final app is supposed to work.

After the design, we make a clickable prototype. The level of detail in this prototype can vary according to the client’s needs: it can be low-fidelity or high-fidelity.

Low-fidelity prototypes consist of static images with active links to the next screens on the buttons. This is the type of prototype we used for the Snow4u project.

High-fidelity prototypes are very similar to the app and fully interactive: you can type any text in the input fields, there are animations and transitions between the screens, and sometimes they can even perform complex calculations, such as commission on loan returns or currency conversion. For example, when developing the Ambit app, we created a high-fidelity prototype to work out all the little details of the interface.

The prototype explains the processes in the app better than the screen map thanks to its immersive nature. When used in a large project, a screen map turns into a maze that’s hard to navigate and blurs the logic of the app. But with a prototype, you focus on one screen at a time: the customer or developer just clicks the buttons as if the prototype were a full-fledged app, and everything becomes clear. As a result, the developer and the customer get a vivid example of the desired result, with a clear picture of how the elements would behave in different situations. This way you can solve most UX-related issues before development even starts.

When One Prototype Just isn’t Enough — So You Make Several!

There are cases where it’s more convenient to make several prototypes. This is what we did for the Primetime app, for example, which is used for online orders and food delivery. We created separate prototypes for different types of orders and payment methods: first we made a prototype for pickup orders from food trucks, then another prototype for takeout orders, and a third prototype just for adding payment methods. The fourth and last prototype was for loading animations. Technically, this task could have been implemented within a single prototype, but in practice it was faster to build separate ones.

We chose this approach because Primetime was a complex app with several modules built over time, so we developed a dedicated prototype for each module. This approach allowed us to start developing one prototype while experimenting with the next one. This kept the experimenters from interfering with the programmers who were implementing the app based on the first prototype without any confusion. As we had separated the prototypes initially, we organized many subsequent stages along the same lines.

As things stand, it only makes sense to use this approach for large projects. What’s more, prototyping tools are evolving: at the time, this was the only optimal solution for a project of this scale. Nowadays, we tend to develop a single prototype for multiple use cases, an option made possible by the new features of ProtoPie, where we create our prototypes.

Recently two of my “for fun” prototypes have been featured by ProtoPie. The first one lets you make a wizard move around using loud sounds. And the second one is a prototype for games from the Squid Game series.

Here’s another case study. Before developing an app for Russia Running, a sports event platform, we created a prototype that became the basis for the app. The prototype shows all the tabs, click animations and loading screens. You can enter search queries or adjust the filters. For this app, we developed a prototype feature that allows you to root for a particular competitor and watch them move along the track in real time. Thanks to this work, the developers were able to accurately assess how much the app would cost. This detailed prototype cost USD 1,500 and took only three weeks to make.

In the same prototype, we tested all the animation parameters for the pie charts that show the tournament participants’ statistics. This made things easier for the programmer, allowing them to transfer the timings and animation variables from the prototype into the code and saving them time. Without a prototype, it’s almost impossible to complete an animation at the first attempt: it is hard to explain how it works without a visual example.

Why We Write Code Manually During Implementation Instead of Using Code Generators

When the prototype is ready and approved, developers start implementing the idea. Of course, there are external tools that can help turn a static design into a piece of code or a finished app. For example, Supernova Studio allows you to apply primitive logic to a static design, and then generates code that can be assembled into an app.

But the generated code has the following issues:

1. The prototype doesn’t indicate what data is needed for the backend and where it should come from: it is still the programmer’s job to specify this.
2. The program generates suboptimal code, and it takes just as much time to make this code readable and optimized as to create similar code from scratch.
3. Adjusting your design and ideas to the limitations of app builders is also difficult and can be outright impossible.

This is why developers still need to get their hands dirty when turning a prototype into a full-fledged app, although we are constantly looking for ways to optimize this process.

How Prototypes Can Help When Creating an App

Can be used to test hypotheses. You can show a prototype to a focus group or an investor, get feedback, study the needs of the target audience, and decide on further development.

Helps to demonstrate an idea. When investors can experience something close to the final app, it is easier to impress them and convince them to invest in full-scale development.

Improves communication with the client. A prototype clearly shows what the end result will be like. If the client had something else in mind, you can still painlessly course-correct at this stage. As a result, the finished app will be exactly what the client is expecting, and you won’t have to spend time and money redoing it.

Reduces risks at the development stage. When you’re identifying the client’s requirements, you can quickly build a wireframe prototype to make sure you don’t miss anything important when it comes to the project’s navigation and functionality. The developer will know how each button and screen of the future app is supposed to work. If something can’t be done or requires certain technologies, this will be clear before development starts.

And a high-fidelity prototype put together at the design stage enables you to do design reviews and easily find and fix logical and compositional errors in the UI design.

Saves time. Creating a standard prototype takes one week, after which the client can test their idea and decide whether it is worth investing in full-scale development, which would take several months.

Within a single prototype, you can test various cases separately from each other and provide references to them in the ToR. This makes things easier for analysts, developers, and the client, and speeds up your work: while one case is being prototyped, the next team can start work on another.

For example, when a high-fidelity prototype is ready, QA specialists can get straight on with preparing multiple test cases for further testing of the app while it is being developed.

Allows you to start your ad campaign early. Even before development begins, you can use the prototype for marketing purposes, e.g., on landing pages, in posts, in videos, etc.

Saves money. Prototyping requires a separate budget, but it cuts development costs by reducing risks at the development stage. Moreover, even if the client’s idea turns out to be unsustainable, they’ve only spent USD 1,500 on a prototype, rather than USD 20,000 on developing a full-fledged app.

Do You Always Need a Prototype?

Absolutely not. Sometimes making an app prototype is not cost-effective, for instance, if your app is basic, with no problematic features or intricate artistic design.

For some features, a suitable prototyping tool doesn’t even exist yet. This is usually the case when the goal is to test a technical implementation rather than a visual one, such as implementation of augmented reality. We believe that within the next few years this kind of prototyping will become a reality too. For now, the developer has to come up with the behavior of this kind of element and implement it all on their own.

In other cases, when the customer wants to see the visual result of the programmers’ work, prototyping can be a quick and inexpensive way to demonstrate what an app is going to be like.

How are you doing with prototypes? Have they helped speed up development and made your programmers happier? Share your thoughts in the comments!

We’d be happy to consult on prototyping for teams and businesses, and we’re also available to help with development. You can contact us on this page.

Follow our Linkedin account to stay tuned.

Read more about design in our blog.

Prototyping as a Quick and Cost-Effective Way to Test Hypotheses was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

What the client wanted

The app had been commissioned by Ucar, a car wash marketplace. Since we had had prior relationship with Ucar, the client was already familiar with our approach and came to us specifically looking to take advantage of our expertise in KMM with plans to create two versions of the app — Android and iOS.

The product was supposed to solve the problem of access to car washes — the idea was to create something like Uber, but for car washes. At the same time, we needed to incorporate the client’s backend with up-to-date information on car washes in the area, such as operation hours, prices and promotions, as well as to set up a feature for service selection aтв payment.

The app was intended primarily for cab drivers, carsharing service providers, and commercial vehicle drivers. We also included a separate set of features for private car owners.

How we made searching for car washes convenient

The app helps car owners find the most suitable car wash on the map in terms of location, price and current promotions. For this we developed several features and provided access to up-to-date information.

1. Moika-Moika shows car washes on the map with all the necessary information: working hours, prices, promotions, and free capacity status.
2. The app chooses rates depending on whether the user is a taxi driver or a regular car owner.
3. Users can pay for the services straight away in the app. This way, when they arrive at the car wash, the employees are already aware of which services they are supposed to provide and can identify the client’s car by the license plate.
4. You can add several cars to the app to find the best option for each vehicle. Services for passenger cars and large-sized vehicles are priced differently, so this can be a useful feature for multiple car owners.

How the Moika-Moika app was developed

We started the development from scratch. The task wasn’t difficult, so we had just one developer and a team leader involved. To accelerate the implementation, we used our MOKO libraries. We regularly create and update KMM open-source libraries to expand their applicability to specific tasks.

When creating the architecture, each feature (e.g., authorization, service selection, rate selection) was isolated into a separate module. This is a standard approach that allows developers to work on their own modules concurrently while not interfering with others.

We prefer to handle all aspects of development, but this time the client did the design and the backend by themselves and had us develop only the mobile app. Since the app was being developed at the same time as the server, the API configuration would sometimes get changed without coordination with our developer. This affected the launch date. For example, when the client would introduce a change in specifications which we would discover only towards the end of the sprint, it delayed the delivery date of the whole volume of performed works. To accelerate the development process, we agreed with the client to inform each other about any changes beforehand. This allowed us to avoid potential errors in the app.

How long it took

It took us two months to create the MVP app. The entire project, however, was seven months long.

We worked in two-week Agile sprints. The start of a sprint included task setting and distribution, and calls every other day with questions or preliminary results. At the end of the sprints, we released builds and received feedback on what modifications were required.

The app was released in summer 2021.

Currently, Ucar is cooperating with a large number of taxi companies and is receving a lot of positive feedback on the app. As of now, we continue to support and update the app with works to introduce general UX improvements and update the bonus system in the pipeline.

Why we used the Kotlin Multiplatform Mobile

KMM has two major advantages: it allows you to write code for both platforms, Android and iOS, while implementing a fully native UI. In other words, the resulting app will look as envisioned by the designer, or the way the users of a given platform are accustomed to. This feature of KMM allowed us to develop the Moika-Moika app based on the design dlivered in advance by the client.

How the client benefited from KMM

We had already launched the Android version with a shared code and were ready to quickly create an iOS version, as originally planned. However, after the launch it became clear that the demand for an iOS version was still insufficient. Because of that, its development was shelved.

Ultimately, the customer didn’t incur any losses, since the cost of developing an Android version in KMM is the same as creating a native Android app. And if the demand for the iOS version increases, the client will be able to utilize the existing code to develop it faster and more cost-efficiently.

This is why both we and our clients appreciate KMM so much — it’s a reliable tool for developing complex projects. By writing a common code for iOS and Android, you can save money short-term due to shared logic compared to native development, and in the long term, you are able to save on labor costs for updates.

We’d be happy to consult teams and businesses on mobile app development with Kotlin Multiplatform Mobile or help with development. You can contact us on this page.

Read more about KMM in our blog.

Why Businesses Choose Kotlin Multiplatform Mobile: Native UI and Improvement Potential was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

When should you integrate KMM?

You can migrate to Kotlin Multiplatform Mobile both at the start of your development and at the implementation or launch stage. In order for the migration to make sense, one or more of the following conditions should apply:

1. You already have an app for multiple platforms, Android and iOS, or you have just started developing such an app.
2. Your app with Android and iOS versions has a complex business logic but a simple UI. For instance, it uses offline synchronization.
3. You already have an Android app in Kotlin, but you urgently need an iOS version which utilizes your previous work.

60% of developers use or have tried Kotlin Multiplatform in production according to this recently published survey by JetBrains.

What are the benefits of KMM integration?

It can potentially save you up to a third of your budget. This is mainly because you develop a common code base for two platforms, Android and iOS, which can be done by a single developer.

You can speed up your development by 25% and implement new features on both platforms faster and easier in the future.

The projects will behave identically on these platforms without any discrepancies in minute details or complex cases.

iOS and Android developers will share the context, which will allow them to understand each other’s code in any part of the business logic and to promptly improve and fix it.

These might be the reasons why over 75% of those who have played around with Kotlin Multiplatform are considering to use it for their production projects.

How does KMM migration occur?

The process of migrating to KMM depends on your current situation with the project. There are three basic scenarios. Let’s use our case studies as examples.

Scenario 1. You have an app on both platforms and you need expert advice on developing common business logic.

This is the type of migration we did for Profi.

Profi is an app for searching for tradespeople and professionals in different fields. The app runs on iOS and Android. The customer asked us to help with migrating its business logic from the Android app to multiplatform.

The process we went through:

1. We signed an NDA.
2. We analyzed the project.
3. After that we created an individual plan for KMM integration.
4. The customer used our plan to move business logic to common code.

How long it took and how much it cost. In general, an integration using this scenario can take anywhere from two weeks to half a year depending on the project, and the cost starts at ~$6600. But in this case the customer did most of the work himself, and we only helped them plan their migration. Our part took us just a few days: in this time we analyzed what the customer had already done to create common code and prepared the plan for business logic migration.

The plan for this project included the following steps:

1. Set up Kotlin Multiplatform support in the Gradle module.
2. Move platform-independent classes to commonMain.
3. Replace JVM/Android libraries with their multiplatform counterparts.
4. Move JVM-dependent code to be changed to commonMain.
5. Move Android-dependent code to be changed to commonMain.
6. Make public interfaces of the common logic components easy-to-use on both platforms.

Afterwards the Profi team was able to use our review in their work.

Scenario 2. Your team has had some success in trying KMM, and you only need expert advice.

This was how we worked with Footballco, an international service for watching football, which also runs on both iOS and Android.

We joined the project at the launch stage. The customer’s team first created common business logic on their own and plugged it into their Android and iOS apps, and afterwards they reached out to us for advice.

The process we went through:

1. We signed an NDA.
2. We analyzed the project.
3. We have provided our recommendations and learning materials.
4. The customer implemented some of the recommendations and contacted us for an explanation about another part.
5. We went over the unclear parts during a conference call.

How long it took and how much it cost. Analyzing and planning usually takes two to five days, and the cost starts at $1300. The audit for this project took us three days and came out at exactly $1300.

Here are some of our recommendations for this project:

1. Streamline the Gradle configuration using the official plugin and our open-source libraries.
2. Enable project hierarchy to use IDEA hints and auto-completion features in iosMain.
3. Enable Kotlin/Native cache, since this significantly improves debug build time.
4. Avoid transitive module export and enable it explicitly for the required modules and libraries to improve build time.
5. Move away from manually wrapping coroutines in favor of auto-generated ones to get equivalent asynchronous methods based on closures on the Swift side.
6. Set up object freezing right in the init to avoid potential errors with multi-threaded operation.
7. Fix the bug with the iOS app launching: one of the Gradle plugins was working incorrectly. It turned out that the Gradle task podspec was configured for a static framework, but the last build of the framework was dynamic. To fix this, we suggested making podspec generate a dummy dynamic framework, so that everything compiles nicely.

Scenario 3. You have to urgently release an iOS version for the existing Android app without interrupting the development to merge business logic of both apps afterwards.

This is what we did for GetMega, an app for multiplayer online gaming and chatting. We based the common code on the Android version, which was already written in Kotlin, and designed it for iOS integration. This allowed the customer to get two apps with common logic without interrupting their work on the features of the Android app.

The process we went through:

1. We signed an NDA.
2. We analyzed the project.
3. After that we created an individual plan for KMM integration.
4. Then we wrote code for the second platform with the integration in mind, so that the customer could integrate it with the Android version on their own.

How long it took and how much it cost. This is the most expensive and complex service, the cost can start at ~$13000. Analyzing and planning usually takes two to five days. Developing an app with a common code can take one to six months, and the integration with the original platform might require anywhere from two weeks to several months. For this project the analysis took us three days and the development was finished in three months. And the customer stayed within the budget of ~$40000.

Which parts do developers move into the common code according to statistics? Between the platforms, 76% of developers share data models, 66% share networking, and 65% share data serialization.

We’d be happy to consult teams and businesses on mobile app development with Kotlin Multiplatform Mobile or help with development. You can contact us here.

And here’s a final piece of statistics for you: 45% of developers have participated in more than one Kotlin Multiplatform project. Tell us in the comment section whether you are one of them ;)

Read more about KMM in our blog.

Faster Development at a Lower Cost. Migration to Kotlin Multiplatform Mobile was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mobile application development can be a complex and time-consuming process, requiring developers to write separate code for each platform they want to target. To help streamline this process, JetBrains recently released Compose Multiplatform, a UI framework that allows developers to write UI for Android, iOS (Alpha), Desktop, Web (Experimental) in Kotlin common code. While Compose Multiplatform is a powerful tool for creating cross-platform user interfaces, it has some limitations when it comes to handling non-UI mobile features like permissions, geolocation, and biometric authentication. To address these limitations, developers can turn to the MOKO libraries, a set of Kotlin Multiplatform Mobile (KMM) libraries that are designed to work seamlessly with Compose Multiplatform.

What Compose Multiplatform Allows You to Do

Compose Multiplatform provides a powerful UI framework that enables developers to create consistent and responsive user interfaces across multiple platforms using Kotlin common code. This means that developers can write a single codebase that can be used to create UIs for both Android and iOS platforms. With Compose Multiplatform, developers can use a declarative approach to build UI components, making it easier to create complex UIs with less code. Compose Multiplatform also provides support for animations, theming, and custom layouts, making it a versatile and flexible tool for creating cross-platform UIs. Starts from Compose Multiplatform 1.4.0 all material ui that was developer for Android now available for iOS too.

What Compose Multiplatform Does Not Do

While Compose Multiplatform is a powerful tool for creating cross-platform user interfaces, it has some limitations when it comes to handling non-UI mobile features like permissions, geolocation, and biometric authentication. For example, Compose Multiplatform does not handle Android configuration changes. Additionally, Compose Multiplatform does not provide built-in support for requesting runtime permissions or tracking geolocation on Android or iOS platforms. This is where the MOKO libraries come in.

How MOKO Complements Compose Multiplatform

The MOKO libraries are a set of KMM libraries that are designed to work seamlessly with Compose Multiplatform. These libraries can help developers to handle common mobile features in a cross-platform way, without having to write platform-specific code. Here are some of the key features of the MOKO libraries:

• moko-resources: This library provides support for managing shared resources, including images, fonts, strings, plurals, raw resources, and more. With moko-resources, developers can easily load resources from their shared code and use them in their Compose UI.
• moko-mvvm: This library provides support for implementing the MVVM pattern and handling Android configuration changes. With moko-mvvm, developers can create ViewModel classes that can be shared across multiple platforms, enabling them to handle view logic and state management in a consistent and efficient way.
• moko-permissions: This library provides support for requesting runtime permissions on Android and iOS.
• moko-media: This library provides support for selecting and displaying images on Android and iOS. With moko-media, developers can easily select images from their shared code and display them in their Compose UI, or send them to a server.
• moko-geo: This library provides support for tracking geolocation on Android and iOS. With moko-geo, developers can easily track the user’s location from their shared code, enabling them to create location-aware applications that work seamlessly across multiple platforms.
• moko-biometry: This library provides support for implementing biometric authentication on Android and iOS. With moko-biometry, developers can easily implement touch and face ID checks from their shared code, enabling them to create secure and efficient authentication flows across multiple platforms.

Where to Find MOKO Libraries and Compose Multiplatform Templates

Developers interested in using Compose Multiplatform and the MOKO libraries in their own projects can find more information and resources on the official MOKO website and the Compose Multiplatform website. In addition, the IceRock Development has configure several official Compose Multiplatform templates to work with the MOKO libraries.

Template for Android and iOS applications and template for Android, iOS, and desktop applications.

Conclusion

Compose Multiplatform and the MOKO libraries offer developers a powerful set of tools for creating cross-platform mobile applications with maximum code reuse. With Compose Multiplatform, developers can write UI for Android and iOS in Kotlin common code, while the MOKO libraries provide support for common mobile features like permissions, geolocation, and biometric authentication. By leveraging these tools, developers can streamline their development process and create mobile applications that work seamlessly across multiple platforms, with less code and fewer bugs. If you’re interested in exploring Compose Multiplatform and the MOKO libraries for your own projects, be sure to check out the resources available on the MOKO website and the Compose Multiplatform documentation, and consider using one of the pre-configured templates to get started quickly and easily.

Maximizing Mobile Code Reuse with Compose Multiplatform and MOKO Libraries was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

MOKO resources is a multiplatform Kotlin library that provides a convenient way to access resources like images, colors, strings, and fonts in your Kotlin Multiplatform projects. With the release of version 0.21.0, MOKO resources now includes support for Compose Multiplatform, allowing developers to easily access resources across all supported platforms.

One of the key benefits of using MOKO resources with Compose Multiplatform is the ability to easily use fonts, colors, and images in your UI. With the fontFamilyResource, colorResource, and painterResource functions provided by MOKO resources, it's easy to reference resources from your shared code.

In this article, we’ll take a closer look at how to use MOKO resources with Compose Multiplatform, and how it can help you build better multiplatform applications.

Usage

MOKO resources provides several functions for accessing resources like images, colors, strings, and fonts. Here’s a brief overview of how to use each of these functions:

ImageResource

To display an image in your Compose Multiplatform UI, use the painterResource function with the ID of the image resource you want to use:

Image(
    painter = painterResource(MR.images.logo),
    contentDescription = null
)

FontResource

To use a custom font in your Compose Multiplatform UI, use the fontFamilyResource function:

Text(
    text = "Hello, World!", 
    fontFamily = fontFamilyResource(MR.fonts.custom_font)
)

StringResource

To display a localized string in your Compose Multiplatform UI, use the stringResource function with the ID of the string resource you want to use:

Text(text = stringResource(MR.strings.hello_world))

ColorResource

To set the color of a Compose Multiplatform component, use the ColorResource class with the ID of the color resource you want to use:

Text(
    text = "Hello, World!",
    color = colorResource(MR.colors.background)
)

AssetResource

To load the contents of an asset file in your Compose Multiplatform UI, use the AssetResource and extension function:

val assetContent: String? by MR.assets.some_asset.readTextAsState() 
Text(text = assetContent.orEmpty())

FileResource

To load the contents of a file in your Compose Multiplatform UI, use the FileResource and extension function:

val fileContent: String? by MR.files.some_file.readTextAsState() 
Text(text = fileContent.orEmpty())

Compose Multiplatform Screen

To show how to use MOKO resources with Compose Multiplatform, let’s build a simple screen that displays an image, a text input, and some localized text. Here’s the code:

@Composable
internal fun App() {
    MaterialTheme(
        colors = if (isSystemInDarkTheme()) darkColors() else lightColors()
    ) {
        Column(
            modifier = Modifier.fillMaxSize()
                .background(color = MaterialTheme.colors.background)
                .padding(16.dp),
            horizontalAlignment = Alignment.CenterHorizontally
        ) {
            Image(
                painter = painterResource(MR.images.moko_logo),
                contentDescription = null
            )

            var text: String by remember { mutableStateOf("") }

            OutlinedTextField(
                modifier = Modifier.fillMaxWidth()
                    .padding(top = 16.dp),
                value = text,
                colors = TextFieldDefaults.outlinedTextFieldColors(
                    textColor = MaterialTheme.colors.onBackground
                ),
                onValueChange = { text = it }
            )

            val counter: Int = text.length
            Text(
                modifier = Modifier.fillMaxWidth()
                    .padding(vertical = 8.dp),
                text = stringResource(MR.plurals.chars_count, counter, counter),
                color = colorResource(MR.colors.textColor),
                fontFamily = fontFamilyResource(MR.fonts.cormorant.italic)
            )

            Button(onClick = { text = "Hello, ${getPlatformName()}" }) {
                Text(text = stringResource(MR.strings.hello_world))
            }

            val fileContent: String? by MR.files.some_file.readTextAsState()
            Text(
                modifier = Modifier.padding(top = 16.dp),
                text = fileContent.orEmpty(),
                color = MaterialTheme.colors.onBackground
            )

            val assetContent: String? by MR.assets.some_asset.readTextAsState()
            Text(
                modifier = Modifier.padding(top = 16.dp),
                text = assetContent.orEmpty(),
                color = MaterialTheme.colors.onBackground
            )
        }
    }
}

With this simple example, we can see how easy it is to use MOKO resources with Compose Multiplatform to build UIs that look and feel great across all supported platforms.

Full code you can see in moko-resources GitHub repository.

Conclusions

MOKO resources is a powerful library that provides a convenient way to access resources like images, colors, strings, and fonts in your Kotlin Multiplatform projects. With the release of version 0.21.0, MOKO resources now includes support for Compose Multiplatform, making it even easier to build great multiplatform applications.

Using MOKO resources with Compose Multiplatform allows developers to easily access resources across all supported platforms, and to create UIs that look and feel great everywhere. With the fontFamilyResource, colorResource, and painterResource functions provided by MOKO resources, it's easy to reference resources from your shared code, and to create UIs that are consistent across all platforms.

In this article, we provided some examples of how to use MOKO resources with Compose Multiplatform, including how to load images, fonts, colors, strings, and assets in your UIs. We also showed how to use MOKO resources to build a simple screen that displays an image, a text input, and some localized text.

In summary, if you’re building Kotlin Multiplatform applications with Compose Multiplatform, MOKO resources is an essential library to have in your toolkit. Its support for Compose Multiplatform makes it easy to create consistent and great-looking UIs across all supported platforms, and its convenient resource-loading functions make it easy to access resources from your shared code.

Thanks

I want to say thanks for great community members, that helps us to create new release.

@kevincianfarini , @jittya , @zacharee , @Cilestal , @InsanusMokrassar , @wakaztahir , @PaulWoitaschek

And also, thanks to OpenAI for ChatGPT. This article was written with great help of ChatGPT .

Links

• https://github.com/icerockdev/moko-resources
• https://github.com/icerockdev/moko-resources/tree/master/samples/compose-resources-gallery
• https://github.com/JetBrains/compose-multiplatform
• https://github.com/icerockdev/moko-resources/releases/tag/release%2F0.21.0
• https://moko.icerock.dev
• https://www.jetbrains.com/lp/compose-mpp/

MOKO resources 0.21 with Compose Multiplatform support was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

We at IceRock Development have been using the MVVM approach for many years, and the last 4 years our ViewModel are shared in the common code. We do it by using our library moko-mvvm. In the last year, we have been actively moving to using Jetpack Compose and SwiftUI to build UI in our projects. And it require MOKO MVVM improvements to make it more comfortable for developers on both platforms to work with this approach.

On April 30, 2022, new version of MOKO MVVM — 0.13.0 was released. This version has full support for Jetpack Compose and SwiftUI. Let’s take an example of how you can use ViewModel from common code with these frameworks.

The example will be simple — an application with an authorization screen. Two input fields — login and password, button Log in and a message about a successful login after a second of waiting (while waiting, we turn the progress bar).

Create a project

The first step is simple — take Android Studio, install Kotlin Multiplatform Mobile IDE plugin, if not already installed. Create a project according to the template “Kotlin Multiplatform App” using CocoaPods integration (it’s more convenient with them, plus we need it to connect an additional CocoaPod later).

git commit

Login screen on Android with Jetpack Compose

The app template uses the standard Android View approach, so we need to enable Jetpack Compose before implementation of UI.

Enable Compose support in androidApp/build.gradle.kts:

val composeVersion = "1.1.1"

android {
    // ...

    buildFeatures {
        compose=true
    }
    composeOptions {
        kotlinCompilerExtensionVersion = composeVersion
    }
}

And we add the dependencies we need, removing the old unnecessary ones (related to the usual approach with view):

dependencies {
    implementation(project(":shared"))

    implementation("androidx.compose.foundation:foundation:$composeVersion")
    implementation("androidx.compose.runtime:runtime:$composeVersion")
    // UI
    implementation("androidx.compose.ui:ui:$composeVersion")
    implementation("androidx.compose.ui:ui-tooling:$composeVersion")
    // material design
    implementation("androidx.compose.material:material:$composeVersion")
    implementation("androidx.compose.material:material-icons-core:$composeVersion")
    // Activity
    implementation("androidx.activity:activity-compose:1.4.0")
    implementation("androidx.appcompat:appcompat:1.4.1")
}

When running Gradle Sync, we get a message about the version incompatibility between Jetpack Compose and Kotlin. This is due to the fact that Compose uses a compiler plugin for Kotlin, and the compiler plugin APIs are not yet stabilized. Therefore, we need to install the version of Kotlin that supports the Compose version we are using is 1.6.10.

Next, it remains to implement the authorization screen, I immediately give the finished code:

@Composable
fun LoginScreen() {
    val context: Context = LocalContext.current
    val coroutineScope: CoroutineScope = rememberCoroutineScope()

    var login: String by remember { mutableStateOf("") }
    var password: String by remember { mutableStateOf("") }
    var isLoading: Boolean by remember { mutableStateOf(false) }

    val isLoginButtonEnabled: Boolean = login.isNotBlank() && password.isNotBlank() && !isLoading

    Column(
        modifier = Modifier.padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        TextField(
            modifier = Modifier.fillMaxWidth(),
            value = login,
            enabled = !isLoading,
            label = { Text(text = "Login") },
            onValueChange = { login = it }
        )
        Spacer(modifier = Modifier.height(8.dp))
        TextField(
            modifier = Modifier.fillMaxWidth(),
            value = password,
            enabled = !isLoading,
            label = { Text(text = "Password") },
            visualTransformation = PasswordVisualTransformation(),
            onValueChange = { password = it }
        )
        Spacer(modifier = Modifier.height(8.dp))
        Button(
            modifier = Modifier
                .fillMaxWidth()
                .height(48.dp),
            enabled = isLoginButtonEnabled,
            onClick = {
                coroutineScope.launch {
                    isLoading = true
                    delay(1000)
                    isLoading = false
                    Toast.makeText(context, "login success!", Toast.LENGTH_SHORT).show()
                }
            }
        ) {
            if (isLoading) CircularProgressIndicator(modifier = Modifier.size
(24.dp))
            else Text(text = "login")
        }
    }
}

And here is our android app with authorization screen ready and functioning as required, but without common code.

git commit

Authorization screen in iOS with SwiftUI

Let’s make the same screen in SwiftUI. The template has already created a SwiftUI app, so it’s easy enough for us to write screen code. We get the following code:

struct LoginScreen: View {
    @State private var login: String = ""
    @State private var password: String = ""
    @State private var isLoading: Bool = false
    @State private var isSuccessfulAlertShowed: Bool = false
    
    private var isButtonEnabled: Bool {
        get {
            !isLoading && !login.isEmpty && !password.isEmpty
        }
    }
    
    var body: someView {
        Group {
            VStack(spacing: 8.0) {
                TextField("Login", text: $login)
                    .textFieldStyle(.roundedBorder)
                    .disabled(isLoading)
                
                SecureField("Password", text: $password)
                    .textFieldStyle(.roundedBorder)
                    .disabled(isLoading)
                
                Button(
                    action: {
                        isLoading = true
                        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
                            isLoading = false
                            isSuccessfulAlertShowed = true
                        }
                    }, label: {
                        if isLoading {
                            ProgressView()
                        } else {
                            Text("login")
                        }
                    }
                ).disabled(!isButtonEnabled)
            }.padding()
        }.alert(
            "Login successful",
            isPresented: $isSuccessfulAlertShowed
        ) {
            Button("Close", action: { isSuccessfulAlertShowed = false })
        }
    }
}

The logic of work is completely identical to the Android version and also does not use any common logic.

git commit

Implement a common ViewModel

All preparatory steps are completed. It’s time to move the authorization screen logic out of the platforms in common code.

The first thing we will do for this is to connect the moko-mvvm dependency to the common module and add it to export list for iOS framework (so that in Swift we can see all public classes and methods of this libraries).

val mokoMvvmVersion = "0.13.0"

kotlin {
    // ...

    cocoapods {
        // ...
        
        framework {
            baseName = "MultiPlatformLibrary"

            export("dev.icerock.moko:mvvm-core:$mokoMvvmVersion")
            export("dev.icerock.moko:mvvm-flow:$mokoMvvmVersion")
        }
    }

    sourceSets {
        val commonMain by getting {
            dependencies {
                api("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.1-native-mt")

                api("dev.icerock.moko:mvvm-core:$mokoMvvmVersion")
                api("dev.icerock.moko:mvvm-flow:$mokoMvvmVersion")
            }
        }
        // ...
        val androidMain by getting {
            dependencies {
                api("dev.icerock.moko:mvvm-flow-compose:$mokoMvvmVersion")
            }
        }
        // ...
    }
}

We also changed the baseName of the iOS Framework to MultiPlatformLibrary. This is an important change, which we will not be able to connect CocoaPod with Kotlin and SwiftUI integration functions in the future.

It remains to write the LoginViewModel itself. Here is the code:

class LoginViewModel : ViewModel() {
    val login: MutableStateFlow<String> = MutableStateFlow("")
    val password: MutableStateFlow<String> = MutableStateFlow("")

    private val _isLoading: MutableStateFlow<Boolean> = MutableStateFlow(false)
    val isLoading: StateFlow<Boolean> = _isLoading

    val isButtonEnabled: StateFlow<Boolean> =
        combine(isLoading, login, password) { isLoading, login, password ->
            isLoading.not() && login.isNotBlank() && password.isNotBlank()
        }.stateIn(viewModelScope, SharingStarted.Eagerly, false)

    private val _actions = Channel<Action>()
    val actions: Flow<Action> get() = _actions.receiveAsFlow()

    fun onLoginPressed() {
        _isLoading.value = true
        viewModelScope.launch {
            delay(1000)
            _isLoading.value = false
            _actions.send(Action.LoginSuccess)
        }
    }

    sealed interface Action {
        object LoginSuccess : Action
    }
}

For input fields that can be changed by the user, we used MutableStateFlow from kotlinx-coroutines (but you can also use MutableLiveData from moko-mvvm-livedata). For properties that the UI should keep track of but should not change - use StateFlow. And to notify about the need to do something (show a success message or to go to another screen) we have created a Channel which is exposed on the UI as a Flow. All available actions we combine under a single sealed interface Action so that it is known exactly what actions can tell the given ViewModel.

git commit

Connect the common ViewModel to Android

On Android, to get our ViewModel from ViewModelStorage (so that when the screen rotates we received the same ViewModel) we need to include a special dependency in androidApp/build.gradle.kts:

dependencies {
    // ...
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.4.1")
}

Next, add LoginViewModel to our screen arguments:

@Composable
fun LoginScreen(
    viewModel: LoginViewModel = viewModel()
)

Let’s replace the local state of the screen with getting the state from the LoginViewModel:

val login: String by viewModel.login.collectAsState()
val password: String by viewModel.password.collectAsState()
val isLoading: Boolean by viewModel.isLoading.collectAsState()
val isLoginButtonEnabled: Boolean by viewModel.isButtonEnabled.collectAsState()

Subscribe to receive actions from the ViewModel using observeAsAction from moko-mvvm:

viewModel.actions.observeAsActions { action ->
    when (action) {
        LoginViewModel.Action.LoginSuccess ->
            Toast.makeText(context, "login success!", Toast.LENGTH_SHORT).show()
    }
}

Let’s change the input handler of TextFields from local state to writing to ViewModel:

TextField(
    // ...
    onValueChange = { viewModel.login.value = it }
)

And call the button click handler:

Button(
    // ...
    onClick = viewModel::onLoginPressed
) {
    // ...
}

We run the application and see that everything works exactly the same as it worked before the common code, but now all screen logic is controlled by a common ViewModel.

git commit

Connect the shared ViewModel to iOS

To connect LoginViewModel to SwiftUI, we need Swift add-ons from MOKO MVVM. They connect via CocoaPods:

pod 'mokoMvvmFlowSwiftUI', :podspec => 'https://raw.githubusercontent.com/icerockdev/moko-mvvm/release/0.13.0/mokoMvvmFlowSwiftUI.podspec'

And also, in the LoginViewModel itself, you need to make changes - from the side of Swift MutableStateFlow, StateFlow, Flow will lose their generic type since they are interfaces. So that the generic is not lost you need to use classes. MOKO MVVM provides special CMutableStateFlow, CStateFlow and CFlow classes to store the generic type in iOS. We bring the types with the following change:

class LoginViewModel : ViewModel() {
    val login: CMutableStateFlow<String> = MutableStateFlow("").cMutableStateFlow()
    val password: CMutableStateFlow<String> = MutableStateFlow("").cMutableStateFlow()

    // ...
    val isLoading: CStateFlow<Boolean> = _isLoading.cStateFlow()

    val isButtonEnabled: CStateFlow<Boolean> =
        // ...
        .cStateFlow()
    
    // ...
    val actions: CFlow<Action> get() = _actions.receiveAsFlow().cFlow()

    // ...
}

Now we can move on to the Swift code. To integrate, we make the following change:

import MultiPlatformLibrary
import mokoMvvmFlowSwiftUI
import Combine

struct LoginScreen: View {
    @ObservedObject var viewModel: LoginViewModel = LoginViewModel()
    @State private var isSuccessfulAlertShowed: Bool = false
    
    // ...
}

We add viewModel to View as @ObservedObject, just like we do with Swift versions ViewModel, but in this case, due to the use of mokoMvvmFlowSwiftUI we can immediately pass Kotlin class LoginViewModel.

Next, change the binding of the fields:

TextField("Login", text: viewModel.binding(\.login))
    .textFieldStyle(.roundedBorder)
    .disabled(viewModel.state(\.isLoading))

mokoMvvmFlowSwiftUI provides special extension functions to ViewModel:

• binding returns a Binding structure, for the possibility of changing data from the UI side
• state returns a value that will be automatically updated when StateFlow returns new data

Similarly, we replace other places where the local state is used and subscribe to actions:

.onReceive(createPublisher(viewModel.actions)) { action in
    let actionKs = LoginViewModelActionKs(action)
    switch(actionKs) {
    case .loginSuccess:
        isSuccessfulAlertShowed = true
        break
    }
}

The createPublisher function is also provided from mokoMvvmFlowSwiftUI and allows you to transform CFlow in AnyPublisher from Combine. For reliable processing actions we use moko-kswift. This is a gradle plugin that automatically generates swift code based on Kotlin. In this case, Swift was generated enum LoginViewModelActionKs from sealed interface LoginViewModel.Action. Using automatically generated enum we get a guarantee that the cases in enum and sealed interface match, so now we can rely on exhaustive switch logic. You can read more about MOKO KSwift in the article.

As a result, we got a SwiftUI screen that is controlled from a common code using the MVVM approach.

git commit

Conclusion

In development with Kotlin Multiplatform Mobile, we consider it important to strive to provide a convenient toolkit for both platforms — both Android and iOS developers should comfortably develop and the use of any approach in the common code should not force the developers of one of the platforms do extra work. By developing our MOKO libraries and tools, we strive to simplify the work of developers for both Android and iOS. SwiftUI and MOKO MVVM integration required a lot of experimentation, but the final result looks comfortable to use.

You can try the project created in this article yourself, on GitHub.

We can also help and development teams, who need development assistance or advice on the topic of Kotlin Multiplatform Mobile.

How to use Kotlin Multiplatform ViewModel in SwiftUI and Jetpack Compose was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin Multiplatform Mobile allows you to compile Kotlin code into native libraries for Android and iOS. If in the case of Android the library obtained from Kotlin will be integrated with an application written in Kotlin, then for iOS the integration will be with Swift. There is a loss of usability at the junction of Kotlin and Swift, due to the difference in languages. This is mainly because the Kotlin/Native compiler (which compiles Kotlin in the iOS framework and is part of the Kotlin Multiplatform) generates the public API of the framework in ObjectiveC. We access Kotlin from Swift through this generated ObjectiveC API, since Swift interacts with ObjectiveC. Further, I will show examples of API waste at the Kotlin-Swift junction and a tool that allows you to get a more convenient API for usage from Swift.

Let’s look at the example of using a sealed interface in Kotlin:

sealed interface UIState<out T> {
    object Loading : UIState<Nothing>
    object Empty : UIState<Nothing>
    data class Data<T>(val value: T) : UIState<T>
    data class Error(val throwable: Throwable) : UIState<Nothing>
}

This is a convenient construct to describe states, which is actively used in the Kotlin code. Let’s see how it looks from the Swift side.

public protocol UIState { }

public class UIStateLoading : KotlinBase, UIState { }

public class UIStateEmpty : KotlinBase, UIState { }

public class UIStateData<T> : KotlinBase, UIState where T : AnyObject {
    open var value: T? { get }
}

public class UIStateError : KotlinBase, UIState {
    open var throwable: KotlinThrowable { get }
}

From the Swift side Kotlin’s sealed interface looks like a set of classes with a common protocol. Of course, in this case, one cannot hope to check the completeness of the switch implementation, since it is not an enum. For developers familiar with Swift, the enum is considered a more correct analog of the sealed interface, for example:

enum UIState<T> {
  case loading
  case empty
  case data(T)
  case error(Error)
}

We can write such an enum from the Swift side and convert the resulting Kotlin UIState into our Swift enum, but what if there are many such sealed interfaces? The MVI approach is quite common in which the screen state and events are described exactly by the sealed class/interface. Writing an analogue in Swift for each such case is expensive. Moreover, we run the risk of class desynchronization in Kotlin and enum in Swift.

To solve this problem, we at IceRock made a special gradle plugin — MOKO KSwift. This is a gradle plugin that reads all the klibs used when compiling the iOS framework. Klib is the library format into which Kotlin/Native compiles everything before building the final binaries for a specific target. A lot of metadata is available inside klib, which gives complete information about the entire public Kotlin api, without loss of information. Our plugin analyzes all klibs that are specified in the export for the iOS framework (that is, those whose API will be included in the header of the framework), and, based on a complete understanding of the Kotlin code, it generates Swift code, in addition to the one Kotlin. For our UIState example, the plugin automatically generates the following construction:

public enum UIStateKs<T : AnyObject> {
  case loading
  case empty
  case data(UIStateData<T>)
  case error(UIStateError)

public init(_ obj: UIState) {
    if obj is MultiPlatformLibrary.UIStateLoading {
      self = .loading
    } else if obj is MultiPlatformLibrary.UIStateEmpty {
      self = .empty
    } else if let obj = obj as? MultiPlatformLibrary.UIStateData<T> {
      self = .data(obj)
    } else if let obj = obj as? MultiPlatformLibrary.UIStateError {
      self = .error(obj)
    } else {
      fatalError("UIStateKs not syncronized with UIState class")
    }
  }
}

We automatically get a swift enum that is guaranteed to match the sealed interface from Kotlin. This enum can be created by passing in the UIState object that we get from Kotlin. And this enum has access to classes from Kotlin to get all the information you need. Since this code is fully generated automatically at each compilation, we avoid the risks associated with the human factor — the machine cannot forget to update the code in Swift after changes occured in Kotlin.

Let’s move on to the next example. In MOKO mvvm (our port of Android architecture components with Android in Kotlin Multiplatform Mobile) to bind LiveData to UI elements, we have implemented a set of extension functions for iOS, for example:

fun UILabel.bindText(
    liveData: LiveData<String>
): Closeable

After compilation in the iOS framework, we were disappointed, because Kotlin/Native does not add extensions to platform classes:

public class UILabelBindingKt : KotlinBase {
    open class func bindText(_ receiver: UILabel, liveData: LiveData<NSString>) -> Closeable
}

In use, instead of the convenient API label.bindText(myLiveData), UILabelBindingKt.bindText(label, myLiveData) is required.

This problem can also be solved by MOKO KSwift, since it has complete knowledge of the entire public interface of Kotlin libraries. As a result, the following function is generated:

public extension UIKit.UILabel {
  public func bindText(liveData: LiveData<NSString>) -> Closeable {
    return UILabelBindingKt.bindText(self, liveData: liveData)
  }
}

Two generators are available currently out of the box in the KSwift plugin — SealedToSwiftEnumFeature (for generating Swift enum) and PlatformExtensionFunctionsFeature (for generating extensions to platform classes), however the plugin itself has an extensible API. You can implement the generation of the needed Swift code in addition to your Kotlin code without making changes directly to the plugin — only in your gradle project. By connecting the plugin as a dependency to buildSrc, you can write your own generator, for example:

import dev.icerock.moko.kswift.plugin.context.ClassContext
import dev.icerock.moko.kswift.plugin.feature.ProcessorContext
import dev.icerock.moko.kswift.plugin.feature.ProcessorFeature
import io.outfoxx.swiftpoet.DeclaredTypeName
import io.outfoxx.swiftpoet.ExtensionSpec
import io.outfoxx.swiftpoet.FileSpec

class MyKSwiftGenerator(filter: Filter<ClassContext>) : ProcessorFeature<ClassContext>(filter) {
    override fun doProcess(featureContext: ClassContext, processorContext: ProcessorContext) {
        val fileSpec: FileSpec.Builder = processorContext.fileSpecBuilder
        val frameworkName: String = processorContext.framework.baseName

val classSimpleName = featureContext.clazz.name.substringAfterLast('/')

fileSpec.addExtension(
            ExtensionSpec
                .builder(
                    DeclaredTypeName.typeName("$frameworkName.$classSimpleName")
                )
                .build()
        )
    }

class Config(
        var filter: Filter<ClassContext> = Filter.Exclude(emptySet())
    )

companion object : Factory<ClassContext, MyKSwiftGenerator, Config> {
        override fun create(block: Config.() -> Unit): MyKSwiftGenerator {
            val config = Config().apply(block)
            return MyKSwiftGenerator(config.filter)
        }
    }
}

In the above example, we include the analysis of Kotlin classes (ClassContext) and generate an extension in Swift for each of the Kotlin classes.
In the Context classes, all the information from the klib metadata is available, and metadata contains all the information about classes, methods, packages, etc. To the same extent as compiler plugins, but read-only (while compiler plugins allow changing the code at compile time).

The plugin is a quite new solution for now and may not work correctly in some cases, which should definitely be reported in the issue at GitHub.

To preserve the ability to use the plugin and in cases where incorrect code is generated, the ability to filter the entities that used to generation has been added. For example, to exclude the class UIState from generation, you need to write in gradle:

kswift {
    install(dev.icerock.moko.kswift.plugin.feature.SealedToSwiftEnumFeature) {
        filter = excludeFilter("ClassContext/moko-kswift.sample:mpp-library-pods/com/icerockdev/library/UIState")
    }
}

Filtering by processed libraries and the ability to enable the includeFilter mode (so that generation occurs only for specified entities) is also available.

If you are using Kotlin Multiplatform Mobile technology, I recommend that you try the plugin on your project (and give feedback on github) — the work of iOS developers will become better when they get a Swift-friendly API for working with the Kotlin module. And, if possible, share your generator options also on github — the more API improvements the plugin supports out of the box, the easier it will be for everyone.

Special thanks to Svyatoslav Scherbina from JetBrains for a tip about using klib metadata.

How to implement Swift-friendly API with Kotlin Multiplatform Mobile was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, guys, it’s IceRock team. So great to get feedback from customers. This time guys from Profi.ru wrote an article. Hope their experience will be useful and inspiring for you.

Hello! My name is Mikhail Ignatov, and I am a team lead at Profi. My team is responsible for client-side mobile apps for Android and iOS. We have been using Kotlin Multiplatform in production since 2019. Let me tell you about why we chose this particular technology, how we integrated it, the key stages that we went through during the process, and the conclusions we reached in the end.

Kotlin Multiplatform

Kotlin Multiplatform allows users to run the same Kotlin code on multiple platforms. In August of 2020, JetBrains introduced Kotlin Multiplatform Mobile (KMM), an SDK that facilitates the use of shared code across Android and iOS. The purpose of the technology is to extract business logic while the UI layer remains native, which is good for a better user experience and the look and feel of the apps.

Why We Chose Kotlin Multiplatform

We studied various cross-platform technologies. For example, React Native and Flutter allow to program and develop a feature for both platforms at the same time, but they narrow the choice of programming language and libraries. We chose Kotlin Multiplatform for three reasons.

Ease of integration

The common code written in Kotlin can be injected with minimal effort into a finished application. It then compiles into platform-familiar libraries. In the case of Android, it is a jar or aar library, while for iOS, it is a Universal Framework. The connection process and further work does not differ from interacting with any native library.

The Kotlin language’s syntax is close to Swift

The similarity of the language lowers the entry barrier for iOS developers. Both languages ​​share a similar ideology focused on development speed and usability. Anyone on the team can understand what is going on in the common code and adjust it if needed.

Developer Resource Waste Minimization

The business logic of our applications is the same. More than 70% of the code is not related to the platform it runs on. We request data from the server, transform it, cache it, and prepare it for display. Without code sharing, we would have to write the same code in Kotlin for Android and in Swift for iOS. There are differences only in the design side due to the difference in the UX on mobile platforms and the interaction with the system in terms of requests to various peripherals like cameras, geolocation, galleries, notifications, and so on.

The Implementation Process

We decided to act thoughtfully and methodically. We started by tackling simple problems, gradually increasing the complexity. We reflected on every stage, assessing the costs, the results and the consequences. Here is a description of the three main steps we have taken.

Step 1. The first line in the shared code

The first task is to make common API request strings to avoid differences in the requested data structures on the two platforms.

Data exchange with the server was implemented via GraphQL. The code request consisted of a multiline string made up of five lines, sometimes under a hundred. When sending such a volume of code, the backend will have to spend time parsing the structure. On the other hand, there is a need to control the requested data during the code review process and the validation of production requests. Therefore, we “train” the server for new requests before release. This allows hashes to be used instead of strings.

Previously, we did the “training” of the server manually and separately for each platform. This took up a lot of resources and increased the likelihood of errors. For example, it is easy to forget to “train” a request on one of the platforms and corrupt the application as a result.

We decided to move several requests into a shared code. A multiplatform shared module was developed for the purpose in the Android project. We moved the query strings into it and wrapped the object in singleton classes, and then called the methods of these classes in client applications. Fun fact — an iOS developer suggested using KMM.

The first line in the shared code

package ru.profi.shared.queries.client.city  

/** 
* City search query by [Params.term]
*/
object GeoSelectorWarpQuery : WarpQuery<Params> {

     override val hash: String? = "\$GQLID{c9d4adbb7b9ef49fc044064b9a3e662b}"

     override val dirtyQuery = listOf("\$term").let { (term) ->
        """
        query geoSelector($term: String) {
          suggestions: simpleGeoSelector(term: $term, first: 100) {
            edges {
              node {
                name
                geoCityId
                regionName
                hostname
                countryId
              }
            }
          }
        }
        """
    }.trimIndent()
 }

Application in an Android project

override fun getQuery() = GeoSelectorWarpQuery.getQuery()

Application in an iOS project

import KotlinComponents

struct GraphQLWarpRequests {
      static let GeoSelectorWarpQuery = GeoSelectorWarpQuery()
          ...
}

let model = GraphQLRequestModel(query: GraphQLWarpRequests.GeoSelectorWarpQuery.getQuery(), variables: variables)

The query structures were relocated into a single repository. In the next release, the shared library was connected on both platforms and the system started operating smoothly. The app size on iOS was increased by only 0.8 MB. As a result, the transfer of requests into the shared code halved the number of approaches needed for the “training”.

The manual learning problem was solved with a utilitarian library consisting of several classes written in Kotlin. It finds untrained requests in the code, generates and then sends new hashes via a pull request to the backend repository. This allows us to avoid wasting time on training, as it is fully automated.

In this step, we built a framework for the shared code on Kotlin Multiplatform, allowing us to move on to more important tasks.

Step 2. Creating a multiplatform SDK

At one point, the company decided to create its own in-house analytics tool based on Clickhouse. An API for applications was created for this purpose on the backend side. All my team had to do was send events. In order not to interfere with the work of the main functionality and avoid losing events if the user did not have a network, it was necessary to learn how to cache, group batches of events, and send them with a lower priority than requests for the main functionality.

We decided to write the module in the shared code. We selected the Ktor network client for this purpose, as it suited us perfectly.

When a network is lacking, the events must be saved until the next communication session. We chose SQLDelight for the purpose — a multiplatform library for a native database.

For asynchronous operations, we used kotlinx.coroutines and kotlinx.serialization for the serialization and deserialization processes.

To increase the reliability of the code, the functionality of the module was ensured with unit tests, since they can be run on different platforms with ease.

There were no problems with integrating the application on Android, but there were crashes at the start on iOS. The stack trace did not get us very close to our goal on the Xcode console and Firebase Crashlytics logs. But the failing element inside the shared code was evident to us.

To get a stack trace, we included the CrashKiOS library from the Touchlab studio. When creating the coroutines, we added the CoroutineExceptionHandler, which identifies exceptions during their execution.

It turned out that the event was dispatched after the coroutine’s scope was canceled. And this was the reason for the failures. It turned out that we had incorrectly canceled CoroutineScope in the application lifecycle.

Kotlin Multiplatform made it possible to combine the responsibility for sending and storing analytical events into a single module. As a result, we built a full-fledged SDK in a shared code.

Step 3. Transfer of the business logic from the Android application to the multiplatform

I am certain that many projects have code that they want to bypass, since it is difficult to read, regularly causes subtle problems with the product, and was written so long ago that its authors are no longer with the company.

The iOS app had this code in the chat business logic module. This was our pain point, as it became more expensive to add new functionality, since the code was written in Objective-C with an outdated and complex architecture. We felt that the developers were reluctant to take on chat tasks.

In an Android application, the chat business logic has recently been rewritten to Kotlin. Therefore, we decided to try to move the existing module into the shared code and adapt it to iOS.

The developers from IceRock helped us a lot. They have long embarked on the path of multiplatform operations, promoting KMM and developing the community. And together, we drew up a plan.

Configure Kotlin Multiplatform support in the gradle module.

Create a module, connect plugins, configure the sourceSets and dependencies.

Move platform independent classes to commonMain.

Move all the elements of JVM and Android independent to commonMain. This is a repository for common code that has no platform dependencies.

Replace JVM / Android libraries with their multiplatform counterparts.

Move from org.json to kotlinx.serialization and from JodaTime to klock. Some parts had to be moved into the platform-dependent code in the form of expect/actual.

Move the JVM-dependent code that requires changes to commonMain.

For example, replace JVM IOException with kotlin.Exception and ConcurrentHashMap with Stately.

Move the Android dependent code that requires changes to commonMain.

The only Android SDK dependency was the Service component, which works with WebSocket, since there is no stable multiplatform analogue on Kotlin yet.

We decided to leave the native implementations in the application and connect them through the SocketService interface.

The SocketService interface

interface SocketService {

      /**
      * Connect on a socket to [chatUrl]. All events from the socket must be sent to [callback]
      */
     fun connect(chatUrl: String, callback: (SocketEvent) -> Unit)

      /**
      * Disconnect from the current socket connection
      */
     fun disconnect()

      /**
      * Send message [msg] on current socket connection
      */
     fun send(msg: String)
 }

Making the API module usable for both platforms.

Since it is impossible to detect runtime exceptions from Kotlin on iOS, we decided to handle them inside the SDK and add callback onError to the interface methods. We had to slightly redesign the interface for interacting with client applications.

When transferring the code to the multiplatform, we formulated an algorithm for migrating the modules with the business logic into a shared code. We use it to extract other modules.

IceRock.dev’s plan helped us a lot with moving faster and with greater confidence. We will surely continue to contact them as needed and share our development experience.

What We Can Conclude

Kotlin Multiplatform helped create a single source of business logic in Profi client applications. The UI and UX were left native for the user. With the right design of the interface for interacting with shared code, the change and extension of business logic takes place from a single source, and client applications just need to support this approach.

We reduced waste of resources. When migrating modules to Kotlin Multiplatform, we noticed how much development time was saved, as the chat module on iOS did not have to be refactored. Instead, we moved the solution from the Android project into the shared code and adapted it for iOS. It costs less than writing chats from scratch.

The developers quickly got used to the process. The only new elements for Android developers were the multiplatform libraries and module build-script customization. The rest was familiar territory. It was easy for iOS developers to understand the syntax of the language, but they had to dig into the assembly using Gradle. And now, each of them has already solved at least one problem in the shared code.

The main disadvantage of the technology is the build time for iOS. For example, when we were looking for the reason for the application’s crash, we often had to rebuild the shared code for iOS. This is barely noticable when publishing shared modules. With the release of new versions of Kotlin, the build speed increases, we hope that future development cycles will be more convenient.

We did encounter some problems as a result of our ignorance. When we started on the project, there was very little information on the implementation of KMM, so we had to solve all of the issues ourselves. The Kotlin Multiplatform community is growing rapidly with more articles and reports appearing at conferences and meetups. There are channels in Slack, libraries for Kotlin Multiplatform, and so on, plenty of information sources available.

It Was Worth It In The End

The first steps were difficult, because the technology was new. At first, it seemed easier to use native solutions on libraries known to the team than to understand new ones. But we understood that things would unravel faster later on. And we were right. We can say that the speed of development using shared code and native projects is fairly equal.

We already have 10 common modules of varying complexity, and we are continuing to migrate the business logic into a shared code. I am sure that Kotlin Multiplatform Mobile is ready to conquer the world of mobile application development.

Read more about KMM in our blog.

How We integrated Kotlin Multiplatform Into Profi was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.