{"id":14289,"url":"\/distributions\/14289\/click?bit=1&hash=892464fe46102746d8d05914a41d0a54b0756f476a912469a2c12e8168d8a933","title":"\u041e\u0434\u0438\u043d \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u043b \u043f\u0440\u043e\u0434\u0430\u0436\u0438 \u043d\u0430 5%, \u0430 \u0441\u0440\u0435\u0434\u043d\u0438\u0439 \u0447\u0435\u043a \u2014 \u043d\u0430 20%","buttonText":"","imageUuid":""}

KMP vs Flutter: 4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter

Привет, это Максим Павлов— управляющий партнёр KTS. Мы создаём IT-продукты для бизнеса.

Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.

При переходе от нативной разработки к кроссплатформенной многие выбирают Flutter, мы выбрали KMP. Я поспрашивал у нашего руководителя мобильной разработки Максима Мялкина, почему мы выбрали его, а не попсовый Flutter — делюсь результатами.

Максим Мялкин 
Руководитель мобильной разработки KTS

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 использовать не получится.

0
89 комментариев
Написать комментарий...
Анатолий Пешков

0) Трижды были упомянуты "ограничения" про Flutter интерфейсы, например "мириться с ограничениями по дизайну". О каких ограничениях идет речь? В моем понимании ограничения это не возможность что-то сделать так как нужно. Будет интересно узнать что нельзя сделать на Flutter такого что будет выглядеть и работать так как задумано. Обратных примеров можно привести много, натив сильно ограничен стандартными компонентами

1) "Вы не хотите долго искать разработчиков" - тогда однозначно JS и React Native их уж точно больше чем нативщиков и с точки зрения работодателя выгоднее (в долгосрочной перспективе нет конечно - я тролю, все упрется в качество)

2) "Вам в приложении нужно использование блютуса" - именно этот кейс успешно прошли на Flutter, вообще проблем не возникло (для интересующихся скоро будет видео на ютуб канале Mad Brains)

3) "Вам важна нативность интерфейса" - у Яндекса на одной конфе даже был квиз-бот где нужно было угадывать натив это или Flutter. Пришлось учить скриншоты и перепроходить, так как это вообще не очевидно, если разработчик хочет сделать нативно на вид. Раньше был яркий признак - проблемный скролл, сейчас это пофиксили

4) "Вам важен плавный переход с нативного приложения" - вот тут пожалуй остановимся поподробнее. "Можно обучить iOS-разработчиков Kotlin" - ну допустим, заставим iOSников разбираться в перепетиях версионирования андроид компонентов, представим что они не взвоют от этого. "не нужно будет переписывать всё приложение с нуля" тут согласен. НО! "можно переписывать код по частям" - как вы собираете сборки под iOS на этапе когда проект лишь частично переписан. Я конечно понимаю что iOS нынче не в почете, но тут прям совсем грустно положеный болт на iOS-ников и iOS версию приложения.

P.S. 5) что там с версионированием компонентов и их совместимостью? Сколько времени тратится на обновление библиотек? У вас же серьезные бизнес приложения, они обычно долго живут и их нужно поддерживать, как с этим обстоят дела? ну и вопрос комьюнити в придачу (хоть и не сильно критично)

Ответить
Развернуть ветку
Максим Павлов
Автор

0) Ограничения по интерфейсу. Речь идет во-первых про ограничения, которые несут за собой флаттеровские виджеты, а во-вторых про ограничения, связанные с тем, что интерфейс один и тот же для обеих платформ. Мой коллега уже ответил выше по конкретике на тему интерфейсов https://vc.ru/services/877220-kmp-vs-flutter-4-scenariya-kogda-nuzhno-sdelat-stavku-na-kotlin-multiplatform-a-ne-flutter?comment=6576863&from=copylink

1) Скорость найма разработчиков. Реакт нейтив не рассматривали в статье в связи с тем как раз что вы написали — качество, если делать большое приложение. В качестве примера выше кидал Airbnb, которые даже решились с него съезжать https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a

2) Блютус. Пока без конкретики по вашему кейсу не могу что-то конкретное ответить. Про наш кейс писал коллега выше: одна из последних задач - автоматическое открытие дверей в момент приближения человека, у которого есть телефон с доступом. При этом приложение может не всегда быть запущено.

3) Неотличимость от натива. Наши сотрудники тоже были на той конфе и самый главный нюанс в том, что там были скриншоты и видео, а не рабочее приложение. Приложение тоже можно отшлифовать до "нативной" отзывчивости, но ценой гигантских усилий

