• Three-framework Problem with Kotlin Multiplatform Mobile
  • Original author: Yev Kanivets
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Hoarfroster
  • Proofread by: Kimhooo, HumanBeingXenon

Kotlin Multiplatform Mobile is maturing, with more and more teams using the platform to develop applications on both Android and iOS. But as more and more projects adopt it, new problems arise.

Today, we’ll talk about problems that can occur in a modular application. These apps use multiple KMP (Kotlin Multi-platform) frameworks that are shared and used within iOS apps. These KMP frameworks all use common code from third-party modules or libraries visible to iOS programs.

The actual sample

Imagine a simple application that keeps track of all authenticated users’ favorite authors and books. All data is stored in the back end, so we want to share relationships, business, and presentation logic in mobile applications using Kotlin Multiplatform technology.

Usage of this application will increase over the next few months, so we want to start with an extensible architecture. We decided to divide the code base into three modules (one module for each function) : certification, author, and book.

Each module in an Android application is represented by two submodules: a shared KMP module and an Android-specific module. In iOS, the shared KMP modules are compiled into the iOS framework and reused in iOS apps with the same architecture as Android apps (one module for each function).

It is worth mentioning that the Author and Book modules rely on the Authentication module to serve authenticated user entities so that the back end can return personalized responses — authors and books.

The actual problem

This approach works fine in Android applications, but can cause tedious problems when applied to iOS applications that import kMP-driven frameworks.

The actual problem is that the Kotlin/Native plug-in contains all of the dependencies in the currently compiled module during iOS module compilation, so it is built in. In addition, to prevent collisions, it prefixes all explicit dependency names with the corresponding library names.

This is handy for a single module or a group of independent modules. However, once two or more modules use the same dependency visible to the iOS app, you have copied multiple versions of the same dependency.

In our example, the user entity from the author module and the user entity from the books module will be the same in the Android application, but will be two different entities in the iOS application, even though they are the same.

In other words, we’ll have two distinct authentication modules in our iOS app, and they don’t share anything, they don’t share anything — they don’t share classes, states, everything!

Actual solution

I had the opportunity to talk to a KMP team about this problem, and their recommended solution (at least that was the optimal solution 6 months ago) was to use the Umbrella module, which contains all the shared KMP modules. This is a framework that will be imported into iOS applications.

This is obviously a disadvantage that breaks modularity on iOS. However, as long as the iOS module matches the Android module, we are less likely to use an out-of-bounds class from the Umbrella framework in the wrong place.

Good architecture helps a lot here, too. For example, with the Clean architecture, only the top layer of the shared KMP module is exposed. In our case, it is a presentation layer that is difficult to use anywhere other than the target module.

conclusion

There is no perfect technology or solution. You should be prepared to deal with problems because they will come up throughout development, especially if you are brave enough to use alpha or beta versions of software.

Kotlin Multiplatform allows you to use modular architectures, but there are some important limitations. These constraints must be taken into account when planning the implementation of common parts and their use in iOS applications.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.