Комментарии 13
Платформенный код (UI, доступ к железу) реализуется отдельно для каждой системы с использованием её родных технологий. Это устраняет необходимость изучать несколько UI-фреймворков и позволяет использовать уже знакомые инструменты, такие как Swift для iOS или Jetpack Compose для Android.
Ээээ, наоборот. КМР требует знания как себя самого, так и нативных инструментов – ну или чего-то типа JetPack Compose. В то время как флаттер или (не к ночи будь помянут) реакт самодостаточны.
Согласен, KMP требует знания как самого Kotlin, так и нативных инструментов. Однако он дает больше гибкости и позволяет работать с уже привычными фреймворками и API. Это плюс для тех, кто хочет сохранить нативный вид и производительность приложения, не изучая новые UI-фреймворки с нуля. Flutter или React Native, это тоже отличные решения, но они немного более ограничены в плане интеграции с нативными платформами.
Однако он дает больше гибкости
Можете привести пример функционала, который невозможно реализовать встроенными средствами того же флаттера, обязательно требующего использования нативных API?
и позволяет работать с уже привычными фреймворками и API
Так в том-то и дело, что нужна команда, обладающая знаниями как КМР, так и каждой из целевых платформ.
Flutter или React Native, это тоже отличные решения, но они немного более ограничены в плане интеграции с нативными платформами.
Вот-вот, именно об этом поподробнее, пожалуйста. В каком конкретно месте обнаружились критичные ограничения? Не придираюсь, реально интересно.
Ограничения Flutter и React Native чаще всего всплывают, когда нужно что-то сделать на уровне самой платформы. Например, на iOS довольно геморно работать с CallKit, Live Activities или App Clips, без нативного кода это не решить. На Android, история с Foreground Services, всякими Broadcast Receiver’ами или глубоким контролем фоновых процессов. Без Kotlin/Java туда не влезешь.
Если говорить о Bluetooth с какой-то специфической логикой (особенно на iOS), то тоже часто приходится уходить в натив. Ну и типичная ситуация, доступ к новым возможностям ОС сразу после их релиза. Flutter и RN обычно отстают, пока не появится официальная поддержка или кто-то не напишет нужный плагин.
Kotlin Multiplatform в этом плане дает больше свободы: бизнес-логику пишешь один раз, а платформенные штуки спокойно реализуешь на Swift или Kotlin, как привык. Ничего не мешает нативно встраиваться, и при этом кодовая база остается максимально общей.
CallKit, Live Activities или App Clips, без нативного кода это не решить
Первые два вопроса у нас были решены во флаттере без проблем, третий в процессе, скоро будет. Из натива понадобился один файл на Swift, буквально пару десятков срок, как часть того же флаттер проекта – без него не получалось надёжно принимать пуши, если приложение в бэкграунде или выгружено.
С Bluetooth не работали, но библиотек полно.
Ну и типичная ситуация, доступ к новым возможностям ОС сразу после их релиза.
Вообще-то это противоречит идее кроссплатформы – которая подразумевает, что приложение делает ровно то же самое везде. Соответственно, если в одной ОС появилась фича, которой нет в других – это не про нас. Да и вообще ИМХО не стоит так уж суетиться.
платформенные штуки спокойно реализуешь на Swift или Kotlin, как привык
То есть опять команда универсальных солдат.
при этом кодовая база остается максимально общей.
Существенно менее общей, чем с флаттером всё же – где она просто единая.
Да, согласен, во Flutter многое реально сделать, особенно если есть опыт и не лень копать в сторону нативных интеграций. Но тут скорее вопрос не в том, можно или нельзя, а в том, насколько это удобно, стабильно и легко потом поддерживать.
Добавить файл на Swift, не проблема. Но когда таких мест становится много, это уже не совсем "единый код". А если проект растет, начинаешь думать, стоит ли вообще всё это пихать в Flutter, или проще часть фич делать нативно, как и задумывалось платформой.
Насчет "фича только на одной ОС", ну, зависит от задач. Если надо просто одинаково везде, то да, Flutter топ. Но если хочется выжать максимум из iOS или Android, использовать какие-нибудь Live Activities, Android-specific background-ограничения, или просто следовать нативным UX-гайдлайнам, тут уже начинаются компромиссы. Flutter это всё позволяет, но через танцы с бубном и нативные вкрапления. И чем больше таких мест, тем меньше ощущение "кроссплатформы".
KMP тут даёт немного другой подход, логика общая, UI и доступ к железу, нативный. Да, нужно разбираться в каждой платформе, но зато ты не воюешь с фреймворком, а просто используешь родные инструменты. У каждого подхода свои плюсы, вопрос в приоритетах проекта.
Flutter это всё позволяет, но через танцы с бубном и нативные вкрапления.
Пробовали, или "Рабинович напел ©"? 😁 Вот честно, не нужны никакие танцы. Всё реализуется вполне естественным путём.
На данный момент у флаттера единственная реальная проблема – недостаточно стабильная реализация для веба. Как правило, всё хорошо, но при существующем зоопарке платформ и браузеров изредка баги таки вылезают. А при аудитории 30М+ пользователей мне пока просто стрёмно раскатывать реализацию на всех, в логах утонем. Так что пока допиливаем на ограниченном множестве, постим им баги и ждём факсов. А натив работает отлично и сейчас.
Да, пробовали, и не только "напели")) Всё зависит от проекта и команды, конечно. Если выстроен процесс, команда опытная, всё можно сделать красиво и без боли, согласен. Но и правда в том, что как только появляется необходимость чуть глубже интегрироваться с платформой, пуши в бэкграунде, камеры, специфичные UI-фичи, неизбежно лезешь в натив. Иногда это легко, а иногда превращается в набор костылей, особенно если фичи специфичные и под iOS, и под Android.
Flutter это умеет, спору нет. Но есть ощущение, что в какой-то момент ты уже не столько "кроссплатформу" делаешь, сколько борешься за баланс между "удобно" и "поддерживаемо".
А про веб, вообще без споров. Мы тоже не рискуем на всю катушку его юзать в проде. Потенциал огромный, но пока есть шероховатости. Хорошо, что команда Flutter активно пилит, но на сейчас, осторожно.
В итоге всё как обычно: Flutter, KMP, натив, всё рабочие инструменты, вопрос в задачах и том, насколько хочется(или нет) держать всё в одном фреймворке.
Но и правда в том, что как только появляется необходимость чуть глубже интегрироваться с платформой, пуши в бэкграунде, камеры, специфичные UI-фичи, неизбежно лезешь в натив.
Нам всё это удавалось решать встроенными средствами – за исключением специфичного UI, который мы принципиально не используем, добиваясь идентичного UX на всех платформах.
Думаю, можем сойтись на том, что функционально оба подхода примерно равнозначны, и выбор в основном зависит от бэкграунда команды. Если речь о переходе от отдельных нативных приложений к кроссплатформе, то КМР, вероятно, вполне обоснованный выбор. У меня было иначе: получили в наследство RN приложение очень плохого качества, пытались привести его в чувство, но в конце концов оказалось проще переписать. С RN к тому времени нахлебались, кроссплатформа была нужна, КМР в тот момент был вообще сырым ещё – так что выбора особо и не было, взяли флаттер. Пока не пожалели.
В любом случае, спасибо за интересную дискуссию.
А про веб, вообще без споров. Мы тоже не рискуем на всю катушку его юзать в проде.
А какие проблемы в ним в КМР? Во флаттере в основном затык даже не в функционале, а в обработке нестандартных ситуаций. Типа у юзера сковырнулся графический энжин, и флаттер начинает сыпать ошибки при попытке рендера каждого фрейма. И всё это сыплется нам в логи. Даже если таких юзеров за день пара штук, всё равно неприятно.
"Решение одним swift файлом"
Так и kmp позволяет просто вызовом нативного метода, всё остальное обработать common-кодом, ну и "есть готовые библиотеки" работает и с kmp)
Так и kmp позволяет
Разумеется. Мы же не фаллометрией тут занимаемся, а пытаемся выяснить, в каких случаях целесообразнее выбирать одну платформу, в каких другую 🙂 При том, что функционально они примерно равноценны. Вроде стало понятнее.
ну кстати если котлин такой и веб и натив через jvm можно сделать тулу по работе с канвасом и свг на нём. если котлин имеет доступ и к канвасу и к странице html, гляну котлин, спасибо призадумался, задача наивнейшая есть html иконок с BBox их надо брать из html и писать в файл, рядом запиысывая txt c их отступами и наименованиями, а сами иконки писать в растр в несколько страниц тоесть несколько листов потомучто там от 20 до 50 мегабайт иконок ) поидее котлин идеально подходит ) может гляну )
Да, под такую задачу Kotlin правда может неплохо подойти. Он и с HTML/JS может работать через Kotlin/JS, и на JVM нормально тянет всякие файловые операции. Ну и плюс удобно, что можно всё на одном языке писать, и обработку, и сохранение, и логику. Если уже есть опыт с Kotlin, точно стоит попробовать, а если нет, может как раз хороший повод глянуть.
Kotlin Multiplatform: как писать код один раз и покорить все платформы