Жизненный цикл большинства мобильных приложений — несколько лет. За это время вокруг продукта вырастает целая экосистема из интеграций, людей, процессов и логики. Чем более зрелая система, тем сложнее её развивать из-за роста количества зависимостей, ограничений и стоимости изменений.
Поддержка двух нативных приложений в таких условиях может быть дорогой в финансовом плане и сложной в скорости вывода новых функциональностей. Один из способов модернизировать продукт и снизить расходы на поддержку – постепенно перейти на Kotlin Multiplatform.
Это блог CleverPumpkin. Уже 15 лет мы разрабатываем сайты, мобильные приложения разного масштаба, делаем интеграции и внедряем AI. Мы создавали новые проекты и развиваем их для Aviasales, Kassir.ru, Хабра, Interfax, Sports, помогаем компаниям обновить технологический стек на более современные решения.
В этой статье технический директор Александр Кияйкин и iOS-разработчик Мария Нестерова из CleverPumpkin вместе с экспертами X5 Tech, AvitoTech и MAGNIT OMNI разбирают, как компании со зрелыми цифровыми продуктами использует KMP, какие риски учитывают и какой видят от этого эффект.
Можно ли оставить всё как есть?
Можно. Многие компании годами поддерживают нативные приложения за счёт поверхностного рефакторинга. Но со временем накапливаются издержки.
Растет стоимость изменений. Каждая новая функция требует реализации и тестирования для обеих платформ, Android и iOS.
Есть расхождения в логике. Даже при синхронной работе команд бизнес-правила начинают отличаться.
Увеличивается технический долг. Без архитектурного обновления кодовая база усложняется, новые разработчики дольше погружаются в работу, а масштабирование становится дороже.
Есть более качественная альтернатива. Можно частично изменить технологический стек с помощью Kotlin Multiplatform, вынести общую бизнес-логику в единый слой и снизить стоимость владения приложением. Подробнее плюсы и минусы технологии мы рассматривали в этой статье.
С чего начинать модернизацию приложения на Kotlin Multiplatform
Миграцию лучше проводить постепенно, аккуратно встраивая в существующую архитектуру без остановки разработки.
При этом команды могут использовать KMP для разных сценариев: одни переносят существующую бизнес-логику в общий слой, другие изначально проектируют мультиплатформенное ядро для новой функциональности.
Этап 1. Настройка модуля Multiplatform, подключение к нативным приложениям.
Создание KMP-модуля — это выделение общего слоя бизнес-логики в отдельный компонент, независимый от Android и iOS. Такой модуль собирается через систему автоматической сборки Gradle и может находиться либо в том же репозитории, что и нативные части, либо в отдельном.
В Android-проекте он обычно используется напрямую как часть кодовой базы. Для iOS из него собирается нативный фреймворк, который затем подключается к проекту как зависимость.
Что это означает для команды:
Существующая архитектура Android- и iOS остается без изменений.
Для пользователя ничего не меняется.
Бизнес-логика постепенно переносится в общий слой.
Таким образом KMP-модуль начинает работать рядом с существующей архитектурой, а перенос бизнес-логики происходит постепенно, без необходимости переписывать приложение целиком.
Этап 2. Перемещение кода из Android-проекта в модуль Multiplatform
Начинают с тех частей системы, которые содержат повторяющуюся бизнес-логику на обеих платформах. При этом эти части не должны быть завязаны с UI или использовать специфичные платформенные API.
📌 Это правило в первую очередь относится к сценариям миграции существующего приложения, когда команды переносят в общий слой инфраструктурные и доменные компоненты. Если же в архитектуру изначально закладывалась возможность использования мультиплатформенного UI, например, при использовании BDUI, или команда планирует экспериментировать с Compose Multiplatform, то в общий слой могут попадать и элементы интерфейса. Но при миграции такие сценарии встречаются реже.
Как правило, в первую очередь переносят сетевые модули, бизнес-правила и доменную логику — именно в этих слоях чаще всего возникает дублирование и расхождения между платформами.
В нашей практике при разработке проекта для билетного оператора Kassir.ru общий KMP‑модуль применили для сетевого слоя. Даже при частичном использовании мультиплатформы эффект был виден: логика запросов стала единой, багфиксы и изменения в API больше не требовали двойной работы.
Этап 3. Интеграция кода в проект iOS и замена исходной реализации на Swift
Если iOS развивается отдельно, KMP подключают как внешний фреймворк. После компиляции модуль становится нативной библиотекой в формате XCFramework, который корректно работает с разными архитектурами.
Новая библиотека с KMP-логикой может подключаться через Swift Package Manager. Это позволяет фиксировать версии и обновлять общий слой без ручной сборки, например, с использованием платформ CL/CD. В итоге бизнес-логика управляется как обычная внешняя зависимость.
В наших проектах CI регулярно собирает XCFramework и публикует его в отдельном репозитории. Сборка может запускаться по расписанию или по мере накопления изменений. После добавления новых модулей или обновления KMP-кода зависимость в iOS-проекте обновляют, чтобы поддерживать стабильность сборки и не накапливать технический долг.
Этап 4. Миграция остальных модулей
После переноса пилотного модуля можно поэтапно переводить остальные части продукта. На каждом шаге можно выбрать самые удачные архитектурные решения.
Приложение продолжает развиваться в обычном режиме – без заморозки релизов и больших перемен для пользователей. К тому же плавная миграция снижает операционные риски и финансовую нагрузку. Вместо одного дорогостоящего обновления бизнес распределяет инвестиции на больший период времени, модернизирует систему частями без потери стабильности продукта.
Архитектура с мультиплатформенным ядром
Не все команды приходят к Kotlin Multiplatform через перенос или углубление существующей логики. В некоторых проектах мультиплатформенный слой проектируется сразу как часть новой архитектуры продукта.
Например, в AvitoTech Kotlin Multiplatform используют в BDUI-движке для кроссплатформенной части логики. Интерфейсы при этом остаются нативными и реализуются отдельно для Android, iOS и Web-платформ (MAV и Desktop).
BDUI не является полностью кроссплатформенным решением. В архитектуре изначально было заложено разделение слоя данных и расчета состояния (ядра) и слоя отображения — рендерера.
«На Kotlin Multiplatform мы решили делать именно ядро BDUI, а UI оставили нативным. Во-первых, хотелось сохранить look&feel каждой платформы и использовать ее дизайн-систему. Во-вторых, опыт других фреймворков показывает, что поддержка единого интерфейса для разных платформ требует значительных трудозатрат. Для нас эти риски были неприемлемы».
Андрей Колпаков
Android Engineer, AvitoTech
Взаимодействие ядра с рендерером у команды построено по принципам UDF-подхода. Интерфейс формируется на основе объектов состояния с простыми полями — цвет, расположение элементов, текст, вложенные контейнеры. В обратную сторону из нативного UI-слоя в ядро поступают события пользователя, которые также представлены простыми объектами. По опыту команды, чем проще такие структуры взаимодействия между ядром и рендерером, тем ниже вероятность скрытых архитектурных проблем.
«Несмотря на определённые сложности, мы полностью довольны решением пойти по кроссплатформенной реализации ядра, так как это действительно даёт скорость и синхронность реализации нового функционала, которую мы никогда бы не достигли, если бы работали параллельно для трёх платформ».
Андрей Колпаков
Android Engineer, AvitoTech
Риски внедрения KMP и как их контролируют
У некоторых зависимостей нет готовой версии для KMP
Иногда бизнес-логика оказывается завязана на платформенные API, либо в проекте используются библиотеки, у которых нет мультиплатформенной версии.
Как контролировать
Экосистема KMP закрывает типовые задачи уровня data/domain, такие как сеть, сериализация, база данных. В других случаях полностью переписывать существующую нативную часть необязательно — можно воспользоваться встроенными механизмами для использования нативной логики отдельно на Android и iOS.
«Например, на нашем финтех-проекте Moneon мы использовали мультиплатформенные библиотеки там, где это было возможно. А для платформо-специфичных функциональностей, которые нельзя перенести в общий код, применяли механизм самого KMP expect/actual.
Так, для работы со строковыми ресурсами в KMP определили общий контракт, а нативные приложения реализовали его на стороне платформ. Android и iOS передают в общий слой локализованные строки через собственные механизмы работы с ресурсами, после чего KMP-логика может использовать их через общий провайдер.
Если в проекте уже используется библиотека без мультиплатформенной версии, можно мигрировать на её KMP-аналог. Так, например в проекте Kassir.ru при переходе на KMP и новый API 2.0 команда отказалась от библиотеки Retrofit в пользу мультиплатформенной Ktor, а вместо Dagger 2 взяли Koin».
Мария Нестерова
iOS -разработчик, CleverPumpkin
Несогласованная работа iOS- и Android-команд
Когда Android- и iOS-разработчики взаимодействуют с KMP-модулем асинхронно или изолированно, есть риск рассинхронизации. Например, общее решение обновляется нерегулярно, архитектурные решения принимаются в одностороннем порядке, а критические части оказываются жёстко завязаны на удобство одной платформы.
Как контролировать
В своих проектах мы пришли к выводу, что KMP‑модули должны проектирова��ься и разрабатываться с участием обеих платформенных команд. На старте обсуждаем архитектуру, стейты и запросы. Так повышается качество решений, снижается количество спорных мест, модуль остаётся живым и масштабируемым.
Далее включаем ревьюеров с обеих платформ в каждый merge‑реквест. Таким образом заранее ловим нюансы, которые могли бы стать техническими конфликтами. Совместная работа экономит время компании и снимает большую часть интеграционных болей ещё на этапе проектирования.
«Для команд, которые постепенно мигрируют с нативной разработки на KMP, есть правило: новые фичи сразу реализуются на KMP для двух платформ.
По опыту работы с этой технологией могу сказать, что рабочим соотношением ресурсов в команде было «один iOS к трём Android». При этом соблюдалась последовательность разработки. Сначала Android, потом общий код могли переиспользовать в iOS разработке».
Дмитрий Алексеенков
Лид мобильной разработки, X5 Tech
Выбор неподходящего модуля для старта миграции
Часто компании на старте выносят в KMP слишком большой и критичный, либо слишком незначительный кусок приложения. В первом случае можно надолго увязнуть в переделке, во втором не получится оценить бизнес-эффект.
Как контролировать
Проанализировать архитектуру продукта и составить план. Для старта подойдет автономный модуль средней сложности. Это должна быть часть такого объема, чтобы было видно в��году от перехода. Но не настолько критичная, чтобы ставить под удар всё приложение.
«В Moneon мы сначала вынесли в общий слой отдельные бизнес-сценарии работы с локальной базой данных в качестве простых юзкейсов. Затем пошли дальше и объединили несколько операций закрытых юзкейсами в комплексные интеракторы, которые хранят актуальный state и управляют изменениями данных.
В нативной части остались слой адаптации под UI и реализация нативных особенностей. А вся логика общая - функции добавляются один раз, тестируются централизованно, и ведут себя одинаково на обеих платформах».
Мария Нестерова
iOS -разработчик, CleverPumpkin
Работа с Kotlin и мультиплатформенными инструментами для iOS-разработчиков
Интеграция KMP-модуля требует, чтобы iOS-разработчики не только использовали внешнюю библиотеку, но и понимали её структуру, API и поведение. На первых этапах это может вызывать трудности при чтении и отладке Kotlin-кода, особенно если раньше команда работала только с Swift или Objective-C.
Как контролировать
По возможности заложите время на обучение и эксперименты, если вы разрабатываете инхаус.
«На первом этапе стремимся максимально погружать iOS-разработчиков в Android-код, а Android-разработчиков - в iOS-код. Еженедельные встречи для обмена опытом, помощь в самых базовых вещах от специалиста на другой платформе. Пишем словарь для перевода важных терминов с iOS на Android».
Алексей Гребенец
Руководитель команды MM AppTech, MAGNIT OMNI
В практике CleverPumpkin команда iOS участвует в создании архитектуры, обсуждает формат данных, подход к состояниям, у неё появляется контроль и понимание общей логики.
«Иногда разработчику без iOS-бэкграунда приходится погружаться в особенности Swift. Или в особенности операционной системы и экосистемы App Store и Apple Developer, что на мой взгляд даже сложнее. Да и в процессах CI/CD между Android и iOS тоже мало общего. Но подобные сложности возникают сильно реже, и в большинстве случаев они решаются в начале жизни проекта».
Дмитрий Алексеенков
Лид мобильной разработки, X5 Tech
Можно привлечь аутсорс-специалистов, у которых уже есть опыт KMP-разработки и легаси-проектами, в роли тимлидов, архитекторов, сторонних консультантов. Они помогут выстроить процесс и менторить команду. В этом случае стоит заранее договориться о кодстайле, ревью-практиках и других стандартах, чтобы код был понятен всем участникам проекта.
Ожидание быстрых изменений
Бизнес рассчитывает уже через месяц сократить бюджет разработки вдвое. Надо быть готовым, что первые итерации могут потребовать дополнительных усилий на обучение и отладку процессов, особенно для команд без опыта кроссплатформенной разработки.
«Мы пока на ранней стадии и не все проходит гладко. Были проблемы, что перестройка под KMP ломала CI, были даже серьёзные креши на проде из-за того, что никто не привык работать с конкретной KMP- библиотекой. Когда разработчику приходится первые разы писать на не родной платформе, процесс естественно затягивается».
Алексей Гребенец
Руководитель команды MM AppTech, MAGNIT OMNI
Как контролировать
По нашему опыту, финансовый эффект KMP особенно заметен после переноса 20–30% бизнес-логики в общий слой и увеличивается в долгосрочной перспективе.
Да, внедрение новых инструментов может временно снизить скорость команды во время адаптации. Поэтому задача в первые месяцы миграции – удержать бюджет в контролируемых рамках и роста затрат из-за организационных ошибок.
Можно внедрить KMP силами текущей команды, если в команде есть Kotlin-разработчик. Если опыта кроссплатформенной архитектуры нет, можно подключить внешнего консультанта на ограниченный срок — это дешевле, чем исправлять архитектурные ошибки спустя время.
Почему KMP – это оптимальный путь для зрелых приложений
Kotlin Multiplatform позволяет модернизировать зрелые приложения без крупного рефакторинга. Команды могут постепенно выносить общую бизнес-логику в единый слой, сохраняя нативную работу на обеих платформах и стабильность продукта.
Технология позволяет обновлять архитектуру без остановки текущей разработки: продукт продолжает развиваться, а новая функциональность внедряется параллельно с модернизацией технологического стека.
Наибольший эффект KMP дает в проектах, где значительная часть бизнес-логики уже дублируется между платформами. В них общий слой логики сокращает объем повторной разработки и упрощает поддержку продуктов.
«У нас несколько мобильных команд и у каждой из них, в зависимости от задач, были разные триггеры. Одни – запускали новые проекты и искали более эффективную архитектурную модель. Другие – смотрели в сторону унификации. А для третьих – было полезнее мигрировать Android-only решения в кроссплатформенную модель.
Когда бизнес-логика, работа с сетью, валидация, правила расчётов реализованы дважды, расхождения почти неизбежны. А на уровне продуктовых команд, это скорость доставки новых фичей, уменьшение количества дефектов и единый релизный цикл.
Поэтому основной мотивацией было снижение дублирования логики и внутренняя синхронизация платформ. Экономический фактор тоже присутствовал, но он не был единственным. Мы стремились к более гибкому распределению экспертизы и уменьшению зависимости от конкретного решения».
Дмитрий Алексеенков
Лид мобильной разработки, X5 Tech
«Для начала эксперимента по KMP было сразу несколько мотивов. Удешевление поддержки (багфиксы для всех платформ сразу); стремление делать больше задач тем же количеством разработчиков, не расширяя бесконечно найм; согласованность данных и логики (одинаковая бизнес-логика и данные везде); согласованность аналитики (одинаковая разметка событиями поведенческой аналитики), упрощение тестирования (единые тест кейсы на все платформы)».
Алексей Гребенец
Руководитель команды MM AppTech, MAGNIT OMNI
«Смело могу сказать, что разработка ускорилась в два раза. Единая кодовая база для двух платформ – это не шутки».
Дмитрий Алексеенков
Лид мобильной разработки, X5 Tech
Если ваш продукт растёт, а поддержка легаси мешает развитию, есть возможность поэтапной модернизации через KMP. Напишите CleverPumpkin в Telegram, проконсультируем по процессам или подключимся к проекту на любом этапе — от аудита архитектуры до сопровождения. Поможем оценить экономический эффект внедрения и предложим реалистичный план перенесения проекта без остановки релизов.
Это блог CleverPumpkin. Создаём цифровые решения полного цикла — веб-сервисы, сайты, мобильные приложения и интеграции. На Хабре делимся опытом, рассказываем о проектах, технических сложностях и решениях, которые помогают бизнесу достигать целей.
