Ответ
Да, работал с KMM (Kotlin Multiplatform Mobile). Использовал для разделения бизнес-логики между Android и iOS. Основные модули — shared (общий код), androidApp, iosApp.
Пример:
// shared модуль
expect fun getPlatformName(): String
// Android реализация
actual fun getPlatformName() = "Android"
// iOS реализация (в iOS-модуле)
actual fun getPlatformName() = "iOS" Плюсы:
- Общий код для платформ
- Снижение дублирования
- Поддержка корутин, сериализации
Сложности:
- Ограниченный доступ к платформенным API
- Требуется настройка окружения для iOS
- Debug может быть сложнее
Использовал Ktor для сетевых запросов, SQLDelight для БД.
Ответ 18+ 🔞
Ну, смотри, KMM — это такая штука, когда ты пишешь бизнес-логику один раз, а потом она, как хитрая жопа, работает и на андроиде, и на айосе. В общем, ебать копать, идея-то вроде здравая.
Вот смотри, как это выглядит на практике. Берёшь и создаёшь модуль shared. Там пишешь код, который должен быть общим. А потом, ёпта, начинается самое интересное. Ты объявляешь функцию как expect — это типа обещание платформам. А потом в каждом родном модуле делаешь actual реализацию. Получается, что общая логика — одна, а доступ к нативным пизюлькам — у каждого свой.
Вот, например, простейший кусок кода, который я не трогаю, как ты и просил:
// shared модуль
expect fun getPlatformName(): String
// Android реализация
actual fun getPlatformName() = "Android"
// iOS реализация (в iOS-модуле)
actual fun getPlatformName() = "iOS" Видишь? В общем модуле мы ожидаем функцию, а на каждой платформе реально говорим, откуда мы. Красота, да?
Что хорошего? Ну, во-первых, овердохуища общего кода. Всю свою бизнес-логику, всю работу с данными, сетевые вызовы — всё это пишешь один раз. Не нужно плодить одни и те же баги в двух местах. Во-вторых, корутины из коробки, нормальная сериализация (Kotlinx.serialization). В общем, если проект не совсем уж мелкий, то выгода налицо.
А теперь про сложности, их тоже дохуя.
Первое и главное — доступ к платформенным API. Ты не можешь из общего кода просто так взять и позвонить, или камеру включить. Для этого надо городить эти expect/actual интерфейсы, что иногда превращается в отдельный геморрой. Второе — это настройка окружения под iOS. Тут, чувак, нужно, чтобы у тебя был мак, Xcode стоял и всё было правильно сконфигурировано. Иначе проект просто не соберётся, и будешь сидеть, как дурак. И третье — дебаг. На андроиде ещё куда ни шло, а вот чтобы пройтись отладчиком по коду, который выполняется на iOS-симуляторе... это надо быть немножко шаманом.
Из библиотек, которые реально спасают — Ktor для сетевухи (удобно, родное) и SQLDelight для базы. Последний вообще красавец — пишешь SQL-запросы, а он тебе типобезопасный код генерит. Не то что эти ORM-костыли.
В общем, инструмент мощный, но не серебряная пуля. Если у тебя команда знает Kotlin и готова потратить время на первоначальную настройку и пробивание граблей — то очень даже. Если же проект на коленке делается или там сплошная нативная специфика — то можно просто охуеть от количества костылей. Решай сам.