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.

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.

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.

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.

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.

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.

1. Intro

This manual is the second part in GiphyApp series, before you start we would recommend to do GiphyApp #1.

The result of this lession is available on github.

2. Implement common logic of Gif list in shared library

App should get list of Gifs from GIPHY service. There is an example with getting list of news from newsapi in the project template (using moko-network with generating network entites and API classes from OpenAPI specification).

We can get OpenAPI spec of GIPHY from apis.guru and can replace getting news by getting Gif.

Feature List is already in the project template and you have not to implement any additional logic. You can see scheme of module and look into mpp-library:feature:list for detail information about it.

Replace OpenAPI spec

Replace file mpp-library/domain/src/openapi.yml by the content from OpenAPI spec of GIPHY service. After it please do Gradle Sync and as the result you will see some errors in the newsapi code. Let's update code by new API.

You can find generated files here mpp-library/domain/build/generate-resources/main/src/main/kotlin

Replace news by gifs in domain module

You have to update the following classes after replacing OpenAPI spec in domain module:

• News should be replaced by Gif;
• NewsRepository – should be replaced by GifRepository;
• DomainFactory – add gifRepository and set necessary dependencies.

News -> Gif

Let’s modify News class to the following one:

@Parcelize
data class Gif(
    val id: Int,
    val previewUrl: String,
    val sourceUrl: String
) : Parcelable

This domain entity contains gif’s id and two URL (full and preview variant). id is used for correct identifying element in a list and in UI animations.

Let’s transform network entity dev.icerock.moko.network.generated.models.Gif to domain entity. To do this add one more construct method:

@Parcelize
data class Gif(
    ...
) : Parcelable {

    internal constructor(entity: dev.icerock.moko.network.generated.models.Gif) : this(
        id = entity.url.hashCode(),
        previewUrl = requireNotNull(entity.images?.downsizedMedium?.url) { "api can't respond without preview image" },
        gifUrl = requireNotNull(entity.images?.original?.url) { "api can't respond without original image" }
    )
}

Above there is a field mapping from network entity to domain entity — it will reduce the number of edits if API has been changed. The application doesn’t depend on API implementation.

NewsRepository -> GifRepository

Let’s change NewsRepository to GifRepository with the following content:

class GifRepository internal constructor(
    private val gifsApi: GifsApi
) {
    suspend fun getGifList(query: String): List<Gif> {
        return gifsApi.searchGifs(
            q = query,
            limit = null,
            offset = null,
            rating = null,
            lang = null
        ).data?.map { Gif(entity = it) }.orEmpty()
    }
}

In this class you have to get GifsApi object (generated by moko-network) and call a method API searchGifs, where we use just query string, but other arguments are by default.

Network entities we have to modify in domain entities, what can be public (network entites generated with internalmodifier only).

DomainFactory

In DomainFactory we have to replace creation newsApi and newsRepository by the following code:

private val gifsApi: GifsApi by lazy {
    GifsApi(
        basePath = baseUrl,
        httpClient = httpClient,
        json = json
    )
}

val gifRepository: GifRepository by lazy {
    GifRepository(
        gifsApi = gifsApi
    )
}

GifsApi - it's a generated class, for creation you need a several parameters:

• baseUrl – server url, it will come from factory of native layer. It needed for set up different envoiroment configuration.
• httpClient - http client object for work with server (from ktor-client)
• json - JSON serialization object (from kotlinx.serialization)

GifRepository is available outside of module, you can create it using gifsApi object only.

There is a lazy initialization – API and repository are Singleton objects (objects are alive while the factory is alive and the factory is created SharedFactory exists during life cycle of an application).

Also we need to send Api Key for work with GIPHY API. To do this we can use TokenFeature for ktor. It was already connected, we just have to configure it:

install(TokenFeature) {
    tokenHeaderName = "api_key"
    tokenProvider = object : TokenFeature.TokenProvider {
        override fun getToken(): String? = "o5tAxORWRXRxxgIvRthxWnsjEbA3vkjV"
    }
}

Every query comes throught httpClient will be append by header api_key: o5tAxORWRXRxxgIvRthxWnsjEbA3vkjV in this case (this is a sample app key, you can create a your one in GIPHY admin area if you are exceed the limit).

Update connection between domain and feature:list from SharedFactory

In SharedFactory we have to change interface of units list factory, NewsUnitsFactory, and replace singleton newsFactory by gifsFactory with Gif configuration.

NewsUnitsFactory -> GifsUnitsFactory

Interface of units list factory should be replaced by:

interface GifsUnitsFactory {
    fun createGifTile(
        id: Long,
        gifUrl: String
    ): UnitItem
}

So, there will be id (for proper diff list calculation for UI animation ) and gifUrl (this is url for animation output) from shared code.

newsFactory -> gifsFactory

List Factory should be replaced by the following code:

val gifsFactory: ListFactory<Gif> = ListFactory(
    listSource = object : ListSource<Gif> {
        override suspend fun getList(): List<Gif> {
            return domainFactory.gifRepository.getGifList("test")
        }
    },
    strings = object : ListViewModel.Strings {
        override val unknownError: StringResource = MR.strings.unknown_error
    },
    unitsFactory = object : ListViewModel.UnitsFactory<Gif> {
        override fun createTile(data: Gif): UnitItem {
            return gifsUnitsFactory.createGifTile(
                id = data.id.toLong(),
                gifUrl = data.previewUrl
            )
        }
    }
)

