Ограничения и подводные камни

Где KMP реально болит — чтобы решение внедрять было осознанным, а не по хайпу.

Подводные камни KMP — практические трудности, не видные из туториалов: отладка Kotlin на iOS, размер артефакта, шероховатости интеропа и зрелость части библиотек.

Отладка на iOS

Отлаживать Kotlin-код, исполняемый внутри iOS-приложения, сложнее, чем на Android. Стек-трейсы при крашах в Kotlin/Native бывают менее читаемыми; брейкпоинты в Kotlin из Xcode работают, но не так гладко, как в Android Studio. Команды решают это логированием на границе и тестами общего кода, чтобы ловить баги до iOS.

Размер артефакта

Kotlin/Native-фреймворк добавляет к iOS-приложению вес: рантайм Kotlin и общий код увеличивают размер бинарника. Для большинства приложений это приемлемо, но если вес критичен, это фактор. На Android прирост обычно меньше, так как Kotlin там и так используется.

Шероховатости интеропа

Мы уже видели: дженерики, sealed-классы и Flow маппятся в Swift неидеально. Без инструментов вроде SKIE интероп местами неудобен, а sealed-классы теряют исчерпываемость в Swift switch. Это требует дисциплины при проектировании публичного API.

Зрелость библиотек

ЗрелоеРазвивается
Ktor, kotlinx.serialization, корутиныCompose MP на web (Wasm)
SQLDelight, Koinчасть нишевых платформенных библиотек

Ядро экосистемы готово к проду, но под конкретную платформенную задачу мультиплатформенной библиотеки может не оказаться — тогда пишете expect/actual сами.

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

Многие трудности упираются в Objective-C как «общий знаменатель» интеропа и в относительную молодость Kotlin/Native по сравнению с JVM. JVM-экосистеме десятилетия, инструменты вылизаны; Kotlin/Native моложе, поэтому отладка, профилирование и часть инструментов отстают. Размер артефакта — следствие того, что нативный рантайм Kotlin приходится упаковывать в приложение, тогда как на Android он уже есть в системе. Понимание этих корней помогает не удивляться, а планировать обходные пути.

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

Ожидать, что iOS-опыт будет таким же гладким, как Android — он догоняет, но пока нет. Вторая ошибка — игнорировать вес фреймворка в чувствительных к размеру приложениях. Третья — выбирать KMP под задачу, где UI-шеринг важнее (тогда Flutter уместнее), или где нет нужных мультиплатформенных библиотек.

Итоги

  • Отладка Kotlin на iOS менее гладкая, чем на Android — компенсируют тестами и логами.
  • Фреймворк добавляет вес iOS-бинарнику.
  • Интероп со Swift местами шероховат; инструменты вроде SKIE помогают.
  • Ядро экосистемы зрелое, но не под всякую платформенную задачу есть готовая библиотека.
Проверьте себя
1. Какой из пунктов — реальный подводный камень KMP?
AНевозможность писать на Kotlin
BОтладка Kotlin на iOS менее гладкая и фреймворк добавляет вес бинарнику
CОтсутствие поддержки Android
DОбязательный JavaScript
2. Что из перечисленного считается зрелым в экосистеме KMP?
ACompose MP на web (Wasm)
BKtor, kotlinx.serialization, корутины, SQLDelight
CВсе нишевые платформенные библиотеки
DНичего