Привет, это Максим Мялкин — управляющий партнёр и руководитель мобильной разработки KTS.
Кроссплатформенные- инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.
Kotlin Multiplatform (KMP) — раньше был известен еще как Kotlin Multiplatform Mobile (KMM).
Кратко про KMP
KMP — это технология, которая помогает разработчикам переиспользовать общий код на языке Kotlin в обеих версиях мобильного приложения: для iOS и Android. KMP разработали в компании Jetbrains, которая сделала язык Kotlin — основной язык разработки приложений под Android.
Приложение на Kotlin Multiplatform состоит из трех частей:
общего кода, который описывает логику сразу для двух платформ,
кода интерфейс под iOS,
кода интерфейс под Android.
Простой пример, как выглядят эти части в реальности: представьте, вам нужно разработать приложение с регистрацией.
У вас будет интерфейс (отдельно под Android, отдельно под iOS), причем довольно простой: два поля ввода, кнопка «далее» и место для ввода кода из SMS.
При этом, за таким простым интерфейсом будет скрываться и своя логика: таймер, который отсчитывает время отправки кода, правила, по которым его нужно отправлять — это будет общий код, одинаковый и для iOS, и для Android.
Кратко про Flutter
Flutter — это более популярный кроссплатформенный фреймворк.
Главная особенность Flutter заключается в использовании одной кодовой базы на языке Dart вместо нескольких для Android и iOS платформ.
То есть, тогда как KMP фокусируется на бизнес-логике и позволяет использовать нативные инструменты каждой платформы для создания пользовательского интерфейса, Flutter предоставляет собственную систему виджетов для создания UI, которая позволяет создавать единый пользовательский интерфейс для всех платформ.
4 сценария, когда вам подойдет KMP
Выбор Flutter может быть предпочтительным, если вам нужно разработать приложение в короткие сроки и вы готовы мириться с ограничениями по дизайну. Согласно данным Surf, разработка на Flutter экономит до 40% времени по сравнению с нативной, тогда как у KMP этот показатель у нас в KTS варьируется между 20-25%.
Однако есть ситуации, когда стоит сделать выбор в пользу KMP.
#1. Вы не хотите долго искать разработчиков
Для работы на Flutter требуется знание языка программирования Dart. Разработчиков на Flutter тяжело найти на рынке — по данным того же hh.ru, сейчас их всего 1877 человек в России. Вы, конечно, можете нанять обычных Android- и iOS-разработчиков, но тогда надо будет потратить время на их переучивание. Без этого они и строчки не напишут.
Для работы на KMP не нужны «специальные» разработчики. KMP требует знание языка Kotlin, а значит вам подойдёт любой Android-разработчик: их, в настоящее время, по данным hh.ru, на рынке более 29 тысяч человек.
Если говорить про iOS-разработчиков, то iOS-интерфейс для KMP-приложений они могут сделать, не изучая KMP. Если вы хотите, чтобы помимо интерфейса, они смогли разработать еще и логику, то нужно закладывать от одного до четырех месяцев на их погружение в KMP с нуля. Но вы можете этого не делать и оставить реализацию логики Android-разработчику.
#2. Вам в приложении нужно использование блютуса, приём звонков и другие нативные фичи
Поскольку Flutter работает с языком Dart, то для настройки интеграции с нативными фичами — звонками или блютусом — придётся разрабатывать бриджи. Это механизмы, которые обеспечивают связь между нативным кодом, который сможет работать с этими фичами, и кроссплатформенным кодом на Dart.
В KMP же эта функция реализована нативно, следовательно SDK от производителя оборудования легко подключить. В итоге вы можете быстрее настроить интеграцию.
Как это реализуется на практике, можно посмотреть в нашем разборе мобильного приложения для управляющей компании застройщика Мангазея. Там мы написали приложение на KMP и без труда подключили в приложение модуль, который поставляет производитель домофонов.
#3. Вам важна нативность интерфейса
Flutter обеспечивает высокую скорость разработки, но в нём больше ограничений, которые накладываются на реализацию интерфейса. В KMP меньше ограничений, но создание интерфейсов занимает больше времени.
Да, конечно, во Flutter можно постараться и создать нативно выглядящий интерфейс под каждую платформу, а в KMP — использовать compose multiplatform, который позволяет делать единый интерфейс для обеих платформ. Но это скорее исключения из общепринятых подходов.
Вывод: если вам важен максимально нативный интерфейс для пользователей платформы или вы стремитесь сделать премиальный продукт, то выбирайте KMP.
#4. Вам важен плавный переход с нативного приложения
Как я и сказал выше, вам не придётся обучать всех разработчиков новому языку. Можно обучить iOS-разработчиков Kotlin или не обучать и оставить им только интерфейс и платформо-специфичные функции, такие как блютус.
Также KMP — подходящий вариант, так как вам не нужно будет переписывать всё приложение с нуля, как того потребует Flutter.
На KMP можно переписывать код по частям, начиная с модулей, которые планируется развивать и чаще дорабатывать, и в которых есть общая логика.
Пример: у вас уже есть два нативных приложения. Вы можете встроить новые экраны, которые написаны на KMP, в старые приложения без необходимости переписывать весь апп. Следовательно, вам не нужно инвестировать много времени в переезд на KMP.
Кто и почему использует КМР
Сейчас KMP используют Avito, Google, Netflix и Тинькофф. Число компаний, которые его используют, растет с каждым годом.
Мы в KTS выбрали КМР по 3 критериям:
нет ограничений на реализацию интерфейсов — они нативны
простота подбора команды: используем тех же Android-разработчиков, что уже работают в штате над другими проектами, а iOS-специалистов быстро доучиваем
экономия денег клиентов: большая часть наших проектов связана с бизнес-приложениями, в которых логика занимает основную часть разработки
Если совсем коротко
Flutter — это решение для быстрого запуска небольшого продукта в том случае, если вы готовы мириться с ограничениями готовых компонентов.
Однако если у вас:
премиальный продукт и вы хотите повысить комфорт пользователя,
есть планы нанять разработчиков в штат
в команде есть готовые разработчики на Android и iOS,
уже есть нативное приложение,
вам нужно использование блютуса, приём звонков и другие нативные фичи,
то лучше использовать KMP, позволяющий создать максимально привычный интерфейс.
Кроме того, некоторые проекты, которые основываются на картах, либо имеют движок карт, имеют свои ограничения и требуют нативных элементов каждой платформы, поэтому при работе с ними Flutter использовать не получится.
Комментарии (19)
Krat0S
13.10.2023 10:17+7Для работы на Flutter требуется знание языка программирования Dart. Разработчиков на Flutter тяжело найти на рынке — по данным того же hh.ru, сейчас их всего 1877 человек в России. Вы, конечно, можете нанять обычных Android- и iOS-разработчиков, но тогда надо будет потратить время на их переучивание. Без этого они и строчки не напишут.
Так всё просто, ищите фронтендеров, пишущих под реактивные фреймворки. Особенно под тайпскриптом. Цена доучивания будет копеечная.
Поскольку Flutter работает с языком Dart, то для настройки интеграции с нативными фичами — звонками или блютусом — придётся разрабатывать бриджи.
Забыли упомянуть, что бриджи под 99.99% функционала давно уже написаны сообществом.
В KMP же эта функция реализована нативно, следовательно SDK от производителя оборудования легко подключить. В итоге вы можете быстрее настроить интеграцию.
Ага, AirWatch, или как он там щас называется, подключите))
Да, конечно, во Flutter можно постараться и создать нативно выглядящий интерфейс под каждую платформу
Не можно, а нужно. Благо, что все элементы интерфейса, как Android, так и iOS, давным давно реализованы. И при этом вам, в большинстве случаев, не придётся писать ДВА интерфейса.
Как я и сказал выше, вам не придётся обучать всех разработчиков новому языку. Можно обучить iOS-разработчиков Kotlin или не обучать и оставить им только интерфейс и платформо-специфичные функции, такие как блютус.
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
И в конце куча выводов, сделанных на неверных исходных данных.
Ну ок :)
Neikist
13.10.2023 10:17+2Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
Сильно спорно. Особенно если кроме интерфейса в приложении есть что то еще. Любому кроссплатформенному разрабу нужно знать обе платформы под которые он пишет, имхо. Пусть не прям глубоко - но основы на уровне джуна точно, плюс нюансы некоторые которые только с опытом приходят.
Ага, AirWatch, или как он там щас называется, подключите))
Да вроде нормально подключаться должно. Просто expect/actual + в абстракции все заворачивать. Но да, местами менее удобно будет чем писать на чистом KMP. Впрочем AirWatch сам по себе шляпа та еще. Помню с вами пересекались на эту тему лет 5 назад.
В общем флаттер я поковырял для себя, и понял что пока предпочел бы котлин. Про KMP как раз возможно в свободное время займусь постепенным переносом частей кода на него в приложении над которым работаю. Немного поковырял - придется конечно что то выкинуть/заменить, что то переписать, но переиспользование неплохое получится когда приступим к разработке версии под ios.
Krat0S
13.10.2023 10:17Любому кроссплатформенному разрабу нужно знать обе платформы под которые он пишет, имхо
Но согласитесь, это несколько отличается от необходимости держать разработчиков под две платформы, чисто ради написания интерфейсов (что, кстати, весьма немалая часть приложения).
Да, Flutter-разработчик должен понимать основы работы обеих платформ и их нюансы, влияющие на работу приложения. Но это совсем не те же знания, которые надо для разработки серьёзного нативного интерфейса.Помню с вами пересекались на эту тему лет 5 назад
Я тоже помню))
MAX1993M Автор
13.10.2023 10:17+3Так всё просто, ищите фронтендеров, пишущих под реактивные фреймворки. Особенно под тайпскриптом. Цена доучивания будет копеечная.
Вы замеряли это или может есть открытая статистика? У нас был негативный опыт погружения react-разработчиков в кроссплатформу, давно и на RN правда. В крупных компаниях, которые разрабатывают на флаттер и имеют большое количество разработчиков, это оправданно, тк в команде есть специалисты с опытом в мобильных приложениях. Если же людей мало, то вы всегда будете находиться в ситуации с рисками недостатка платформенной экспертизы.
Благо, что все элементы интерфейса, как Android, так и iOS, давным давно реализованы.
Реализованные виджеты не всегда ведут себя так, как на платформе.
Для примеров можно открыть тысячи issue платформ ios и android. Некоторые из них кажутся незначительными. Но есть и глобальные, например: 1, 2, 3 .
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
По обучению - если в команде есть специалисты Android и iOS, то общую часть может начинать Android без дополнительного обучения (заменяются только библиотеки некоторые). Нативные iOS-разработчики после Swift достаточно быстро въезжают в Kotlin, особенно, когда приходят на уже готовый проект.
Единственный разработчик - это идеальная картина кроссплатформенных фреймворков, которая может работать для простых приложений на начальном этапе, до тех пор, пока не придется залезть в нативную часть из-за бага, нюанса платформы или пока приложение не вырастет.
ReyzoR
13.10.2023 10:17Так всё просто, ищите фронтендеров, пишущих под реактивные фреймворки. Особенно под тайпскриптом. Цена доучивания будет копеечная.
Ага, и напишут они столько всего, что потом расхлебывать будете. Мобильному разработчику очень много думать нужно про то, что веб разраб не задумывается. Это нужно будет разрабу ломать шаблон мышления.
Забыли упомянуть, что бриджи под 99.99% функционала давно уже написаны сообществом.
Ага, и качество у них соответствующее. Баги если найдете и либа не сильно популярная - фисите сами, и дай бог овнер примит пуллреквест, иначе - будете жить с форком и меть геморой с подливом "мастера".
Как интересно, а для разработки на Flutter, вообще не требуется держать специалистов по двум платформам.
Значит у вас не было сложного приложения с нативными функциями. У меня был такой опыт, очень и очень грустно когда нету специалиста под платформу. А просто лезть в незнакомые дебри - не продуктивно и кучу времени сьедает.
itmind
13.10.2023 10:17+7Есть у меня нативное приложение под android (compose). Получает данные с сервера, отображает, хранит данные в sqlite и делает бэкап в хранилище. Решил сделать его кросплатформенным: android+iOS+desktop+wasm. Выбирал между kmp и flutter. На Хабре топят за kmp, выбрал его (точнее compose multiplatform). И... Ничего быстро не получилось. В процессе выяснилось, что используемые мной сторонние compose библиотеки собраны только под android, а под compose multiplatform даже аналогов нет, нужно писать с нуля. Работа с файлами, получение разрешений, открытие диалогов открытия/сохранения файлов находится в composable функциях (т. к. это интерфейс) и это нельзя шарить между платформами, нужно под каждую писать свою реализацию, свои экраны. На это уйдёт много времени и по сути это как дублирование кода. Еще неизвестно с какими проблемами придется столкнуться под web.
Таким образом выбор kmp в разы увеличил время разработки, требует навыков разработки под ios. (Приложение пишу я один). Поэтому мне пока не понятны восхищённые отзывы об kmp. И теперь опять перед выбором: писать все с нуля и долго на kmp (всетаки как язык Kotlin нравится) или перейти на flutter и быстро получить результат под все платформы...
А довод про поиск разработчиков считаю невереным. Для разработки на flutter нужен один разработчик, для kmp два. Это же дороже в два раза. При этом сам язык Dart проще Kotlin, его изучить можно за пару дней (естественно имея базу из Си подобных языков).
Devchik
13.10.2023 10:17+1В конце статьи написано, когда стоит выбрать Flutter или KMP.
Мне лично KMP очень нравится и я к нему привык, compose multiplatform так вообще один в один с jetpack compose и библиотеки можно практически без изменений копипастить. И надо понимать, что compose multiplatform еще сырой и поддержка ios только недвано появилась, поэтому необходимым либ мало совсем .
На счет разрешений, файлов и другого, можно без особого труда решить проблему через expect/actual и все будет отлично шариться. Да, что-то надо реализовать самому пока, но со временем появятся готовые либы, как это было с flutter. (возможно уже какие то либы есть из перечисленных, для файлов думаю точно должно быть что-то)
Короче через какое то время будет все супер и даже лучше
Вот полезная репа с kmp библиотеками и там есть для файлов и разрешений (но я ими не пользовался, поэтому не могу ничего сказать)
MAX1993M Автор
13.10.2023 10:17+2Спасибо за описание своего опыта!
Насчет наличия библиотек - выше подметили репозиторий с kmp-библиотеками. Он часто обновляется. В частности там есть библиотека для работы с пермишнами.
По невозможности шарить composable-функции между платформами - не очень понял. Есть официальные примеры, в этом же и суть.
Наличие библиотек только под android в compose понятно - пока именно compose-multiplatform развивается. И все библиотеки не будут моментально адаптированы сообществом. Нужно ждать беты и стейблы.
Про разработчиков писал в комментах выше. Нужно мерять не только простоту языка, но и его удобство, лаконичность, чтобы язык не ставил палки в колеса. Для разработчика с опытом и желанием не будет проблемой въехать в любой из высокоуровневых языков общего назначения. Swift и Kotlin достаточно похожы, поэтому в нашей команде ios-разработчики вкатываются быстро.
Кстати, наш android-разработчик в качестве pet-проекта разрабатывает приложение на compose-multiplatform (android, desktop, ios) без наличия опыта ios-разработки.
И эта статья не про восхищенный отзыв, а про сравнение 2 фреймворков через призму нашего опыта)
gev
13.10.2023 10:17Jetpack Multiplatform для iOS использует skia, как и Flutter, до недавнего времени. В чем принципиалная разница? виджеты для iOS ненативные и там и там.
MAX1993M Автор
13.10.2023 10:17Все верно, использует skia. Но kmp позволяет не делать интерфейс через jetpack multiplatform. Вы в своем праве шарить только то, что вам нужно в проекте.
Даже есть эксперимент создания ui на flutter с общей логикой на kmp))
lil_master
13.10.2023 10:17+1Вам в приложении нужно использование блютуса, приём звонков и другие нативные фичи
Это давным давно не проблема. Можно использовать Platform Channels.
Как я и сказал выше, вам не придётся обучать всех разработчиков новому языку. Можно обучить iOS-разработчиков Kotlin
А с Виндовс разработчиками что делать? Flutter поддерживает 6 платформ, а не только мобильные. + также можно писать модули для андроида на котлине, а модули для айос на свифте.
То что вы написали в статье - это ваше мнение, основанное на вашем опыте, в этот опыт не входит хорошее знание Flutter.
MAX1993M Автор
13.10.2023 10:17Что kmp, что compose multiplatform поддерживают разработку для windows. Но будем честны, остальные платформы - это скорее бонус, а не необходимость.
lil_master
13.10.2023 10:17Забыли упомянуть, что бриджи под 99.99% функционала давно уже написаны сообществом.
Кстати да, абсолютно верно.
TDMNS
13.10.2023 10:17+1Я бы еще добавил #5. Может я не правильно понял п. #3 но все же внесу свои 5 копеек.
У любого бизнеса могут быть разные задачи, и соответственно может быть разный дизайн под разные платформы. Таким образом, если дизайн будет розниться на том же iOS и Android (да, редко... но такое бывает), то смысла рассматривать Flutter совсем нет (по моему мнению), иначе дело заканчивается лютейшими костылями со стороны Flutter. Мне кажется это один из ключевых пунктов, по которому стоит рассматривать KMP, в качестве кросс платформы.
Всех благ! Статья понравилась.
Algrinn
Ещё React Native есть. В целом, идея писать всё на Котлине выглядит перспективно. После того, как Android разработчики предали язык Java и перешли на Kotlin, сложилась такая ситуация, что сервер на Java, Android на Kotlin, а ios на Swift. Было бы хорошо их всех перевести на Kotlin. Тогда можно получить хорошую монолитную команду разработчиков.
acsent1
Единый язык не означает, что можно будет легко с сервера переключиться на мобилы. Да даже в рамках одного языка-платформы разные фреймворки имеют существенную разницу и необходимо доучиваться. Например react-angular
Format-X22
На JS уже изобретено - сайт, iOS, Android, Windows (и электрон, и WinUI нативно, и джей скрипт), Linux (и даже NodeOS), MacOS, FreeBSD, СмартТВ (и веб, и с вендорными вставками), терминал, бекенд, база данных (MongoDB нативно исполняет JS), голое железо (через кросскомпиляторы, и не только ардуино), блокчейн, облачные функции, прикладные функции энтерпрайз софта, и я не удивлюсь если где-то на JS работает кофеварка. И вот вам и интерфейсы, и толстые и тонкие клиенты, под всё это бекенды с базой, на телике показать и, в случае особых потребностей, извратится во всех сферах где можно запустить код. И нужны только JS разработчики и ты властелин мира.
Идея не нова - уже была в Java с виртуалкой на всё что имеет хоть какой процессор, даже на пластиковые карты. Да и С++ так то многое позволяет.
Только вот во всех технологиях сразу чтобы подовсё есть нюансы…