О KMM мало говорят и пишут. Поэтому неудивительно, что руководители крупных проектов почти ничего про него не слышали. А если и слышали, то видят трудности в переходе на эту технологию и не знают о выгодах.
Но люди, которые работали с КММ, понимают, как эта технология может помочь при разработке приложений. В этой статье мы расскажем о преимуществах KMM и о том, как обойти препятствия, связанные с ее внедрением.
Что это за технология
Kotlin Multiplatform Mobile — набор инструментов, позволяющий написать код и скомпилировать его в нативную библиотеку Android, нативный фреймворк iOS и других платформ. То есть получить такие библиотеки, к которым привыкли разработчики на каждой из платформ. Это позволяет сэкономить до трети бюджета, ускорить разработку на четверть и сделать интерфейс приложений таким, каким он будет привычнее для пользователей той или иной платформы.
Мы уже рассказывали о KMM в наших статьях, например о том, как KMM снижает риски при разработке iOS-приложений, и о том, как KMM продолжает развиваться даже в условиях санкций.
Что может дать вашей команде и вашим заказчикам общая бизнес-логика
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 при общей бизнес-логике — это то, что сделает ваши продукты лучше
Нативный UI — значит, созданный «родными» инструментами соответствующих платформ. Это позволяет держать планку качества на высоком уровне. Вы можете использовать все особенности и возможности каждой из платформ, чтобы адаптировать дизайн под них и сделать так, чтобы пользователю было привычно пользоваться интерфейсом.
Экономия, скорость разработки, удобство пользования — это все может быть благодаря Kotlin Multiplatform Mobile
Это удобный мультиплатформенный инструмент для разработки приложений. Он не идеален, но продолжает развиваться и совершенствоваться, несмотря на санкции. В том числе — благодаря сообществу. В нашем чате в «Телеграме», посвященном KMM, уже 1350 человек. И они активно обсуждают проблемы и их решения, порой без нашего участия.
- Если у вас остались вопросы, то присоединяйтесь к чату или запишитесь на бесплатную консультацию.
- Мы также можем подключиться к проекту, подписав NDA, и помочь перевести ваш проект на KMM.
- А еще у нас есть канал в «Телеграме» — заходите, если вам интересно, как применяют KMM на практике.
Звучит всё круто, но чем это лучше Flutter, который очень давно в ходу и уже доказал свою надежность и эффективность?
Не будем спорить про преимущества KMM/Flutter/RN, это слишком холиварная тема. Для нас KMM стал основной технологией из-за нескольких факторов:
1. Низкий порог вхождения для android разработчиков, которых у нас много. iOS разработчиков мы достаточно быстро погрузили в необходимые технологии, и продолжаем всех обучать
2. KMM позволяет реализовать нативный UI на каждой платформе, что привычно пользователям, и не вызывает отторжения
Очень классная статья
Хорошая статья
Джетбрэйнс опять со своей рекламой. Суть предложения - в отличии от давно известных инструментов они добавили нативный внешний вид. Все остальные недостатки известных инструментов, разумеется, они снова тащат с собой.
Нельзя отменить iOS разрабов, потому что только у них есть простой доступ ко всем возможностям системы. Но джеты, понятно, хотят себя засунуть во все щели и вот лезут на айфон. И в бэкенд тоже лезут. Везде, куда не просят, они обязательно лезут. Это логично, так живёт бизнес - орёт во все уши, что бы только у него покупали. Но суть-то остаётся прежней - нас банально хотят лишить простых и привычных способов, заменив при помощи рекламы на более дорогие.
Почему дорогие? Ну, во первых, джетам надо много денег, а в том числе за эту рекламу кто-то из вас обязан заплатить. Во вторых - как только вам понадобятся специфические для платформы особенности - вам придётся нанять iOS разработчик. То есть если вы делаете примитив, тогда и так уже есть куча инструментов, а если же вы делаете что-то, требующее системных возможностей - вы нанимаете iOS разработчика. И места джетам здесь не остаётся. Ну и, в третьих, вам придётся всех разрабов переобучать или увольнять из-за того, что джеты вам насоветовали "экономить". Ага, прекрасная экономия - тратим денег на переобучение, или на найм почти отсутствующих спецов по этому кмм, а потом обнаруживаем, что нам надо подстраиваться под пользователей, а этот кмм не работает с нужной фичей. Ура, возвращаемся к старым разрабам и старым навыкам. А деньги уже выбросили.
Вообще весь этот бизнес типа "у нас всё лучше" в подавляющем большинстве оказывается типом "у нас очередная туфта".