Comments 25
В таких обзорных статьях хотелось бы хотя бы поверхностного сравнения с Flutter, ибо он выглядит стабильнее уже прямо сейчас.
Могу пару слов на эту тему сказать. Flutter достаточно стабилен, чтобы писать production-ready приложения. Вкатиться во Flutter ещё проще, так как можно выбирать не только среди Android/iOS разработчиков, но ещё и разработчиков Angular. Всё остальное +/- тоже самое.
Вы правы, если мы будем сравнивать Flutter с CMP без дополнительного контекста. Если лоб в лоб, то Flutter куда более развитый и стабильный, чем CMP, потому что получить рабочее приложение на нем будет гораздо проще.
Но есть пара моментов:
1) Нативный UI для iOS лучше Flutter и CMP во всех случаях. Мало какие компании готовы на user experience, который дает Flutter, потому постепенный переезд на натив обязательная необходимая опция.
2) Синтаксис CMP 1 в 1, как Jetpack Compose, который нативен для Android. Если android разработчик будет сразу писать под Android под CMP, то он не заметит разницы, а эффект будет точно таким же. CMP для Android работает поверх Jetpack Compose, а значит дает тот же эффект, что и натив.
3) Сегодня для новых экранов и приложений android разработчик с гораздо большей вероятностью выберет Jetpack Compose, чем View(xml)
Получается, что если мы добавляем к выбору библиотеки еще и контекст набора команды и построения процессов, то:
Flutter куда менее пригоден, чтобы шарить только бизнес логику на несколько платформ, чтобы потом поверх нее построить нативный UI. KMM(KMP) с этим справляется гораздо лучше. Т.E с Flutter будет сложнее слезть.
Чтобы Flutter появился в проекте - надо нанять Flutter разработчиков (и где-то их еще найти), когда как Compose и так сейчас заходит в проекты, так как это нативная для Android технология. При небольшой подготовке мы получаем CMP код для iOS в подарок просто потому, что android разработчик делал свою работу.
И вот вопрос, если Jetpack Compose и CMP - это одно и то же, и я как iOS разработчик получаю почти бесплатно экраны для iOS просто потому, что android разработчик занимается своей работой, то почему бы мне этим не воспользоваться?
Во-первых, я смогу подкинуть готовые экраны уже сейчас, в которых нет скролла/работы с жестами
Во-вторых, я смогу подкинуть все остальные экраны тоже, но временно, чтобы не срывать релиз, если вдруг не успеваю. А с выходом в beta проблем у этой технологии станет еще меньше.
Во-третьих, chatGPT переводит CMP в SUI на раз два
Даже несмотря на то, что Flutter как технология старше и стабильнее, концептуально с точки зрения расходов и настройки процессов он на мой взгляд не очень удачен.
"Flutter достаточно стабилен, чтобы писать production-ready приложения."
Да, но я бы по опыту сказал что только для проектов у которых маленький жизненный цикл - написал, внедрил, забыл.
Вел проект около 2-3х лет, и постоянно вылезали проблемы по типу - для того чтоб обновиться нужно чтоб все либы обновились. А таких breaking changes уже было два: при переходе с дарта без наллсейфити на наллсейфити, и сейчас с 2 на 3. И не дай бог у вас в проекте есть какая то либа которую забросили год назад. Начинаются истории с локальным форканьем проекта и его поддержка садиться на ваши плечи. Как по мне 2 раза за такой короткий срок ломать начистую обратную совместимость для продакшен решения - не комильфо.
Все таки одним из минусов докинул бы что вскользь упоминал автор - если вдруг придется писать нативную реализацию самим (нет нужной библиотеки, или есть но не удовлетворяют бизнес-требованиям) это превращается в борьбу с платформой. Даже с учетом возможности использовать Pigeon - местами превращается в борьбу и написание "прослойки", когда в KMP это более проще выглядит.
Compose действительно хотелось бы попробовать в мультиплатформе, но останавливает отсутствие Mac. Раньше не обзавелся, сейчас дороговато. + то что он ещё в альфе все же.
А для десктопа под капотом будет JVM?
Я правильно понимаю, что Compose Multiplatform и Jetpack Compose это два разных композа? И первый не нативен для Android также как и для и iOS в отличии от Jetpack Compose. А Skia под капотом исползуется для обеих платформ?
Не совсем так, Compose Multiplatform работает поверх Jetpack Compose для Android. Для всего остального(web, desktop) CMP работает поверх Skia. То есть для android CMP условно нативная технология, android разработчик почти не заметит разницы между CMP и jetpack compose во время работы
Смотрел презу CMP на Мобиусе, для iOS все выглядело максимально грустно и костыльно. Докладчик просто копипастил андроидовский дропдаун компонент для iOS, потому что такого просто не существует и в целом компонентов под нее раз-два и обчелся, насколько я понял... Что будет с производительностью тоже, мягко говоря, вопрос. На Flutter уже обожгись с jank'ами в Skia на яблочной платформе, поэтому и переходят на Impeller. В CMP как планируют решать эту проблему, или пока не до этого, выпустить бы бету?
Да, самое главное, что заметит android разработчик при переходе на CMP - это то, что нету этих самых дропдаунов и тд. Для Android решается очень просто через expect/actual @Composable функцию, где для android можно подкинуть ту самую, что копировал выступающий из натива (т.е без копирования). Для iOS придется писать свою реализацию, или скопировать, как это было в примере на конференции
На Skia на CMP будут те же самые проблемы, что и в Flatter, когда он на Skia. Это связанно с устройство самой Skia, потому что там нету возможности компилировать шейдеры заранее, в лучшем случае прогревать их, как это делали на Flutter. Про переход CMP на impeller не знаю, думаю, что пока не выкатят beta, а потом stable, речи о переходе на другой движок не будет
Нет, компоуз в природе только один, его написала гугл. Только там почему-то решили мультиплатформенный код собирать только под андроид таргет.
Чтобы получить CMP jetbrains затягивает в свой форк новую версию, выносит весь мультиплатформенный код в common (а в последнее время как я понимаю даже это не так часто приходится делать, т.к. в гугле уже пишут его в common), и полирует релиз для всех остальных таргетов. В случае подключения CMP к андроид проекту gradle загружает не мультиплатформенные артефакты от JB, а гугловые. Т.е. для андроида нет разницы какой компоуз в проекте CMP или нет, приложение всегда собирается с гугловым.
А как на КММ встраивать БД для iOS и Андроид одновременно?
Ну начать стоит с:
https://github.com/cashapp/sqldelight
Эта мультиплатформенная библиотечка работает поверх sqlLight, потому справляется прекрасно.
Если есть какие-то специфические вещи, которые она не решает (а я с ходу не могу придумать какие), то можно создать мультиплатформенный интерфейс, написать реализацию на каждой платформе отдельно и прокинуть в KMM проект. Из плюсов при правильном построении архитектуры можно будет написать тесты для БД раз для обоих платформ
Лично мне для всех моих случаев было достаточно sqlDelight
Без обид, на фоне Flutter это выглядит мышиной возней, без каких-либо обозримых перспектив в проде.
Обид нет?
Все зависит от задачи: если нас устраивает тот user experience, который дает Flutter, и у нас нет планов переходить на натив, то Flutter однозначный победитель. В таком случае нужна команда Flutter разработчиков.
Если же мы работаем над приложением, которое будет развиваться, и нас интересует нативное поведение UI, то мы однозначно выбираем KMM(KMP) + CMP. Потому что в таком случае мы получаем бонусы для iOS, которые я описал в статье просто потому, что android разработчик делает свою работу на нативном для себя фреймворке. У нас (iOS разработчиков) будет возможность взять уже готовую бизнес логику KMM(KMP), готовые экраны на CMP, втащить их временно в прод, а в процессе переписывать CMP на SUI, например, с chatGPT.
Звучит сложнее, чем просто написать приложение на Flutter, но найти команду на Flutter тех размеров, какие сейчас есть команды в больших компаниях просто невозможно. Потому не понятно, что еще сложнее
Чем вам React Native не нравится. С точки зрения затрат на разработку и поддержку он не имеет конкурентов. Разработчиков найти проще простого. Любой мидл фронтенд освоит его прямо в процессе разработки.
Тем, что Android разработчики уже есть в команде и их не надо нанимать. Достаточно только внедрить технологию и настроить процессы, чем искать целый штат.
Если мы говорим про приложение с нуля, когда команды еще нет, то я тоже бы предпочел, чтобы мои коллеги были ближе к нативу, чем фронтендеры, которые решили переучиться в мультиплатформенную мобильную разработку. Последние неизвестно когда въедут, потому что платформенные нюансы будут сыпаться еще долго. К тому же у меня нет ответа на вопрос: "Зачем им это надо?"
Отвратительным UX?)
Для разработчиков это может и удобно, но помню что переходил на аналоги некоторых приложений, которые переписывали на react.
Из моего опыта использования подобных решений, все упирается в качество кросс-платформенных библиотек. Например, недавно пытался сделать диктофон на flutter. Библиотек много, но часть из них не работает, в части нет документации, в остальных только мобильные или только десктопные версии, когда нужны все. И оказалось, что нативно написать с помощью ChatGPT и какой-то матери быстрее, чем разбираться в проблемах некачественных библиотек на экзотическом языке, который больше нигде не используется, что ставит под вопрос целесообразности инвестиций времени в его изучение. Как только копнешь чуть глубже crud-сайтиков, запакованных в "нативное" приложение — труба. Как с этим в данном решении?
В том и дело, что в KMM(KMP) можно написать мультиплатформенный интерфейс, в наивном коде сделать его реализацию и подписаться под него, а потом, например, через DI прокинуть в KMM(KMP) модуль под этим интерфейсом. Т.Е тут не нужны никакие каналы, как это сделано во Flutter и тд, чтобы доставить нативную реализацию до мультиплатформенной части. Ко всему прочему, CMP позволяет обернуть любую нативную вьюху и вставить в мультиплатформенный UI. Я таким образом реализовывал видео плееры и полет нормальный
Надо будет пощупать. Пытался свой пет проект на флаттере писать, но были некоторые проблемы с работой с текстом и неудобством работы с изолятами (как же тогда не хватало привычных корутин и многопоточки обычной). Ну и замена sealed классов в то время была только через freezed, не самая удобная штука, хотя в дарт сейчас их вроде добавили в каком то виде.
Есть ли смысл начинать писать мобильное приложение не на Kotlin Multiplatform и Compose Multiplatform?