Привет, это Максим Павлов— управляющий партнёр 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 использовать не получится.
За 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
Каждый из этих пунктов бред.
1. По опыту ищутся они также как и другие кодеры. Нам не нужен отряд разрабов, нам нужны 1-5 хороших
2. Для любой нативной фичи есть готовые пакеты, за 3 года работы с флаттером я ни разу не был в ситуации, где мне требовалось бы что-то писать ручками на нативе, обертки на дарте есть для всего.
3. Флаттеровские виджеты сейчас выглядят абсолютно также также, как и нативные. Может раньше и были еле заметные отклонения в анимациях с айосом, но сейчас даже их нет
4. Мне интересно посмотреть на разработчиков, которые на мидл/сеньор позиции на нативе пойдут учить флаттер. Далеко не каждый джун на такое пойдет. Для переписывания на другой язык/фреймворк нанимают людей, которые уже умеют на нем писать. А истории по типу где ты и швец, и жнец, обычно в компаниях, где весь айти отдел это полтора человека, думаю даже рассматривать смысла нет. Плавный переход кстати тоже осуществляется без проблем, такие кейсы тоже есть.
Итого что имеем. Если у вас мало интерфейса, но много логики, нужно брать кмп. Но по такой же логике можно брать хоть c++ разрабов, их на рынке на порядок больше айосов и андроидов вместе взятых.
Мое негодование вызвано тем, что чтобы показать кмп в лучшем свете зачем то приводят бредовые аргументы сравнивая с флаттером. Зачем говорить, что кмп переиграл и уничтожил флаттер? Вы сами сказали, что на флаттере экономия 40 процентов, а у вас 20-25. Хотя по опыту экономия 60-80.
Итого получается совершенно обратная ситуация, за исключением совсем спецефичных моментов флаттер переигрывает и уничтожает кмп, а не наоборот
UPD: на счет премиальности. Существует огромное количество "премиальных" приложений на флаттере. Так же как и для крупного бизнеса. Так что утверждение что он только для пет проектов и стартапов тоже бред
Комментарий недоступен
1. Опыт найма лично вами одного или 5 в разные моменты времени не опровергает факта, что их просто меньше в 2.5 раза. Из этой пропорции следует что нанять их при прочих равных сложнее.
2. На сколько сложные фичи с нативными штуками вам приходилось делать? В статье четко написано, что речь про глубокую работу с нативными фичами. Если делать приложения для рынка, в котором не требуется глубокая работа с нативкой, то даже за долгое время можно так и не столкнуться с ситуацией, в которой требуется что-то написать руками
3. Касаемо виджетов - реализованные виджеты не всегда ведут себя так, как на платформе.
Для примеров можно открыть тысячи issue платформ ios и android (https://github.com/flutter/flutter/issues?q=is%3Aopen+label%3Aplatform-ios%2Cplatform-android+). Некоторые из проблем кажутся незначительными. Но есть и глобальные, например: 1(https://github.com/flutter/flutter/issues/82906), 2(https://www.reddit.com/r/FlutterDev/comments/yywx66/attn_all_your_vote_is_needed_to_fix_critical/), 3(https://www.reddit.com/r/FlutterDev/comments/1140pdv/two_years_later_flutters_biggest_problem/)
4. Нативных разработчиков имеет смысл пересаживать на KMP, потому что можно ощутимо сэкономить не переучиваясь.
Можно сохранить команду, которая уже в курсе всех деталей бизнеса, но при этом сэкономить в деньгах и скорости
5. Если мало интерфейса, но много логики действительно лучше брать KMP. C++ разрабы не сравнятся в скорости разработки с разрабами на Kotlin и swift, на сколько бы много их не было
6. Премиальность. В статье описаны причины и аргументы, почему премиальные приложения лучше делать с нативными интерфейсами. Факт, что кто-то делает их на флаттере / реакт нейтиве / ксамарине не опровергает этот аргумент
P. S. Ну а переиграл и уничтожил - это мэм такой, а суть чётко описана в заголовке - 4 сценария, когда kmp лучше флаттера
Из всей статьи можно сделать вывод, KMP нужен только в том случае, когда у вас уже есть команда нативщиков, а заказчики их не хотят брать, потому как дорого, а изучать новую технологию они не хотят. Все остальное из пальца высосано, помимо этого автор не рассказал о мешке проблем, с которыми столкнулись при использовании KMP в проде, а не для pet проектов.
А, ну и 4й тот, который вы сами увидели - уже есть нативное приложение и готовая команда, которую вы не хотите переучивать на новую технологию
Вы как-то невнимательно читали:)
Вывода 4:
1. Главный вывод: если заказчик хочет сделать не одноразовое мини-приложение, а развивать его и наращивать команду разработчиков наймом с рынка, в том числе в будущем собирать команду на своей стороне, то нужно использовать KMP. Иначе - выбирать придётся среди 1900 людей в России или ждать, пока новые сотрудники обучатся
2. Если приложение не просто визитка или какой-то новостной сервис, а например прил для управляющей компании с интеграциями по блютусу, NFC, приёмом вызовов и так далее, то лучше использовать KMP
3. Если прил для премиальной аудитории и интерфейс должен выглядеть максимально нативно, то на KMP это будет сделать проще
Ну а мешка проблем-то и нет, мы его уже 2 года примерно в проде используем
это какие?
максимально нативный интерфейсKMP умеет в нативный интерфейс на ios?
Если действовать по классическому пути, на флаттере интерфейс строится на основе виджетов.
Основной профит этих виджетов как раз в том, что интерфейс делается 1 раз, сразу под обе платфомы. Это и несёт в себе ограничения - виджеты выглядят норм, но не нативно
Да, KMP умеет из коробки стыковаться с нативным UI.
Есть инструмент, который называется compose multiplatform, который предоставляет что-то типа флаттеровских виджетов, но более стандартный подход с KMP - это нативные UI на андроиде и на iOS, которые стыкуются с общей частью, написанной на Kotlin.
Так мы и делаем - бизнес логику пишем на KMP, а интерфейсы делаем нативными
'максимально нативный интерфейс' - тут имеется ввиду, что интерфейс реализуется на каждой платформе нативно, а в KMP реализуется общая бизнес логика, которая уже переиспользуется на android и ios
О чем вообще речь идет? Ни слова не понимаю, я в лаборатории работаю в больнице
О выборе технологии, на которой писать мобильное приложение :)
Если не заморачиваться, то нужно делать 2 приложения: 1 под iOS, 1 под Android. Но тогда надо платить за них как за 2 приложения
А можно написать один кусок с логикой общий, а интерфейсы сделать для каждой версии (iOS и Android) отдельно.
В итоге экономия на этом общем куске.
Ну и есть 2 варианта: Flutter и KMP и KMP лучше в случаях, которые описаны в статье. Самый важный — количество разработчиков. На Flutter прям мало специалистов, на KMP нормально :)
Флаттер насколько мне известно тоже можно подключить к приложению и использовать только на определенных экранах
При его подключении в текущее приложение есть ограничения, например можно подключать через полноценные VC в ios. И не получится пойти от обратного: начинать переиспользовать логику в отрыве от UI. KMP в свою очередь не накладывает ограничение на шаринг тех или иных компонентов - где нужно можно пошарить, где не нужно - не шарить.
Котлин или Флаттер? Почему не Симпсоны?
Мелкий и средний бизнес выбирает flutter, поскольку он значительно экономит финансы на разработку. Не "нативность" UI он часто не принимает во внимание, когда речь идёт о каком-то каталоге товаров или условном небольшом личном кабинете. А учитывая, что этот же разработчик ещё может и веб админку сверстать, делает его (разработчика) очень ценным для бизнеса. Поэтому спрос на такие скилы очень высокий и думаю будет расти и дальше. Что делает flutter технологию весьма востребованной у этого сегмента рынка. И мне как разработчику очень важен этот аспект и я бы предпочел развиваться именно в эту сторону . Имхо у flutter и kmp разные сегменты рынка и я не вижу острой конкуренции между ними. Они играют на разных полях
С точки зрения разработчика хорошая стратегия, стать одним из 1900 человек, которые умеют во flutter:)
А с точки зрения заказчика/работодателя получается наоборот))
А насчёт разных рынков вы правы, для этого и написали статью, чтобы подсветить кейсы, в которых KMP лучше решает задачу чем Flutter
Kotlinx-datetime не позволяет банальнейшие форматы и парсинг( https://github.com/Kotlin/kotlinx-datetime/pull/251 ), отсутствуют любые сложные ui элементы.
Для продакшена где все надо быстро - не готов.
Для своих пет-проектов, где можно самому не торопясь пилить компоненты под нужные платформы - вполне себе и надеюсь что оно будет развиваться, так как это точно лучше чем Dart.
Насчет дат: в таких узких кейсах можно реализовать работу с ними через механизм expect/actual в несколько десятков строчек
Советую использовать библиотеку Klock (часть проекта KorGE). Форматы и парсинг есть. ktx либа и правда очень не очень
Насчёт дат и парсинга ответят коллеги, но насчёт ui я подробно в статье описал - мы делаем нативный ui для каждой платформы, так что проблем со сложными элементами вообще нет
Все заметили, как много статей стало в поддержку KMP и нативной разработки, когда ты чувствуешь слабость, приходится доказывать обратное. Рынок уже порешал и всем понятно, кто текущий фаворит.
Я бы написал по-другому:)
Когда видишь более крутой вариант вариант решения задачи, которую обычно решают по-другому и не видишь достаточного количества материалов про этот подход, то надо как можно быстрее писать об этом, чтобы быть, если не первым, то в первых десятках
А насчет рынка - ничего еще не порешано, также говорили и про кордову и про реакт нейтив, ionic вон до сих пор пишет, что он ни много ни мало "The Cross-Platform App Development Leader"
Ситуация меняется на глазах и про нативную разработку я еще соглашусь насчет того что ее доля может в ближайшее время серьезно сократиться.
Потому что KMP закрывает все проблемы, которые несут в себе другие кроссплатформенные фреймворки по сравнению с нативной разработкой и при этом экономит деньги. То вот про уменьшение доли KMP точно тенденции такой нет
Так что посмотрим через пару лет, уверен что KMP просто займет долю нативок в сложных приложениях, а Flutter — нишу стартапов
Честно, прям сильно не понял про невероятный Bluetooth, и проблемы с ним.
Мы используем сканеры Zebra, Honeywell, Urovo, в том числе с SDK от Honeywell, и всё отлично заводится и сканирует.
Доступ к нативной части приложения так же - не немыслимая вещь, ведь существуют MethodChannel.
Да, тут надо покопаться, если есть потребность идти в натив. Но, опять же, это необходимо чуть ли не единоразово для подключения и настройки. Далее - логика работы с данными, и тут уже вечеринка, с бизнес-требованиями и блэк джеком.
В плане ui - тоже не понял проблемы.
Вроде того, что кому-то надо на андроиде видеть стандартные виджет андроида, а на iOS - айосные?
Чё ж там с дизайнерами происходит? И почему бы не дать всем один внешний вид продукта, исходя от требований бизнеса, бренда, фирменного стиля, а не платформы?
Но тут, опять же, у всех свои потребности.
(Ну и не стоит забывать, что стандартные виджеты что Андрюши, что ИОС - лежат в самом флаттере в базе)
В плане того, что можно с Kotlin пильнуть приложку так же, и под ios, дорисовав интерфейс - клёво.
Но рассказывать про то, что flutter - не для бизнеса, тут не убедил.
p.s. На хакатоне вполне себе отлично заносили пакет Яндекса для работы с их картами. Да, там есть ограничения, в веб версии отказался заводиться.
По bluetooth одна из последних задач - автоматическое открытие дверей в момент приближения человека, у которого есть телефон с доступом. При этом приложение может не всегда быть запущено.
Касаемо виджетов - реализованные виджеты не всегда ведут себя так, как на платформе.
Для примеров можно открыть тысячи issue платформ ios и android (https://github.com/flutter/flutter/issues?q=is%3Aopen+label%3Aplatform-ios%2Cplatform-android+). Некоторые из проблем кажутся незначительными. Но есть и глобальные, например: 1(https://github.com/flutter/flutter/issues/82906), 2(https://www.reddit.com/r/FlutterDev/comments/yywx66/attn_all_your_vote_is_needed_to_fix_critical/), 3(https://www.reddit.com/r/FlutterDev/comments/1140pdv/two_years_later_flutters_biggest_problem/) .
Насчёт технических деталей попрошу ответить коллегу, насчёт интерфейса отвечу сам.
Если делать приложение для сотрудников и не нужно заботиться о привычности, то можно сделать и один интерфейс для обеих платформ.
Но если говорить про премиальных пользователей, то цель приложений обычно увеличить ценность основного продукта, например квартиры. Чтобы хорошо закрывать эту цель, интерфейс должен быть максимально привычен, без всякого "да вроде нормально, но что-то немного непривычно"
А что у KMP с разработкой для веб и настольных вариантов приложения?
Такая возможность присутствует, сделать можно https://kotlinlang.org/docs/multiplatform.html но это не то чтобы классический подход. А десктопные приложения вообще неклассическая в современном мире штука:)
Для UI есть Kobweb (который на основе Compose). Бизнес-логику можно писать хоть на JS (есть возможность взаимодействия с node.js и npm пакетами из-под Kotlin, есть поддержка Typescript), хоть на JVM, хоть на нативе
настольных вариантов приложенияUI - работа с Compose или любым Java-фреймворком под это дело. Или что-нибудь нативное (но примеров я не видел). Или запакетить в Электрон kotlin-js веб-приложение (тоже примеров не видел)
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 изменения были несущественные.
Ого, четыре сценария, когда нужно выбирать Kotlin Multiplatform вместо Flutter? Вот это да! Надо же так удивиться. Я уже подумал, что Flutter - это панацея для всех проблем в кроссплатформенной разработке.
О, еще одна статья о Kotlin vs Flutter. Как оригинально!
Котлин - лучше флаттера, куда катится мир девелопа!
Почему Kotlin Multiplatform лучше, чем Flutter для разработки приложений?
Если нужна скорость разработки и доступность специалистов, нужно выбирать js/Electron. Flutter, разумно выбирать только если вам приплачивает Гугл за продвижение их технологий, которые в ближайшее время врятли будут широко востребованы, а скорее всего просто канут в лету.
Посмотри, что сделал Evernote с переписыванием нативных продуктов на js.
Флаттер 👒