In code above there is a data source listSource and we call gifRepository from domain module there. Temporary query is set up as test value, but we will change it in next lessons.
Also there is a parameter strings, localization strings, will be implemented in feature:list module (this module requires only one string "unknown error").
The last required parameter is unitsFactory, but the module works with 1 method factory, createTile(data: Gif), and for native platforms it will be better to use a specific list factory (so every UI-related field was defined from common code). That's why we use gifsUnitsFactory.createGifTile.

The last thing to do — replace SharedLibrary constructor by the following code:

class SharedFactory(
    settings: Settings,
    antilog: Antilog,
    baseUrl: String,
    gifsUnitsFactory: GifsUnitsFactory
)

So native platforms will return GifsUnitsFactory object.

3. Implement Gif list on Android

Set server URL

There is a working server URL will be passed from application layer to the common code library so we avoid rebuilding when server url had changed.

In our current configuration there is only one environment and only one server url. It set up in android-app/build.gradle.kts, let's replace it:

android {
    ...
    defaultConfig {
        ...

        val url = "https://api.giphy.com/v1/"
        buildConfigField("String", "BASE_URL", "\"$url\"")
    }
}

Dependencies Injection

We have to use glide library for gif rendering and we use constraintLayout library for setting aspect ratio 2:1 of list’s unit.

constraintLayout is already declared in project dependencies and we just need to include it on android-app, let's add it in android-app/build.gradle.kts:

dependencies {
    ...
    implementation(Deps.Libs.Android.constraintLayout.name)
}

A glide has to be appended in dependencies injection script in buildSrc/src/main/kotlin/Versions.kt:

object Versions {
    ...
    object Libs {
        ...
        object Android {
            ...
            const val glide = "4.10.0"
        }
    }
}

And in buildSrc/src/main/kotlin/Deps.kt:

object Deps {
    ...
    object Libs {
        ...
        object Android {
            ...
            val glide = AndroidLibrary(
                name = "com.github.bumptech.glide:glide:${Versions.Libs.Android.glide}"
            )
        }

After this we can add in android-app/build.gradle.kts the following code:

dependencies {
    ...
    implementation(Deps.Libs.Android.glide.name)
}

SharedFactory Initialization

To create SharedFactory you have to replace newsUnitsFactory by gifsUnitsFactory. To create this dependency let's modify NewsUnitsFactory class to the following:

class GifListUnitsFactory : SharedFactory.GifsUnitsFactory {
    override fun createGifTile(id: Long, gifUrl: String): UnitItem {
        TODO()
    }
}

And we should use it in SharedFactory:

AppComponent.factory = SharedFactory(
    baseUrl = BuildConfig.BASE_URL,
    settings = AndroidSettings(getSharedPreferences("app", Context.MODE_PRIVATE)),
    antilog = DebugAntilog(),
    gifsUnitsFactory = GifListUnitsFactory()
)

GifListUnitsFactory Implementation

SharedFactory.GifsUnitsFactory interface requires to create UnitItem from id and gifUrl variables. UnitItem is a part of moko-units and you can generate implementation from a DataBinding layout.

Let’s create android-app/src/main/res/layout/tile_gif.xml with the following content:

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools">

    <data>

        <variable
            name="gifUrl"
            type="String" />
    </data>

    <androidx.constraintlayout.widget.ConstraintLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:padding="8dp">

        <ImageView
            android:layout_width="match_parent"
            android:layout_height="0dp"
            app:gifUrl="@{gifUrl}"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintDimensionRatio="2:1"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            tools:ignore="ContentDescription" />
    </androidx.constraintlayout.widget.ConstraintLayout>
</layout>

And run Gradle Sync after this – TileGif class will be generated automatically and we will use it in GifListUnitsFactory class.

class GifListUnitsFactory : SharedFactory.GifsUnitsFactory {
    override fun createGifTile(id: Long, gifUrl: String): UnitItem {
        return TileGif().apply {
            itemId = id
            this.gifUrl = gifUrl
        }
    }
}

In the layout we use non-standart Binding Adapter — app:gifUrl. We should implement it. To do this let's create android-app/src/main/java/org/example/app/BindingAdapters.kt file with the following code:

package org.example.app

import android.widget.ImageView
import androidx.databinding.BindingAdapter
import androidx.swiperefreshlayout.widget.CircularProgressDrawable
import com.bumptech.glide.Glide

@BindingAdapter("gifUrl")
fun ImageView.bindGif(gifUrl: String?) {
    if (gifUrl == null) {
        this.setImageDrawable(null)
        return
    }

    val circularProgressDrawable = CircularProgressDrawable(context).apply {
        strokeWidth = 5f
        centerRadius = 30f
        start()
    }

    Glide.with(this)
        .load(gifUrl)
        .placeholder(circularProgressDrawable)
        .error(android.R.drawable.stat_notify_error)
        .into(this)
}

This allows us to set gifUrl for ImageView from layout. Moreover on loading there will be progress bar and on error it will be error icon.

Create a Gif list screen

All that’s left to do a screen showing data from our common code.
Create android-app/src/main/res/layout/activity_gif_list.xml with the content:

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <data>
        <import type="org.example.library.domain.entity.Gif"/>
        <import type="org.example.library.feature.list.presentation.ListViewModel" />

        <variable
            name="viewModel"
            type="ListViewModel&lt;Gif&gt;" />
    </data>

    <FrameLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent">

        <androidx.swiperefreshlayout.widget.SwipeRefreshLayout
            android:id="@+id/refresh_layout"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            app:visibleOrGone="@{viewModel.state.ld.isSuccess}">

            <androidx.recyclerview.widget.RecyclerView
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                app:adapter="@{`dev.icerock.moko.units.adapter.UnitsRecyclerViewAdapter`}"
                app:bindValue="@{viewModel.state.ld.dataValue}"
                app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager" />

