Постепенное внедрение в готовое приложение

KMP не требует переписывать приложение — его внедряют по кусочку, начиная с самого ценного слоя.

Постепенное внедрение (incremental adoption) — стратегия добавления KMP в существующие нативные приложения слой за слоем, без полного переписывания.

Почему это сильная сторона KMP

В отличие от Flutter/RN, переход на которые обычно означает новую кодовую базу UI, KMP внедряется поверх ваших нативных приложений. Вы оставляете весь существующий UI и архитектуру, а в общий модуль выносите один слой, подключаете его к Android и iOS — и получаете немедленную выгоду без риска переписать всё.

С чего начинать

Лучший первый кандидат — слой, который чисто детерминирован и сильнее всего дублируется. По убыванию ценности:

Сетевой слой и DTO: запросы и модели API одинаковы на обеих платформах — выносим первыми.
Доменная логика: валидация, расчёты, бизнес-правила.
Репозитории и кэш: объединяют сеть и БД.
Presentation (ViewModel): сложнее из-за интеропа состояния, но даёт максимум общего кода.

UI оставляют нативным до последнего (или навсегда, если не берёте Compose MP).

Технически: подключение модуля

Существующий Android-проект просто добавляет зависимость на общий модуль (это обычный Gradle-модуль). Существующий iOS-проект подключает собранный XCFramework. Дальше платформенный код начинает вызывать общие классы вместо своих старых реализаций — по одному месту за раз.

Было:  [Android: свой NetworkClient]   [iOS: свой APIClient]
Стало: [Android UI] --\                /-- [iOS UI]
                      [ shared: OrderApi, OrderRepository ]

Как работает под капотом

Поскольку общий модуль для Android — обычная JVM-библиотека, а для iOS — обычный фреймворк, интеграция не отличается от подключения любой сторонней зависимости. Нет рантайма-посредника, нет моста: общий код компилируется в тот же бинарник приложения (байткод на Android, нативный код на iOS). Поэтому внедрение безопасно: вы заменяете реализацию слоя, а интерфейсы взаимодействия с UI остаются прежними. Откатить тоже легко — вернуть старую платформенную реализацию.

Частые ошибки

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

Итоги

KMP внедряется поверх существующих приложений, без переписывания.
Начинают с сетевого и доменного слоя — самого дублируемого и детерминированного.
Android подключает модуль как Gradle-зависимость, iOS — как XCFramework.
Нет моста-посредника: общий код становится частью нативного бинарника.