Понятное дело, что Яндекс может вложить +/- сколько угодно сил в то, чтобы отшлифовать до состояния, когда выглядеть будет хорошо + они по сути переизобрели для себя все основные компоненты, не каждая компания может себе позволить вложить столько ресурсов в полную переработку всех компонентов

4) Переход с нативного приложения. Процитирую предложение полностью:
"Можно обучить iOS-разработчиков Kotlin или не обучать и оставить им только интерфейс и платформо-специфичные функции, такие как блютус.". Мы своих обучили и они не выли, если ваши воют или просто не хочется тратить лишнее время на обучение, то можно просто не обучать — просадки не будет

Версионирование компонентов. Иосерам не нужно знать версионирование андроид компонентов, потому что в кмп используются котлин зависимости, а версионирование стандартное major-minor-patch

Сборка проекта. KMP распространяется в виде библиотеки. Иосный проект может находиться совершенно в другом репозитории, соответственно подключение KMP части никак не затронет сборку

Так что никакого болта на иосников не положено, интерфейс на айосе нативный, максимально привычный, а логика переиспользована с андроида

5) Версионирование и совместимость. В любой технологии есть изменения не поддерживающие обратную совместимость. При обновлении флаттера и добавлении нулабельности например было несладко. За наш опыт не было проблем, когда приходилось что-то долго переделывать. Даже при изменении модели памяти KMP в ios изменения были несущественные.

Ответить
Развернуть ветку
Анатолий Пешков

0) Все равно звучит не убедительно про ограничения. По мне так наоборот свобода делать что хочется и как нужно. А вот в нативе как раз таки ограничений вагон и тележка. Стоит только вспомнить UISearchBar (прастихоспаде). А вот про единый интерфейс - вообще не правы, кто мешает их разделять и делать так как нужно на любой платформе (не только мобайл)? Да, будут условия в коде, но как по мне если бизнес требует - это сильно очевиднее и дешевле чем 2 отдельные кодовые базы для разных платформ
1) Да с RN все понятно, закапываем. Но аргумент с этой стороны что мол проще нанимать в корне не согласен. Хороших нативщиков днем с огнем искать, а уж тех кто желает в KMP тем более. Флаттер очень легок для входа, сами обучили уже достаточно много людей, в том числе через собственные курсы для начинающих. Опыт был и с нативными курсами, там все грустнее
2) ¯\_(ツ)_/¯
3) Понятное дело что отличия всегда можно найти. Но это не уровень RN или Cordova и тп. Для конечного пользователя разница будет не заметна в 99.99% А выгоды значительно больше. Про отдельные самописные компоненты у яндекса - думаю что на написание этих компонентов на нативе они потратили бы сильно больше времени. Тут возможность делать что-то не стандартное сразу на обе платформы сильно перевешивает условную "ненативность". по этому как по мне, аргумент слабоват
4) Ладно, может мне попадаются принципиальные iOS-еры ;)
Но вот с плавным переходом все таки не понял. То есть вы начинаете с выноса части логики в отдельные либы и подключаете их в существующий iOS проект? То есть вся бизнес-логика постепенно переезжает в набор (или одну большую) закрытую для iOS-ников библиотеку? Для однотипности подозреваю что и для андроида происходит что-то подобное. Звучит как сильное усложнение если вы это как-то скриптами не автоматизировали. Хотелось бы узнать подробнее как у вас это выглядит - пока звучит страшнова-то
5) Мои эксперименты с KMP все время упираются проблемы с версиями и совместимостью. Может что-то в последнее время поменялось, но было прям не приятно

Ответить
Развернуть ветку
Анатолий Пешков

Ну и в качестве завершения, чтобы не разводить холивар. Я не отрицаю что KMP интересный инструмент и у него есть большие перспективы. Но причина по которой решил докопаться кроется в кликбейтном утверждении "Я тебя переиграл и уничтожил" - весомое заявление, подкрепленное только субъективными положительными аргументами, вес которых я попытался снизить сравнив их с альтернативой. Аргументация очень не объективна, что мешает воспринимать всерьез даже заявление "когда нужно сделать ставку на Kotlin Multiplatform" - не убедительно

Ответить
Развернуть ветку
Георгий Хромченко

Статья 2018 года от AirBNB разобрана по косточкам и по моему осталась только как аргумент в спорах когда не хочется анализировать почему у них не получилось. Основная их проблема в том, что они по сути добавили третью платформу к двум нативным аппам ради нескольких экранов, а не стали писать на RN один кросс-платформенный апп.

А вот Coinbase и Shopify наоборот сделали основную ставку на RN и все у них хорошо.

Ответить
Развернуть ветку
86 комментариев
Раскрывать всегда