Section 1 - Getting Started with Multiplatform Mobile Development Using Kotlin
This section covers the core concepts of Kotlin Multiplatform. Comparing cross-platform to native technologies, it describes the market gap that Kotlin Multiplatform fills.
Moreover, it explains the rationale behind why this new technology is one to learn and adopt while giving a deep dive into its architecture and how it makes sharing code between different platforms possible.
This section comprises the following chapters:
- Chapter 1, The Battle Between Native, Cross-Platform, and Multiplatform
- Chapter 2, Exploring the Three Compilers of Kotlin Multiplatform
- Chapter 3, Introducing Kotlin for Swift Developers
Chapter 1: The Battle Between Native, Cross-Platform, and Multiplatform
The proliferation of smartphones has led to the development of a large number of applications, making app development an important field. Because the same service in the form of an application needs to be developed on multiple platforms, various technologies, in addition to native solutions, have started to arise – first, cross-platform and now multiplatform. These technologies have been developed mainly to cut costs and make the application development process more efficient.
We'll start by learning about the issues with native development, why cross-platform can solve some of these issues with compromises, and how multiplatform can be a better solution. Also, if you're at the start of your career, we'll dive into why it may be better to focus on a multiplatform technology stack, rather than a cross-platform technology stack. I realize that this chapter is quite theoretical, but I encourage you to bear with me – it should help you build up that dopamine release, which is going to be paramount in the following chapters to maximize your learning.
In this chapter, we're going to cover the following topics:
- Understanding the compounding costs of native development
- Exploring the pitfalls of cross-platform solutions
- Adopting a multiplatform approach
Understanding the compounding costs of native development
The manufacturer of every platform or operating system provides a software development kit (SDK), which contains everything necessary for someone to develop applications on that specific platform or OS. Here, we are referring to a native development process, where someone uses that SDK to develop applications for that single platform.
Cross-platform frameworks have a separate SDK, which is usually a layer on top of a native SDK.
Cross-platform solutions are becoming more and more popular; for example, as of May 2021, out of ~5 million apps on the Google Play Store, more than 200,000 are Flutter-based apps, which is not bad for fairly new technology (4-6% of all the apps published in Google Play Store).
For a more detailed look at some of Google Play's statistics, visit https://www.appventurez.com/blog/google-play-store-statistics.
If you are interested in learning a bit more about Flutter-based applications, check out https://www.youtube.com/watch?v=a553D0s7HeE&t=1779s.
To understand why there is an increasing demand for cross-platform solutions, we need to understand what issues people face with native development.
One of the reasons for the increase in demand for cross-platform solutions is developer convenience. Becoming an expert nowadays, and especially staying one, in any programming language or framework is not an easy job. While transferring concepts and general knowledge can be achieved in varying degrees, depending on the similarity between two platforms, becoming an expert in a new language still requires learning. Therefore, those people who'd like to become an all-around frontend developer with considerable expertise in Android, the web, and iOS have to learn not only three different frameworks but their primary languages as well: Swift/Obj-C, Kotlin/Java, and JavaScript. This is the case unless there is a shortcut providing passage between these worlds, which is generally covered by cross-platform technologies.
This explains the openness developers have toward using cross-platform, but it's only one part of the equation – the supply – and we still need demand for it.
There is another major reason for developers steering away from native solutions: cost.
The cost of native app development
So, why doesn't everyone want to go with a native development process? This choice is somewhat similar to buying tailored garments versus ready-made garments from clothing stores: it's cheaper.
Before we understand the costs associated with Native development, let's introduce the concept of nativeness first. Nativeness is a measure of the degree to which the quality of a product conforms with the peculiarities of a platform. For example, imagine the differences between a native English speaker and a non-native one (potentially the author of this book, who has an imperfect Hungarian accent). The differences can range from subtle to more obvious, based on the complexity of the words and the non-native speaker's skills.
Now, why would anyone give up nativeness? It's mainly because people can achieve lower costs (or at least they think they can).
To get a better picture of the cost variance between native, cross-platform, and multiplatform, we're going to examine the relationship between a feature's complexity and the development cost that's needed to bring it to life in a simplistic manner. Features can consist of multiple sub-features. So, for example, a delivery app can be thought of as an app with one delivery feature, where the complexity of this feature is the sum of all of its sub-features.
In the case of native development, since there is little to no cost reduction, the cost of development is determined as follows:
Cost of development (n) = n * FC
Here, n is the number of platforms and FC is the feature complexity, which, as we mentioned earlier, is the sum of all the sub-features that comprise a feature.
Important Note
This and the following calculations are approximations and only describe the reality simplistically. Nevertheless, they should provide you with a better picture to understand the cost differences between frameworks.
This is what costs would look like if you were developing a product on two (blue line) and three (red line) platforms, respectively, where there is no cost reduction by sharing code:
Figure 1.1 – Cost of native development as a function of feature complexity
Unfortunately, there is a little beast known as synchronization between platforms that we didn't take into account, which can significantly increase development costs, bit by bit; it's hard to plan for it, so it can be an unknown variable in calculations.
Synchronization
What is the specialty of frontend and mobile products in general? They are mostly similar, though they do have some differences. Thus, the goal of developers is to achieve consistency between platforms while paying a...
