Как уменьшить стоимость разработки или что нужно знать бизнесу о KMM

Сегодняшний рынок мобильной разработки предлагает решения под потребности и возможности любого бизнеса. Нужно лишь разобраться в плюсах и минусах технологий и выбрать ту, что поможет добиться поставленных целей, а в идеале — ещё и сэкономит время и бюджет. В статье технический директор MobileUp Евгений Валеев рассказывает об одной из наиболее перспективных кроссплатформенных технологий — KMM. И рассуждает, почему студиям разработки уже сейчас стоит инвестировать в неё, чтобы выиграть в конкурентной борьбе в будущем

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

Kotlin Multiplatform Mobile (КММ) — это технология для кроссплатформенной мобильной разработки. Обычно версии одного и того же приложения для iOS и Android имеют много общего. Их бизнес-логика, в том числе код, отвечающий за управление данными и аналитику, практически ничем не отличается. Разница заметна только в UI. Вот авторы KMM и подумали: «А почему бы не использовать единую кодовую базу для бизнес-логики обоих приложений?».

Когда iOS- и Android-команды занимаются бизнес-логикой по отдельности, они могут реализовать её по-разному. Соответственно, приложения тоже начнут вести себя по-разному. А это значит в два раза больше возможностей для ошибок и в два раза больше работы. KMM позволяет использовать общую кодовую базу для бизнес-логики приложений и писать платформенный код только там, где это необходимо. Например, для реализации интерфейса.

Такой подход кардинально отличается от других кроссплатформенных решений типа Flutter или React Native. Их принцип заключается в том, чтобы сделать общими все части. Но, скажем, реализовать универсальный UI невозможно. Поэтому до рабочего состояния приложения приходится «допиливать». И сложность этого «допиливания» возрастает по мере усложнения проекта.

Соответственно, три главных преимущества KMM:

В мире мобильной разработки KMM — совсем новая технология. Это значит, что в ней хватает «сырых» мест и каких-то нерешенных вопросов. Тот же Flutter по сравнению с ней более зрелый. Здесь все типовые и даже нетиповые юзкейсы давно проработаны и легко находятся в интернете.

Для KMM готовых решений, к которым все привыкли, может просто не быть. Когда бизнес-логика пишется кроссплатформенно, библиотеки и прочие инструменты должны быть кроссплатформенными. Если их нет, приходится встраивать в каждую платформу свои нативные решения, а затем дружить с ними кроссплатформенную бизнес-логику. Подход понятен, но делать это руками довольно трудоёмко.

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

Пожалуй, самая большая сложность заключается в том, что бизнес-логика пишется на Kotlin. И пока Android-команда занимается этим, iOS-команде остаётся, грубо говоря, «раскрашивать» кнопки. Разработчики, которые привыкли к интересным задачам и нацелены на развитие, могут воспринять такую работу как некий шаг назад.

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

Переход на новые технологии — это всегда инвестиция. Сначала компания тратит ресурсы на их внедрение, а потом технологии работают на неё и помогают получать разнообразные выгоды. Например, KMM при правильном подходе позволяет сократить трудозатраты при разработке проекта на 30% (такую экономию получили мы). Соответственно, команда может выпускать приложения за более короткий срок, укладываясь при этом в меньший бюджет.

Если команда знакома и умеет работать с KMM, как таковых затрат на внедрение технологии нет. Если же компания всегда разрабатывала нативно, а затем решила попробовать KMM (это как раз наш кейс), появляются определенные издержки. Во-первых, нужно выделить время на то, чтобы техлиды изучили особенности технологии, поискали подводные камни и разобрались, как всё работает. Во-вторых, нужно закладывать дополнительные часы непосредственно на разработку. Поскольку при работе с первыми проектами на KMM iOS- и Android-команды, скорее всего, будут тратить больше времени на решение технических вопросов, которые уже давно решены в нативной разработке. Один из примеров — навигация между экранами. В нативной разработке навигацией управляет UI-фреймворк. Но с KMM такой вариант нам не подошел, хотелось переиспользовать логику навигации между платформами. Мы придумали, как описывать навигацию в общем коде и подружить ее с Jetpack Compose и Swift UI.

Всё началось с того, что мы искали способы удешевить разработку. Внимание как раз привлек KMM. Я дал задание Android-техлиду поисследовать технологию и подготовить обзорную презентацию о ней на компанию. Чуть позже мы провели технический спичап — уже конкретно для iOS- и Android-разработчиков. Взвесили все «за» и «против» и поняли, что нужно пробовать, потому что это шанс получить неплохое конкурентное преимущество.

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

Что обычно мы делали, если нужно было уменьшить смету? Предлагали отказаться от менее приоритетных фичей. Но это не всегда устраивало клиентов. Здесь мы пошли другим путём — решили сократить смету за счет использования KMM. Получилась win-win ситуация, когда у нас появилась возможность обкатать новую технологию на реальном проекте, а у заказчика — реализовать всё, что он хотел, но за меньшую цену.

Что важно: мы сократили смету на 30%, но поскольку KMM — новая для нас технология, сверху заложили внутренний бюджет на непредвиденные риски. Если бы что-то пошло не по плану, и мы разбирались в какой-то задаче дольше, чем нужно, расходы на это были бы на нашей стороне. Это дополнение к предыдущему вопросу об инвестициях — компания-разработчик обязательно должна закладывать риски и брать на себя ответственность.

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

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

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

Если таких слоев нет, смысла внедрять KMM тоже нет. Сначала нужно поработать над архитектурой и только потом задумываться об использовании кроссплатформенных решений.

Думаю, с повышением зрелости у KMM есть все шансы, если не подвинуть нативную разработку, то, как минимум, занять внушительную долю рынка. Другие кроссплатформенные решения не могли предложить нативное поведение приложения, их максимум — понятный UX. Но KMM решил эту проблему.

KMM позволяет создавать приложения, ничем не отличающиеся от нативных, и при этом экономить до 30-40% на разработке — что сравнимо с экономией при использовании других кроссплатформенных фреймворков, если разрабатывать качественный UI. И в среднесрочной перспективе, когда KMM станет достаточно зрелым, в конкурентной борьбе выиграют те компании, которые уже обладают экспертизой разработки приложений на KMM.