        </androidx.swiperefreshlayout.widget.SwipeRefreshLayout>

        <ProgressBar
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            app:visibleOrGone="@{viewModel.state.ld.isLoading}" />

        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:gravity="center"
            android:text="@string/no_data"
            app:visibleOrGone="@{viewModel.state.ld.isEmpty}" />

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:padding="16dp"
            android:orientation="vertical"
            app:visibleOrGone="@{viewModel.state.ld.isError}">

            <TextView
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:gravity="center"
                android:text="@{viewModel.state.ld.errorValue}" />

            <Button
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:layout_gravity="center_horizontal"
                android:onClick="@{() -> viewModel.onRetryPressed()}"
                android:text="@string/retry_btn" />
        </LinearLayout>
    </FrameLayout>
</layout>

Layout uses Data Binding and show 1 of the 4 states got from ListViewModel. There is SwipeRefreshLayoutwith RecyclerView inside in data state, and RecyclerView uses LinearLayoutManager and UnitsRecyclerViewAdapter for rendering UnitItem objectes that got from UnitsFactory.

Let’s create android-app/src/main/java/org/example/app/view/GifListActivity.kt with the content:

class GifListActivity : MvvmActivity<ActivityGifListBinding, ListViewModel<Gif>>() {
    override val layoutId: Int = R.layout.activity_gif_list
    override val viewModelClass = ListViewModel::class.java as Class<ListViewModel<Gif>>
    override val viewModelVariableId: Int = BR.viewModel

    override fun viewModelFactory(): ViewModelProvider.Factory = createViewModelFactory {
        AppComponent.factory.gifsFactory.createListViewModel()
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        with(binding.refreshLayout) {
            setOnRefreshListener {
                viewModel.onRefresh { isRefreshing = false }
            }
        }
    }
}

We’ve got ListViewModel<Gif> from gifsFactory factory and it will be inserted in viewModel field from activity_gif_list layout.

Also we define setOnRefreshListener in code for proper execution SwipeRefreshLayout and call viewModel.onRefresh that report in lambda when update will be finished and we can turn off the updating animation.

Replace a startup screen

Let’s set up GifListActivity as a launch screen. To do it let's add GifListActivity in android-app/src/main/AndroidManifest.xml file and remove others (we don't need it any more).

<application ...>

    <activity android:name=".view.GifListActivity" >
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
</application>

Remove unnecessary classes

Now we can delete all unnnecessary files from project template:

• android-app/src/main/java/org/example/app/view/ConfigActivity.kt
• android-app/src/main/java/org/example/app/view/NewsActivity.kt
• android-app/src/main/res/layout/activity_news.xml
• android-app/src/main/res/layout/tile_news.xml

Run

You can run the application on Android and see list of Gifs.

4. Implement Gif list on iOS

Set server URL

As well as on Android, a working server URL will be passed from application layer to the common code library so we avoid rebuilding common library when server url had changed.
This setting can be set in ios-app/src/AppDelegate.swift file:

AppComponent.factory = SharedFactory(
    ...
    baseUrl: "https://api.giphy.com/v1/",
    ...
)

Dependencies Injections

We have to use SwiftyGif for showing gif files. To include it we have to inject ios-app/Podfile dependency:

target 'ios-app' do
  ...
  pod 'SwiftyGif', '5.1.1'
end

and after this we can run a pod install command in ios-app directory.

SharedFactory Initialization

We have to use gifsUnitsFactory instead of newsUnitsFactory to create SharedFactory. To do this let's modify NewsUnitsFactory class in following code:

class GifsListUnitsFactory: SharedFactoryGifsUnitsFactory {
    func createGifTile(id: Int64, gifUrl: String) -> UnitItem {
        // TODO
    }
}

And will pass it in SharedFactory:

AppComponent.factory = SharedFactory(
    settings: AppleSettings(delegate: UserDefaults.standard),
    antilog: DebugAntilog(defaultTag: "MPP"),
    baseUrl: "https://api.giphy.com/v1/",
    gifsUnitsFactory: GifsListUnitsFactory()
)

GifListUnitsFactory implementation

SharedFactory.GifsUnitsFactory interface requires to create UnitItem from id and gifUrl variables. UnitItem is a part of moko-units and implementation requires to create xib with cell interface and specific cell class.

Create ios-app/src/units/GifTableViewCell.swift with the content:

import MultiPlatformLibraryUnits
import SwiftyGif

class GifTableViewCell: UITableViewCell, Fillable {
    typealias DataType = CellModel
    
    struct CellModel {
        let id: Int64
        let gifUrl: String
    }
    
    @IBOutlet private var gifImageView: UIImageView!
    
    private var gifDownloadTask: URLSessionDataTask?
    
    override func prepareForReuse() {
        super.prepareForReuse()
        
        gifDownloadTask?.cancel()
        gifImageView.clear()
    }
    
    func fill(_ data: GifTableViewCell.CellModel) {
        gifDownloadTask = gifImageView.setGifFromURL(URL(string: data.gifUrl)!)
    }
    
    func update(_ data: GifTableViewCell.CellModel) {
        
    }
}

extension GifTableViewCell: Reusable {
    static func reusableIdentifier() -> String {
        return "GifTableViewCell"
    }
    
    static func xibName() -> String {
        return "GifTableViewCell"
    }
    
