Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.
За 20 лет в ИТ могу сказать что трудозатраты на разработку UI всегда недооценивают и в общем объеме проекта они и съедают огромное количество человеко-часов и в основой части проекта и в последующем развитии и исправлении дефектов. А то что называют весомым словосочетанием "бизнес-логика" обычно делается относительно легко и в предсказуемые сроки в общем-то на любом языке. И я сейчас не только про простенькие приложения, но и про суровые Enterprise системы для большого бизнеса.
Поэтому необходимость дважды пилить UI считаю серьезным недостатком KMP.
Однако, спасибо за обзор, это очень полезно знать.
Под “бизнес-логикой” люди часто понимают разное. И в KMP действительно можно выносить в кроссплатформу разные части, по потребности. В статье мы не стали раскрывать что именно туда входит, тк не хотели закапываться в технику, но кратко опишу тут.
Кто-то в KMP выносит только логику работы с данными, а кто-то всю логику: презентационную, доменную, логику работы с источниками данных. Более детально можно посмотреть в опросе от JB (https://blog.jetbrains.com/kotlin/2021/10/multiplatform-survey-q1-q2-2021/). В наших проектах мы идем по второму пути, и поэтому из KMP-части прилетает только UiState, который нужно отрисовать на UI на платформах и передать из платформ в KMP событие от пользователя. Так получается достичь большего переиспользования.
В основном мы как раз делаем приложения для бизнесов, в которых часто разработка интерфейса занимает либо меньше, либо столько же, сколько тратится на логику, всякие синхронизации с сервером, локальное хранение.
Поэтому эффект действительно ощутимый и для клиентов важна возможность сделать интерфейс нативным для пользователей каждой платформы
Но для кейсов где требований к нативности нет, можно использовать compose multiplatform