Привет, это Максим Павлов— управляющий партнёр KTS. Мы создаём IT-продукты для бизнеса.
Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.
При переходе от нативной разработки к кроссплатформенной многие выбирают Flutter, мы выбрали KMP. Я поспрашивал у нашего руководителя мобильной разработки Максима Мялкина, почему мы выбрали его, а не попсовый 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 использовать не получится.
Честно, прям сильно не понял про невероятный Bluetooth, и проблемы с ним.
Мы используем сканеры Zebra, Honeywell, Urovo, в том числе с SDK от Honeywell, и всё отлично заводится и сканирует.
Доступ к нативной части приложения так же - не немыслимая вещь, ведь существуют MethodChannel.
Да, тут надо покопаться, если есть потребность идти в натив. Но, опять же, это необходимо чуть ли не единоразово для подключения и настройки. Далее - логика работы с данными, и тут уже вечеринка, с бизнес-требованиями и блэк джеком.
В плане ui - тоже не понял проблемы.
Вроде того, что кому-то надо на андроиде видеть стандартные виджет андроида, а на iOS - айосные?
Чё ж там с дизайнерами происходит? И почему бы не дать всем один внешний вид продукта, исходя от требований бизнеса, бренда, фирменного стиля, а не платформы?
Но тут, опять же, у всех свои потребности.
(Ну и не стоит забывать, что стандартные виджеты что Андрюши, что ИОС - лежат в самом флаттере в базе)
В плане того, что можно с Kotlin пильнуть приложку так же, и под ios, дорисовав интерфейс - клёво.
Но рассказывать про то, что flutter - не для бизнеса, тут не убедил.
p.s. На хакатоне вполне себе отлично заносили пакет Яндекса для работы с их картами. Да, там есть ограничения, в веб версии отказался заводиться.
Насчёт технических деталей попрошу ответить коллегу, насчёт интерфейса отвечу сам.
Если делать приложение для сотрудников и не нужно заботиться о привычности, то можно сделать и один интерфейс для обеих платформ.
Но если говорить про премиальных пользователей, то цель приложений обычно увеличить ценность основного продукта, например квартиры. Чтобы хорошо закрывать эту цель, интерфейс должен быть максимально привычен, без всякого "да вроде нормально, но что-то немного непривычно"
Без сарказма, действительно не понимаю, что именно ему не привычно в приложении, в котором можно купить квартиру?
Речь про системные иконки, строку поиска и т.д.?
Ради интереса зашёл в Телеграмм, Вотсапп, Авито и ВК, и иконки не повторились, если речь, опять же, о них.
На примере телеги: угловатость, поиск, привычные жесты и как интерфейс на них отзывается, всякие такие микровзаимодействия
Чем cupertino-вские и material виджеты не угодили во flutter? Помимо этого в VIP PREMIUM сервисах как любит автор дизайнеры обычно любят кастомный дизайн пилить, который как раз во flutter делается гораздо быстрее.
Так кастомный дизайн не равно одинаковый для iOS и Android. Понятное дело, что никто не делает интерфейсы на чистом Material и Cupertino без кастомизации, но основывается на них для каждой платформы. При этом фичи обычно одни и те же, фирменный стиль единый и так далее
И прошу вспомнить про упоминания compose, что говорит о том, что автор планирует тоже делать не нативные виджеты, привет skia от которой flutter отказывается. Синдром утенка на лицоб когда есть понимание, что пора переучиываться, но команда и лид не готовы.
Читайте внимательнее :)
Цитата из статьи:
"Да, конечно, во Flutter можно постараться и создать нативно выглядящий интерфейс под каждую платформу, а в KMP — использовать compose multiplatform, который позволяет делать единый интерфейс для обеих платформ. Но это скорее исключения из общепринятых подходов."
Вся статья про нативный интерфейс для каждой платформы + общая часть на KMP. Исключения бывают и я писал выше в комментах, что можно в целом использовать и Compose вместо Flutter, если очень хочется, но наилучший подход в сценариях, описанных в статье — это именно KMP с нативными интерфейсами
Вы написали так много комментариев о переобучении на Flutter и его превосходство над KMP, что кажется, будто вы испытываете подсознательный страх. Так сильно боитесь, что flatter уйдет на второй план?) Вы не волнуйтесь, переучитесь потом на KMP :)
Для начала, порекомендовал хотя бы научиться технологии правильно писать или английский язык подучить, в профессии полезно.
К KMP неприязни не испытываю и благо мой опыт нативной разработки и знания языка позволит не переучиваться, а только освежить знания.
Мало вероятно, что flutter уйдет когда-то на второй план, мы видим обратное. Помимо этого гугл сейчас львиную чатсь на развитие тратит.
Спасибо за рекомендацию)
У меня нет хейта в сторону KMM, самому было интересно поиграться, учитывая, что мне очень нравится kotlin как язык.
Но если автор разжигает холивар своим превью, почему бы и нет, в наше время терпимости к окружающим и технологиям не всегда есть такая возможность)
Помимо этого из дискуссии можно вынести моменты, где стоит углубить знания, сейчас на основе дискуссии стал изучать как у вас все под капотом на ios устроено в данный момент, в том числе compose.
Комментарий удален автором поста
Комментарий удален автором поста