    static func bundle() -> Bundle {
        return Bundle.main
    }
}

Then create ios-app/src/units/GifTableViewCell.xib with a cell layout.

The result looks like this:

We have to set GifTableViewCell class in UITableViewCell cell:

And set an identifier for reuse:

Now we can implement UnitItem creation in GifListUnitsFactory:

class GifsListUnitsFactory: SharedFactoryGifsUnitsFactory {
    func createGifTile(id: Int64, gifUrl: String) -> UnitItem {
        return UITableViewCellUnit<GifTableViewCell>(
            data: GifTableViewCell.CellModel(
                id: id,
                gifUrl: gifUrl
            ),
            configurator: nil
        )
    }
}

Create a Gif list screen

All that’s left to do a screen showing data from our common code.

Create ios-app/src/view/GifListViewController.swift with the content:

import MultiPlatformLibraryMvvm
import MultiPlatformLibraryUnits

class GifListViewController: UIViewController {
    @IBOutlet private var tableView: UITableView!
    @IBOutlet private var activityIndicator: UIActivityIndicatorView!
    @IBOutlet private var emptyView: UIView!
    @IBOutlet private var errorView: UIView!
    @IBOutlet private var errorLabel: UILabel!
    
    private var viewModel: ListViewModel<Gif>!
    private var dataSource: FlatUnitTableViewDataSource!
    private var refreshControl: UIRefreshControl!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        viewModel = AppComponent.factory.gifsFactory.createListViewModel()

        // binding methods from https://github.com/icerockdev/moko-mvvm
        activityIndicator.bindVisibility(liveData: viewModel.state.isLoadingState())
        tableView.bindVisibility(liveData: viewModel.state.isSuccessState())
        emptyView.bindVisibility(liveData: viewModel.state.isEmptyState())
        errorView.bindVisibility(liveData: viewModel.state.isErrorState())

        // in/out generics of Kotlin removed in swift, so we should map to valid class
        let errorText: LiveData<StringDesc> = viewModel.state.error().map { $0 as? StringDesc } as! LiveData<StringDesc>
        errorLabel.bindText(liveData: errorText)

        // datasource from https://github.com/icerockdev/moko-units
        dataSource = FlatUnitTableViewDataSource()
        dataSource.setup(for: tableView)

        // manual bind to livedata, see https://github.com/icerockdev/moko-mvvm
        viewModel.state.data().addObserver { [weak self] itemsObject in
            guard let items = itemsObject as? [UITableViewCellUnitProtocol] else { return }
            
            self?.dataSource.units = items
            self?.tableView.reloadData()
        }
        
        refreshControl = UIRefreshControl()
        tableView.refreshControl = refreshControl
        refreshControl.addTarget(self, action: #selector(onRefresh), for: .valueChanged)
    }
    
    @IBAction func onRetryPressed() {
        viewModel.onRetryPressed()
    }
    
