Thread by @mobileunderhood

Думаю рассказ про мой опыт с Kotlin Multiplatform (далее просто МП/MP) стоит начать с небольшого предисловия. Я занимаюсь разработкой приложения для отслеживания своей активности для лыжников и сноубордистов

У нас уже больше 1.5 года была вынесена часть логики в МП, это была логика определения состояния пользователя, будь то отдых, подъем на подъёмнике или райд. Там в основном алгоритмы, но не простые и хотелось иметь single source of truth на обеих платформах...

... что бы не фиксать разные баги на iOS и Android. Так как с точки кода это был не сложный модуль работало там все прекрасно, но потом мы решили что хотим пойти дальше и сделать так что бы на платформе остался только UI и какие то специфические сервисы

План изначально был такой:
Потестить МП на каких нибудь простых экранах
Перенести туда Нетворк слой
Перенести базу
Перенести вью модели
Перенести сервисы
Перенести разные инфраструктурные вещи
Перенести все что можно
------ Мы сейчас тут ------
Профит!

Уже был вопрос про UI, сейчас разрабатываются разные библиотеки, которые позволяют описывать UI в МП, но мы решили их не использовать, потому что все ещё сырое(

На данный момент из интересного у нас в МП частично унесены пермишены, частично строковые ресурсы, что кстати тоже довольно удобно, опять же Single Source of Truth.

Но если с детектором активности все было гладко, то тут начались проблемы. Первым делом у нас стрельнул Ktor (http клиент/сервер на котлине), который ни в какую не хотел работать на iOS. Проблема была с многопоточностью, которая в KN реализована довольно интересным способом...

... сейчас я не буду рассказывать об этом, но если интересно есть хорошая статья в двух частях про это Kotlin Native Stranger Threads
1. medium.com/@kpgalligan/ko…
2. medium.com/@kpgalligan/ko…

Проблема в том, что при компиляции андроид приложения это не играет роли, потому что таргетом для сборки МП является jwm (на самом деле android, но в общем суть одна). А под iOS пока все не очень круто и ктор не умеет нормально работать на бек граунде и ..

При запуске в бекграунд потоке происходит freez (объект пытается стать иммутабельным) и все ломается. Поэтому в конечном итоге мы пришли к тому, что у нас два разных клиента, реализованных через expect/actual (про них чуть позже). Для таргета android это ктор...

...а для iOS это UrlSession

expect/actual, это, имо, довольно удобный механизм, который позволяет сделать разные реализации чего либо для разных платформ, таким образом у нас есть, например, LiveData, которая для андроида использует под капотом настоящую LiveData, а для iOS, где не нужен такой контроль...

... за жизненным циклом простую логику. Тоже самое с нашими базовыми ViewModel и с некоторыми другими компонентами где нужны классы из платформенного SDK

Выглядит это примерно вот так:
На первом скриншоте экспект класс, а на втором его платформенная реализация для Android

Наши бекграунд сервисы в конечном итоге были перенесены в МП, но все ещё стартуются из приложения

А теперь давайте поговорим про поддержку и библиотеки. Самое обидное это когда ты находишь какую нибудь крутую библиотеку, а она не поддерживается для МП, хотя используется в ней только Котлин и все что надо сделать это поменять ее структуру, так у нас было с KotlinResult

Но в целом уже библиотек довольно много, и причем много из них сфокусированы на мобильных платформах

В целом иногда больно, но пользоваться можно