Технологичный способ удешевить разработку: что нужно знать бизнесу о KMM
Материал для студий, которые думают о внедрении KMM, а также компаний, которые сомневаются, стоит ли использовать эту технологию в своем приложении.
Сегодняшний рынок мобильной разработки предлагает решения под потребности и возможности любого бизнеса. Нужно лишь разобраться в плюсах и минусах технологий и выбрать ту, что поможет добиться поставленных целей, а в идеале — ещё и сэкономит время и бюджет. В статье технический директор MobileUp Евгений Валеев рассказывает об одной из наиболее перспективных кроссплатформенных технологий — KMM. А также делится опытом и результатами её внедрения при разработке маркетплейса.
Что такое Kotlin Multiplatform Mobile
Kotlin Multiplatform Mobile (КММ) — это технология для кроссплатформенной мобильной разработки. Обычно версии одного и того же приложения для iOS и Android имеют много общего. Их бизнес-логика, включая код для управления данными и аналитику, практически идентична. Основное различие заключается лишь в пользовательском интерфейсе. И вот разработчики KMM подумали: «А почему бы не использовать одну кодовую базу для бизнес-логики обоих приложений?»
Когда команды iOS и Android работают над бизнес-логикой отдельно, они могут реализовать её по-разному. В результате приложения начинают вести себя по-разному, что приводит к увеличению количества ошибок и объема работы. KMM позволяет использовать единую кодовую базу для бизнес-логики приложений и писать платформенный код только там, где это действительно необходимо. Например, для реализации пользовательского интерфейса.
Такой подход существенно отличается от других кроссплатформенных решений вроде Flutter или React Native. Их принцип заключается в создании общего кода для всех частей приложения. Однако создание универсального UI часто невозможно. Поэтому приложение приходится «допиливать» до рабочего состояния, и сложность этого процесса возрастает по мере усложнения проекта.
Итак, три главных преимущества KMM:
Нативный UI для каждой платформы. Пользователи приложения не заметят разницы между нативной разработкой и тем, что сделано с помощью KMM. Технология упрощает и ускоряет разработку, но не влияет на итоговый результат с точки зрения юзера. Он будет видеть нативный UI и не сможет отличить приложение, написанное на KMM, от нативного. Это и является ключевым преимуществом.
Сокращение времени разработки. Ещё одно преимущество — бизнес-логика разрабатывается один раз для обеих платформ, а не дважды для каждой. Это позволяет сократить время разработки и, как следствие, снизить стоимость проекта.
Одинаковое поведение на всех платформах. Это снижает вероятность возникновения ошибок и сокращает время на исправление багов.
Риски при работе с KMM
KMM — это относительно новая технология в мире мобильной разработки. Это означает, что она может иметь «сырые» места и нерешенные вопросы. В сравнении с KMM, такие технологии, как Flutter, более зрелые. Для них уже проработаны типовые и даже нетиповые случаи использования, которые легко найти в интернете.
Для KMM может не быть готовых решений, к которым все привыкли. Когда бизнес-логика пишется кроссплатформенно, библиотеки и инструменты должны быть кроссплатформенными. Если таких инструментов нет, приходится внедрять нативные решения для каждой платформы и затем интегрировать их с кроссплатформенной бизнес-логикой. Такой подход понятен, но требует значительных трудозатрат.
Кроме того, KMM имеет слоистую архитектуру. Если команда уже работала с такой архитектурой, переход на новую технологию будет практически незаметным для Android-разработчиков. Для iOS-разработчиков это сложнее, поскольку внедрение нового подхода всегда требует выхода из зоны комфорта. Пройти процесс полностью безболезненно не удастся, но это нормально.
Сложность для iOS-команды
Одной из самых больших сложностей является то, что бизнес-логика пишется на Kotlin. Пока Android-команда занимается этим, iOS-команде остаётся «раскрашивать» кнопки. Разработчики, привыкшие к более интересным задачам и стремящиеся к развитию, могут воспринять такую работу как шаг назад.
Если компания решит полностью перейти на KMM, перед iOS-командой станет выбор: либо заниматься разработкой пользовательского интерфейса, либо участвовать в создании бизнес-логики. Для второго варианта потребуется расширение компетенций и изучение Kotlin.
Стоит ли инвестировать в KMM
Переход на новые технологии всегда требует инвестиций. Но KMM позволяет сократить трудозатраты при разработке проекта до 30% (такую экономию мы получили в одном из кейсов). Это означает, что команда может выпускать приложения быстрее и при меньших затратах.
Если команда уже знакома с KMM, затраты на внедрение технологии минимальны. Если же компания всегда занималась нативной разработкой и решила попробовать KMM (как это было в нашем случае), возникают определенные издержки. Во-первых, нужно выделить время для изучения технологии техлидами, чтобы понять её особенности и подводные камни. Во-вторых, требуется закладывать дополнительные часы на разработку. При работе над первыми проектами на KMM iOS- и Android-команды могут тратить больше времени на решение технических вопросов, которые уже давно решены в нативной разработке. Например, мы столкнулись с проблемой навигации между экранами. В нативной разработке навигацией управляет UI-фреймворк, но с KMM нам захотелось переиспользовать логику навигации между платформами. Мы нашли способ описывать навигацию в общем коде и интегрировать её с Jetpack Compose и SwiftUI.
Опыт MobileUp: как мы внедрили KMM
Мы обратили внимание на KMM и я поручил Android-техлиду исследовать технологию и подготовить обзорную презентацию для компании. Позже мы провели технический спичап для iOS- и Android-разработчиков. Взвесили все плюсы и минусы и решили попробовать KMM, поскольку это дало бы нам шанс получить конкурентное преимущество на рынке заказной разработки.
Мы выбрали один из наших внутренних проектов и полностью переписали его на KMM. Это позволило проверить гипотезы, выявить подводные камни и немного освоить технологию. Например, мы поняли, что важно, чтобы команды iOS и Android работали как единое целое. По окончании тестовой работы у нас появился реальный проект, где вся желаемая функциональности не вписывалась в бюджет заказчика.
Обычно, чтобы уменьшить смету, мы предлагали отказаться от менее приоритетных функций. Однако это не всегда устраивало клиентов. В этом случае мы решили сократить смету за счёт использования KMM. Это создало win-win ситуацию: мы обкатали новую технологию на реальном проекте, а заказчик смог реализовать все желаемые функции по сниженной цене.
Важно отметить, что мы сократили смету на 30%, но поскольку KMM была новой для нас технологией, мы добавили внутренний бюджет на непредвиденные риски. Если бы что-то пошло не по плану и мы тратили больше времени на решение задач, расходы покрывались бы нашей компанией. Это дополнение к инвестициям — разработчик должен учитывать риски и брать на себя ответственность.
В итоге общий бюджет остался в рамках и даже сэкономил заказчику пару процентов от изначальной оценки стоимости.
Внедрение KMM в существующие проекты
Внедрение KMM в существующие проекты зависит от архитектуры. Если архитектура не предусматривает разделение на слои, интеграция KMM будет очень сложной или невозможной. Если же архитектура благоприятствует этому, KMM можно использовать в существующем проекте.
Архитектурные слои приложения можно разделить на бизнес-логику и пользовательский интерфейс, что актуально для iOS и Android. Если в существующем проекте архитектура уже разделена на слои, KMM позволяет соединить верхний слой UI на iOS с нижним слоем бизнес-логики на Android.
Если таких слоев нет, внедрение KMM тоже нецелесообразно. В этом случае сначала следует поработать над архитектурой, а затем рассматривать использование кроссплатформенных решений.
Перспективы KMM
С увеличением зрелости у KMM есть все шансы занять значительную долю рынка, если не полностью заменить нативную разработку. Другие кроссплатформенные решения не могли предложить нативное поведение приложения, их максимум — понятный UX. KMM решает эту проблему.
KMM позволяет создавать приложения, которые ничем не отличаются от нативных, и при этом экономить до 30–40% на разработке. Это сопоставимо с экономией, достигаемой при использовании других кроссплатформенных фреймворков, если разрабатывать качественный UI. В среднесрочной перспективе, когда KMM станет достаточно зрелым, компании с опытом разработки на этой технологии получат конкурентное преимущество.
Просто о сложном
Новости 
Кейсы 
How to 
Интервью и дискуссии 
Маркетинговые исследования 
Проверено ADPASS 
Рекламные кампании 