    @objc func onRefresh() {
        viewModel.onRefresh { [weak self] in
            self?.refreshControl.endRefreshing()
        }
    }
}

And let’s bind NewsViewController to GifListViewController in MainStoryboard:

Replace a startup screen

To launch the application from gif screen we have to link rootViewController with GifListViewController in Navigation Controller:

Remove unnecessary files

Now we can delete all unnnecessary files from project:

• ios-app/src/units/NewsTableViewCell.swift
• ios-app/src/units/NewsTableViewCell.xib
• ios-app/src/view/ConfigViewController.swift
• ios-app/src/view/NewsViewController.swift

Run

Now you can run the application on iOS and see a list of Gif.

Read more about KMM in our blog.

Creating a simple Kotlin Multiplatform project based on moko-template — part 2 was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this lesson we will cover developing small application for iOS and Android using Kotlin Multiplatform based on moko-template.

Tools

We will need:

• Android Studio 3.4.0+ (do not use 3.5.1 version, cause there is a bug is breaking MPP project);
• Xcode 10.3+;
• Xcode Command Line Tools (xcode-select --install);
• CocoaPods (sudo gem install cocoapods);
• JDK — требуется для запуска gradle из Xcode build phase.

The Result

As the result of GiphyApp lessons you will get an application to view gif files using GIPHY API.
UI of this application will be completely native, player of gif files will make using native libraries glide for Android and SwiftyGif for iOS.

2. Create the project based on moko-template

For creation we will use project template from moko-template.

The project template already has preconfigured builds of iOS and Andoroid application with shared library and you will save the time to integrate shared library to iOS project on iOS platform, to configure Kotlin Multiplatform modules and dependencies (using mobile-multiplatform-gradle-plugin you can make configuraion is simplier).
The project template has a sample of several features as well as.

Use this template

To use this template you have to go on GitHub репозиторий шаблона moko-template and press a green button Use this template. As the result, you create a new repository according to the last commit of master branch of moko-template project.

After succefull creation you should clone this rep: git clone <git url of repo>.

3. Test build

To be sure that start state is correct, will run the both applications. To do this:

• on Android: open root repository directory in Android Studio, wait while Gradle Sync will finish, and run android-app as regular application.
• on iOS: install project’s CocoaPods (in directory ios-app run a command pod install, and after this open ios-app/ios-app.xcworkspace in Xcode and press Run for running application.

Building of Kotlin/Native can take a time (it will start automatically on doing pod install as well as building iOS project).

4. Setting up an application identifiers

You can set an appllication identifiers like you do in regular Android and iOS application:

Change Appliсation Id

Android - in file android-app/build.gradle.kts need to change:

android {
    ...

    defaultConfig {
        ...
        
        applicationId = "dev.icerock.codelab.giphy"
        ...
    }
}

iOS - you have to set Bundle Identifier in the project's setting in Xcode like on the screenshot below:

Change an application name

Android - in file android-app/src/main/res/values/strings.xml change:

<resources>
    <string name="app_name">Giphy App</string>
    ...
</resources>

iOS - you have to set Display name in the project's setting in Xcode like on the screenshot below:

Change an application icon

You can download the icon's resources here.

To change Android icons you have to move content of android directory of this archive in android-app/src/main/res directory. After this, you need to set this icon on android-app/src/main/AndroidManifest.xml:

<manifest>
    <application
        ...
        android:icon="@mipmap/ic_launcher">
        ...
    </application>
</manifest>

To change icons on iOS you have to replace ios-app/src/Assets.xcassets/AppIcon.appiconset directory by the archive's version.

Change launch screen

There is a launch screen on iOS and to replace it you have to modify ios-app/src/Resources/LaunchScreen.storyboard file. For example, let's just change a text like on screenshot:

5. Next steps

On the next lesson GiphyApp #2 we will create a Gif list.

Read more about KMM in our blog.

Creating a simple Kotlin Multiplatform project based on moko-template was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Set up Kotlin Multiplatform Project

We are going to turn two standard projects (Android and iOS) into a multiplatform project with a shared library on Kotlin Multiplatform.

We will need:

• Android Studio 3.4.0+ (do not use 3.5.1 version, cause there is a bug is breaking MPP project);
• Xcode 10.3+;
• Xcode Command Line Tools (xcode-select --install);
• CocoaPods (sudo gem install cocoapods).

To start, we’ll need an Android project created from an Android Studio template and an iOS project created from an Xcode template. Put both projects in the same directory:

├── android-app
│   ├── build.gradle
│   ├── proguard-rules.pro
│   └── src
│       ├── androidTest
│       │   └── java
│       │       └── com
│       │           └── icerockdev
│       │               └── android_app
│       │                   └── ExampleInstrumentedTest.kt
│       ├── main
│       │   ├── AndroidManifest.xml
│       │   ├── java
│       │   │   └── com
│       │   │       └── icerockdev
│       │   │           └── android_app
│       │   │               └── MainActivity.kt
│       │   └── res
│       │       ├── drawable
│       │       │   └── ic_launcher_background.xml
│       │       ├── drawable-v24
│       │       │   └── ic_launcher_foreground.xml
│       │       ├── layout
│       │       │   └── activity_main.xml
│       │       ├── mipmap-anydpi-v26
│       │       │   ├── ic_launcher.xml
│       │       │   └── ic_launcher_round.xml
│       │       ├── mipmap-hdpi
│       │       │   ├── ic_launcher.png
│       │       │   └── ic_launcher_round.png
│       │       ├── mipmap-mdpi
│       │       │   ├── ic_launcher.png
│       │       │   └── ic_launcher_round.png
│       │       ├── mipmap-xhdpi
│       │       │   ├── ic_launcher.png
│       │       │   └── ic_launcher_round.png
│       │       ├── mipmap-xxhdpi
│       │       │   ├── ic_launcher.png
│       │       │   └── ic_launcher_round.png
│       │       ├── mipmap-xxxhdpi
│       │       │   ├── ic_launcher.png
│       │       │   └── ic_launcher_round.png
│       │       └── values
│       │           ├── colors.xml
│       │           ├── strings.xml
│       │           └── styles.xml
│       └── test
│           └── java
│               └── com
│                   └── icerockdev
│                       └── android_app
│                           └── ExampleUnitTest.kt
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
├── gradlew.bat
├── ios-app
│   ├── ios-app
│   │   ├── AppDelegate.swift
│   │   ├── Assets.xcassets
│   │   │   ├── AppIcon.appiconset
│   │   │   │   └── Contents.json
│   │   │   └── Contents.json
│   │   ├── Base.lproj
│   │   │   ├── LaunchScreen.storyboard
│   │   │   └── Main.storyboard
│   │   ├── Info.plist
│   │   └── ViewController.swift
│   └── ios-app.xcodeproj
│       ├── project.pbxproj
│       └── project.xcworkspace
│           └── contents.xcworkspacedata
└── settings.gradle

To do this, we create an Android project and rename the app module into android-app (remember to change the name of the module in settings.gradle too). Now, let's create an iOS project ios-app in the root directory of the Android project.

Alternatively, download this archive with the ready setup.

2. Create a shared library module

To create a shared library we need to add a new gradle module (Android and mpp libraries are managed by build system gradle). To create the module:

Create an mpp-library directory (the name of our new gradle module) next to the apps to get:

├── android-app
├── ios-app
└── mpp-library

Create mpp-library/build.gradle. It will hold the multiplatform module configs. To begin with, the file will contain:

apply plugin: 'com.android.library'
apply plugin: 'org.jetbrains.kotlin.multiplatform'

Now let’s include the new module in settings.gradle:

include ':mpp-library'

git changes

After applying these changes you can run Gradle Sync and make sure that the module has connected, but can't be configured because the Android library is missing some data. First, we haven't specified Android SDK versions. Let's do this:

In mpp-library/build.gradle:

android {
    compileSdkVersion 28

    defaultConfig {
        minSdkVersion 21
        targetSdkVersion 28
    }
}

git changes

This time Gradle Sync will show that it's unable to read AndroidManifest. This file is essential for any Android module.

Let’s create mpp-library/src/main/AndroidManifest.xml with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<manifest package="com.icerockdev.library" />

git changes

Now Gradle Sync will run successfullу.

Setup mobile targets

Add the following to mpp-library/build.gradle:

kotlin {
    targets {
        android()
        iosArm64()
        iosX64()
    }
}

git changes

Create these directories:

• mpp-library/src/commonMain/kotlin/
• mpp-library/src/androidMain/kotlin/
• mpp-library/src/iosMain/kotlin/

git changes

Now we can run Gradle Sync and see that the directories commonMain/kotlin and androidMain/kotlin are highlighted as the source code directories unlike the iosMain/kotlin directory, but we'll talk about it later. For now let's make sure that everything Android-related is in androidMain.

Configure Android target

Move AndroidManifest.xml to androidMain:
mpp-library/src/main/AndroidManifest.xml → mpp-library/src/androidMain/AndroidManifest.xml
git changes

However, after this change you’ll notice that Gradle Sync is once again unable to read AndroidManifest. The reason is that the Android gradle plugin is not aware of the Kotlin Multiplatform plugin. To accurately move everything Android-related to androidMain, we need to add a special configuration.

Add to mpp-library/build.gradle:

android {
    //...

    sourceSets {
        main {
            setRoot('src/androidMain')
        }
        release {
            setRoot('src/androidMainRelease')
        }
        debug {
            setRoot('src/androidMainDebug')
        }
        test {
            setRoot('src/androidUnitTest')
        }
        testRelease {
            setRoot('src/androidUnitTestRelease')
        }
        testDebug {
            setRoot('src/androidUnitTestDebug')
        }
    }
}

git changes

Now Gradle Sync runs successfully.

3. Write common code

We create mpp-library/src/commonMain/kotlin/HelloWorld.kt with the following contents:

object HelloWorld {
    fun print() {
        println("hello common world")
    }
}

git changes

However, IDE will notify you that Kotlin has not been configured. That’s because we need to hook up the kotlin stdlib library to the common (aka shared) code.

In mpp-library/build.gradle:

kotlin {
    // ...

    sourceSets {
        commonMain {
            dependencies {
                implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
            }
        }
    }
}

git changes

Now IDE recognizes the Kotlin code, and we can write common code natively in Kotlin.

4. Android app realization

First, we need to hook up our shared library to android-app. We do it the same way as with any other Kotlin or Java module.
Add to android-app/build.gradle:

dependencies {
    // ...

    implementation project(":mpp-library")
}

Then call our print function on the main screen.
Add to android-app/src/main/java/com/icerockdev/android_app/MainActivity.kt:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {	
        // ...

        HelloWorld.print()
    }
}

git changes

Then, on Gradle Sync IDE will notify you that the SDK version in android-app is lower than the SDK version in mpp-library - let's upgrade it so that we can connect the shared library (otherwise, downgrade the SDK version in the shared library).
In android-app/build.gradle change the minimal version of the Android SDK to make it compatible with mpp-library:

android {
    // ...
    minSdkVersion 21
    // ...
}

git changes

After these changes we can run android-app on the emulator and make sure that the logcat console displays a message.

Add Android-specific code

Suppose, we want to use a platform-specific API. To do this, we add the platform-specific code in the shared library.

Create mpp-library/src/androidMain/kotlin/AndroidHelloWorld.kt with the following contents:

import android.util.Log

object AndroidHelloWorld {
    fun print() {
        Log.v("MPP", "hello android world")
    }
}

This allows us to see another class (AndroidHelloWorld) in the Android version of the shared library, and we can use any platform functionality inside this platform-specific code (android.util.Log in our example). Now we just need to call this function in the app too.

Add in android-app/src/main/java/com/icerockdev/android_app/MainActivity.kt:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {	
        // ...

        AndroidHelloWorld.print()
    }
}

