Как Kotlin Multiplatform Mobile приходит на помощь продакту

О KMM мало говорят и пишут. Поэтому неудивительно, что руководители крупных проектов почти ничего про него не слышали. А если и слышали, то видят трудности в переходе на эту технологию и не знают о выгодах.

Но люди, которые работали с КММ, понимают, как эта технология может помочь при разработке приложений. В этой статье мы расскажем о преимуществах KMM и о том, как обойти препятствия, связанные с ее внедрением.

Kotlin Multiplatform Mobile — набор инструментов, позволяющий написать код и скомпилировать его в нативную библиотеку Android, нативный фреймворк iOS и других платформ. То есть получить такие библиотеки, к которым привыкли разработчики на каждой из платформ. Это позволяет сэкономить до трети бюджета, ускорить разработку на четверть и сделать интерфейс приложений таким, каким он будет привычнее для пользователей той или иной платформы.

1. Ваши разработчики будут делать одно изменение в бизнес-логике, а повлияет оно сразу на две платформы

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

Две версии продукта можно разрабатывать одновременно, а следить нужно будет только за одним процессом.

В чем может возникнуть проблема: разработчики разных платформ по-разному решают одни и те же задачи. Поэтому Android-разработчику может потребоваться время, чтобы разобраться в коде, если бизнес-логику делала команда iOS-разработчиков, и наоборот.

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

2. При разработке бизнес-логики ваши разработчики станут взаимозаменяемыми

Это сделает управление проектом более гибким. Исправить ошибки или внести изменения в оба проекта сможет разработчик любой платформы. Например, Android-разработчик исправит ошибку, и исправления отразятся на обеих платформах. Таким образом, он косвенно ускорит разработку не своей платформы.

Это особенно помогает, если команда разработчиков проекта небольшая.

В чем может возникнуть проблема: как и в предыдущем пункте — если логику программировала команда одной платформы, то команде другой платформы при реализации своей версии понадобится время, чтобы разобраться в коде. Вместо экономии времени возникнет лишняя итерация.

Как этого избежать: синхронизировать команды на техническом уровне — сначала обе команды должны совместно продумать бизнес-логику. При внедрении общей логики на каждую платформу, команда будет понимать код так, будто сама его писала.

3. Снизятся затраты на тестирование, ведь обе версии приложения будут вести себя одинаково

Если версии приложения разрабатываются независимо друг от друга, Android-разработчик может обработать ошибку одним образом, а iOS-разработчик — другим. Например, при вводе данных в одной версии может возникнуть абстрактное сообщение об ошибке, а в другой — будет точно указано, какое поле заполнено неверно.

А если версии идентичны на уровне технологий, то при проверке определенных условий, они будут вести себя одинаково. Это позволяет тестировать продукт только на одной платформе, ведь на второй он будет вести себя точно так же. Общую бизнес-логику надо будет проверить всего один раз.

В чем может возникнуть проблема: этот принцип касается только работы с бизнес-логикой. UI в каждой из версий нативный, поэтому надо четко знать, с чем связана тестируемая в данный момент проблема — с логикой или с UI.

Как этого избежать: перед началом тестирования можно пообщаться с технической командой. Они могут дать краткое овервью по проекту, рассказать, какие части связаны с бизнес-логикой, а какие — нет.

4. Если заказчику впоследствии потребуется версия на iOS, ваша команда сможет быстро ее развернуть

Если в Android-приложении есть общая бизнес-логика на KMM, не составит труда развернуть ее на другой платформе. Останется только поработать над UI для iOS.

В чем может возникнуть проблема: iOS-разработчику может понадобиться время на освоение KMM. Некоторые инструменты KMM, вроде Android Studio, языка Kotlin, Gradle, не входят в нативную инфраструктуру iOS, и разработчики могут не иметь ни времени, ни желания для изучения «чужеродных» инструментов.

Как этого избежать: по нашему опыту, лучше еще на этапе собеседования выяснить готовность iOS-разработчиков работать с чем-то новым. Пробовать грамотно объяснять плюсы KMM, помогать с адаптацией: предоставить обучение, подробную документацию и библиотеки. Для KMM написано много бесплатных опенсорс-библиотек, которые делают разработку удобнее, — в том числе можно дать наши.

Нативный UI — значит, созданный «родными» инструментами соответствующих платформ. Это позволяет держать планку качества на высоком уровне. Вы можете использовать все особенности и возможности каждой из платформ, чтобы адаптировать дизайн под них и сделать так, чтобы пользователю было привычно пользоваться интерфейсом.

Это удобный мультиплатформенный инструмент для разработки приложений. Он не идеален, но продолжает развиваться и совершенствоваться, несмотря на санкции. В том числе — благодаря сообществу. В нашем чате в «Телеграме», посвященном KMM, уже 1350 человек. И они активно обсуждают проблемы и их решения, порой без нашего участия.