KMP vs Flutter: 4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter
Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.
9.2K9.2K показов
4.2K4.2K открытий
11 репост
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 изменения были несущественные.