git changes

After this change we can run android-app and check that the logging works through println and through Android's Log.

5. iOS app realization

If you remember, IDE didn’t recognize iosMain/kotlin as a directory with the source code. That because we have initialized two targets - iosArm64Main and iosX64Main. The source code of these targets is expected in iosArm64Main/kotlin and iosX64Main/kotlin correspondingly. So we have to either duplicate the code or generalize it somehow. We recommend to use symlinks in iosMain. This approach will help us avoid the source code duplication and provide all-around correct integration with IDE.

Let’s create symlinks mpp-library/src/iosArm64Main and mpp-library/src/iosX64Main as follows:

cd mpp-library/src
ln -s iosMain iosArm64Main
ln -s iosMain iosX64Main

git changes

Now we can run Gradle Sync and notice that iosX64Main/kotlin and iosArm64Main/kotlin have become the directories with the source code.
Let's add the iOS-specific code for iOS, using the platform API. To do this, we can create a file in IDE through any of the created directries-symlinks (iosX64Main,iosArm64Main) - they link to the same place.

Create mpp-library/src/iosMain/kotlin/IosHelloWorld.kt:

import platform.Foundation.NSLog

object IosHelloWorld {
    fun print() {
        NSLog("hello ios world")
    }
}

git changes

Now IDE correctly recognizes iOS platform APIs, has auto-import, autocomplete, and navigation to the definition.
We now can compile the framework that we will connect to the iOS app. But for framework compilation we need to complete project configuration first.
In mpp-library/build.gradle replace iosArm64() and iosX64() with a call to the configuration block:

kotlin {
    targets {
        // ...

        def configure = {
            binaries {
                framework("MultiPlatformLibrary")
            }
        }

        iosArm64("iosArm64", configure)
        iosX64("iosX64", configure)
    }
}

git changes

After this change we can call Gradle Task:mpp-library:linkMultiPlatformLibraryDebugFrameworkIosX64 to compile framework for the simulator. As a result, we will get our compiled framework in the directory mpp-library/build/bin/iosX64/MultiPlatformLibraryDebugFramework/. We now need to connect it to the iOS app.

Integrate framework into iOS app

