KMP в корпоративной среде: о легаси, миграции и точечном применении

Kotlin Multiplatform (KMP) перестал быть технологией только для новых проектов. Компании с работающими мобильными приложениями всё чаще рассматривают его как способ сократить дублирование кода и снизить стоимость сопровождения. Директор Nord Clan Алексей Артамонов разбирает, когда такой переход оправдан, какие модули стоит переносить в общий код в первую очередь и что нужно изменить в процессах команды, чтобы технология заработала в реальных условиях.

Полная миграция: когда она имеет смысл

Крупные компании редко начинают мобильную разработку с нуля. Обычно уже существуют приложения, которые поддерживают несколько лет, десятки интеграций с корпоративными системами, собственные библиотеки и команды iOS и Android со сложившимися процессами.

В таких условиях вопрос звучит не «Стоит ли внедрить KMP?», а «Окупится ли переход в конкретном продукте?». Ответ зависит от того, какую проблему компания пытается решить. Если речь о дублировании бизнес-логики между платформами, высокой стоимости сопровождения или необходимости синхронно развивать несколько мобильных приложений — KMP может дать ощутимый эффект. Если же приложения уже стабильно работают, команды выстроили процессы, а объём общей логики относительно невелик — переход вряд ли оправдан.

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

Точечное внедрение: как получить эффект без полной перестройки

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

Точечное внедрение работает так: компания выбирает конкретные модули, где дублирование логики создаёт наибольшую нагрузку, и переносит их в общий код. Лучшие кандидаты для этого — модули бизнес-логики, работа с данными, сетевое взаимодействие, авторизация, расчёты и интеграции с корпоративными сервисами. Именно здесь эффект от переиспользования кода обычно максимальный, а зависимость от платформенных особенностей минимальная.

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

Какие ограничения есть у KMP

Несмотря на активное развитие экосистемы Kotlin Multiplatform, количество полноценных мультиплатформенных библиотек остается существенно меньше, чем для нативной Android- или iOS-разработки. При отсутствии KMP-аналогов команде приходится искать альтернативные библиотеки, писать собственные реализации или создавать платформенные обёртки. Это увеличивает стоимость разработки и сопровождения проекта

Одним из наиболее существенных ограничений является интеграция с библиотеками, написанными на Swift.

Kotlin/Native обеспечивает хорошую совместимость с Objective-C API, однако не поддерживает прямой импорт произвольных Swift-модулей. Если сторонняя библиотека распространяется только как Swift Framework и не предоставляет Objective-C интерфейс, использовать ее непосредственно из общего KMP-кода невозможно.

В таких случаях приходится либо создавать Objective-C-совместимую обёртку поверх Swift-кода, либо вызывать Swift-библиотеку исключительно из iOS-части приложения, не вынося соответствующую логику в общий модуль, либо полностью отказаться от использования библиотеки и искать альтернативное решение.

Подобные ограничения особенно заметны при работе с современными iOS SDK, многие из которых разрабатываются исключительно на Swift и используют возможности языка, недоступные через Objective-C (например, generics, async/await, property wrappers, Swift-only protocol requirements и другие особенности).

Таким образом, при миграции на KMP, стоит заранее анализировать возможный функционал приложения и выбирать более подходящие инструменты.

Как определить, что стоит делать общим

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

При проектировании каждого модуля стоит задать один вопрос: зависит ли эта логика от особенностей конкретной платформы? Если нет — кандидат на перенос в общий код. Обычно сюда попадают бизнес-правила, работа с данными, сетевые запросы, авторизация и интеграции с внешними сервисами. Если да — лучше оставить на платформенном уровне. Сюда относится всё, что связано с UI, взаимодействием с устройством и системными сервисами.

Хороший KMP-проект — это проект с правильно определёнными зонами ответственности, а не проект с максимальным объёмом общего кода. Компании, которые понимают это с самого начала, получают от технологии измеримый эффект. Те, кто пытается перенести в общий код всё подряд, со временем сталкиваются с архитектурой, которую сложнее поддерживать, чем две независимые нативные кодовые базы.