Open ios-app/ios-app.xcodeproj in Xcode and add framework to the project. To do this:
Add the framework to the project.

As a result, the framework should appear here:

Now we need to add the framework to embed frameworks.

Once that’s done, there will be duplicates in the linked frameworks. Delete one of them to get this:

The last thing is to add the directory with the framework (./../mpp-library/build/bin/iosX64/MultiPlatformLibraryDebugFramework)to the search paths. We can do this in Build Settings of the target app.

git changes

Now we can update the view code by adding the following in ios-app/ios-app/ViewController.swift:

import UIKit
import MultiPlatformLibrary

class ViewController: UIViewController {
  override func viewDidLoad() {
    // ...

    HelloWorld().print()
    IosHelloWorld().print()
  }
}

git changes

After this we can launch the iOS app in the simulator (not on device! We’ve compiled the framework for the simulator, and the settings are hard coded accordingly for now).
After launching the app we see that both logging variants are working and that they look different, just as with Android.

6. Connect shared library via CocoaPods

We can use the dependency manager from CocoaPods to integrate the shared library into the app in the most simple and convenient (for iOS developers) way. The dependency manager will help us avoid configuring numerous project settings and a separate framework compilation through Android Studio.

Here’s how CocoaPods integration works. We create a local pod that contains an embed framework (already compiled from Kotlin), and the pod itself will participate only in one phase of compilation — via a script with the call to a gradletask to compile the framework.
CocoaPods dictates that the framework should always be in the same place. In our configuration it's going to be in build/cocoapods/framework/MultiPlatformLibrary.framework.

Setup framework compilation into a single directory

Add in mpp-library/build.gradle:
At the beginning:

import org.jetbrains.kotlin.gradle.plugin.mpp.Framework
import org.jetbrains.kotlin.gradle.tasks.KotlinNativeLink

At the end:

tasks.toList().forEach { task ->
    if(!(task instanceof KotlinNativeLink)) return
    def framework = task.binary
    if(!(framework instanceof Framework)) return
    def linkTask = framework.linkTask

    def syncTaskName = linkTask.name.replaceFirst("link", "sync")
    def syncFramework = tasks.create(syncTaskName, Sync.class) {
        group = "cocoapods"

        from(framework.outputDirectory)
        into(file("build/cocoapods/framework"))
    }
    syncFramework.dependsOn(linkTask)
}

Setup local CocoaPod containing Framework

Create mpp-library/MultiPlatformLibrary.podspec:

Pod::Spec.new do |spec|
    spec.name                     = 'MultiPlatformLibrary'
    spec.version                  = '0.1.0'
    spec.homepage                 = 'Link to a Kotlin/Native module homepage'
    spec.source                   = { :git => "Not Published", :tag => "Cocoapods/#{spec.name}/#{spec.version}" }
    spec.authors                  = 'IceRock Development'
    spec.license                  = ''
    spec.summary                  = 'Shared code between iOS and Android'

    spec.vendored_frameworks      = "build/cocoapods/framework/#{spec.name}.framework"
    spec.libraries                = "c++"
    spec.module_name              = "#{spec.name}_umbrella"

    spec.pod_target_xcconfig = {
        'MPP_LIBRARY_NAME' => 'MultiPlatformLibrary',
        'GRADLE_TASK[sdk=iphonesimulator*][config=*ebug]' => 'syncMultiPlatformLibraryDebugFrameworkIosX64',
        'GRADLE_TASK[sdk=iphonesimulator*][config=*elease]' => 'syncMultiPlatformLibraryReleaseFrameworkIosX64',
        'GRADLE_TASK[sdk=iphoneos*][config=*ebug]' => 'syncMultiPlatformLibraryDebugFrameworkIosArm64',
        'GRADLE_TASK[sdk=iphoneos*][config=*elease]' => 'syncMultiPlatformLibraryReleaseFrameworkIosArm64'
    }

    spec.script_phases = [
        {
            :name => 'Compile Kotlin/Native',
            :execution_position => :before_compile,
            :shell_path => '/bin/sh',
            :script => <<-SCRIPT
MPP_PROJECT_ROOT="$SRCROOT/../../mpp-library"

"$MPP_PROJECT_ROOT/../gradlew" -p "$MPP_PROJECT_ROOT" "$GRADLE_TASK"
            SCRIPT
        }
    ]
end

Connect our local CocoaPod to the project

Create ios-app/Podfile:

# ignore all warnings from all pods
inhibit_all_warnings!

use_frameworks!
platform :ios, '11.0'

# workaround for https://github.com/CocoaPods/CocoaPods/issues/8073
install! 'cocoapods', :disable_input_output_paths => true

target 'ios-app' do
  # MultiPlatformLibrary
  pod 'MultiPlatformLibrary', :path => '../mpp-library'
end

Remove previously added FRAMEWORK_SEARCH_PATHS in the project settings. To do this, press backspace and remove the value altogether instead of editing the field by leaving it empty.

Call pod install in the directory ios-app (cocoapods need to be installed prior to this).

git changes

After successful pod install we get direct integration between Xcode and the framework (including automatic recompilation of the framework when recompiling the Xcode project). After installing the pods you should close the current Xcode project and open ios-app/ios-app.xcworkspace.
Now we can launch the iOS app on a device and see that it works correctly.

(!) It’s possible that when building through Xcode gradle won't run successfully and notify you that java is missing. In this case you should install java development kit. When gradle runs through the Android Studio, it uses and openjdk variant from the Android Studio's built-in distributive. So everything works out-of-the-box for the Android project.

That’s all. Thanks for being with us :) Join to our twitter https://twitter.com/KotlinMPP

Read more about KMM in our blog.

How to start use Kotlin Multiplatform for mobile development was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

[Check out the links at the bottom to supply your tech-speaking colleagues with the juicy details on successfully delivering Kotlin Multiplatform projects, six real-life case studies inclusive.]

Read on to learn how your app can become multiplatform without eating into your development budget and at the same time offering your users unique, platform-specific experience.

The usual cross-platform suspects

When it comes to cross-platform mobile app development, the usual suspects that come to mind are tools like PhoneGap, Xamarin, Ionic, and lately also React Native with Flutter.

Their appeal has been hard to resist: a universal tool that can reduce development effort for building iOS and Android apps in parallel has been the holy grail in the app developer community for a while now.

Unfortunately, none of these technologies has managed to become the de facto instrument for building mobile apps, let alone oust native development. When working with these cross-platform app development tools, developers most often gripe about:

• Poor or limited UI/UX capabilities
• Lack of access to platform-specific advanced features (e.g., camera and NFC)
• Necessity to support three code bases: iOS, Android, and “cross-platform”

But with Kotlin/Native, and more specifically Kotlin Multiplatform, things are about to change as this nascent technology promises uncompromised native-app quality while significantly optimizing the app development process.

Multiplatform begs to differ

Kotlin is a programming language that got official support from Google a couple of years ago and since then has become the prime tool for building Android apps natively. But its potential is much more far-reaching than mere Android apps development. The Kotlin/Native technology — a part of the Kotlin ecosystem — allows developers to target the following platforms besides Android:

• iOS / MacOS
• Android
• Windows
• Linux
• WebAssembly

Multiplatform projects are an experimental feature in Kotlin that lets developers build iOS and Android apps at the same time using a shared codebase. This shared code base may contain the business logic, client-server pieces, and everything else that iOS and Android apps can share under the hood.

What’s important is that UI and UX remain 100% native for both iOS and Android. As a result, users get to work with apps that offer experiences similar to other best-in-class apps on each platform.

Kotlin Multiplatform advantages for your business

One thing you need to remember about using Multiplatform is that iOS and Android developers will still be working in their usual environment to build out UX/UI and other parts that have to do with advanced hardware functionality. The rest is handled via a shared Kotlin codebase that can and should be modular — to reuse its parts in future apps.

Uncompromised apps quality

iOS and Android apps that we’ve developed using Kotlin Multiplatform projects provide native UX and feature UIs that are specific to each platform. So you don’t need to worry about how your apps will look like on different devices. They will scale accordingly on different screens and will look stunning, while users will appreciate the familiar and comfortable controls.

Faster time to market

Kotlin is currently the primary programming language for developing Android apps. Therefore, it’s natural that an Android developer would be responsible for working on shared libraries on your multiplatform project. And an iOS developer, when working on the app, will be just plugging the Kotlin code pieces that the Android developer has prepared. This means your iOS engineer will not be spending time on developing the code that handles server interactions or the code that is responsible for the overall logic of the application or whatever else they decide to share. And as a result, the apps will hit the app stores quicker.

Lower maintenance costs

It’s a rare case when an app that drives real business value sits in an app store without being updated. How often do we get notifications on our phones to update another app, right? With Kotlin Multiplatform most of the time, you’ll only need to update the shared code (once) and then “apply” it to both apps, which is not the same as iOS and Android devs working separately on a new set of features for both platforms.

Iterative approach

The Multiplatform projects feature is also great because you don’t need to refactor (equals to developing from scratch with cross-platform solutions) your existing apps to start getting the value. Any new functionality can be added via a shared library and will cost you less during maintenance.

Support for more platforms

The true potential of Kotlin Multiplatform lays in how many platforms it supports besides iOS and Android: the desktop OSs such as MacOS and Windows, WebAssembly, etc. It may have a mind-blowing effect on all your business because you will be able to update your apps on all major platforms using far fewer resources than you did before.

Kotlin Multiplatform trade-offs

Of course, as with any new technology, there are some downsides to using Multiplatform on all app development projects.

iOS developers will need to catch up

While Android developers feel completely at home with Kotlin, iOS app developers will need to learn a few things to be able to contribute to developing shared code. One thing that probably makes the whole idea less scary is that Kotlin resembles Swift in many ways: It’s a modern, well-documented programming language with similar syntax and excellent tooling. So the learning curve won’t be that steep.

Android vs. iOS architectures

iOS and Android developers will need to coordinate their approach to the architecture of the future apps, as a shared codebase implies that this architecture will be practically identical on both platforms. This certainly implies some quality time at the start of the project for iOS and Android developers working in tandem.

Experimental feature

Kotlin developers are very explicit about their commitment to the Kotlin Multiplatform functionality, but they also plainly state that the feature is experimental. For app developers, this means that anything can change any time, and this is something they should be ready for.

Got questions about Multiplatform?

At IceRock, we have been investing in Multiplatform a lot because we see the future of mobile development with one universal environment for developing apps on all platforms in parallel.

As of June 2019, we’ve already helped our clients release six apps to the app stores and keep on honing our Kotlin Multiplatform skills, which allows us to offer more appealing development budgets and delivery timelines. For more technical details please read:

The Dos and Dont’s of Mobile Development with Kotlin Multiplatform: Part I

The Dos and Dont’s of Mobile Development with Kotlin Multiplatform: Part II

Please get in touch if you have questions about leveraging the power of Multiplatform on your app projects.

Read more about KMM in our blog.

The Rise of Multiplatform App Development: Smaller Budgets, Better Apps was originally published in IceRock Development on Medium, where people are continuing the conversation by highlighting and responding to this story.