Сейчас существует широкий спектр кроссплатформенных технологий, среди которых Flutter, React Native и, конечно же, Kotlin Multiplatform Mobile (KMP). Какую технологию стоит выбрать и почему именно ее? Давайте попробуем разобраться!
Все технологии имеют свои преимущества и недостатки, но ни одна из них не решает всех проблем. Проще говоря, ваш выбор будет зависеть от конкретных задач.
Ребята из JetBrains проделали невероятную работу для оптимизации затрат на разработку и переиспользование кода. Причем повторное использование возможно не только внутри одной платформы, но и между разными платформами (Android и iOS). Если ваша команда разработчиков хочет сохранить нативный UI для каждой платформы, то Kotlin Multiplatform Mobile — идеальный вариант.
Это связано с тем, что Kotlin Multiplatform вообще не поддерживает пользовательский интерфейс. Вместо этого она позволяет реализовывать бизнес-логику для приложений на Android и iOS. Из-за особой конфигурации можно создать проект, который будет скомпилирован в библиотеке Android с конкретным кодом для Android, а во фреймворке iOS — с соответствующим кодом для iOS. С технической точки зрения больше нет проблем с одновременным использованием одного и того же кода на iOS и Android. Когда вы отлаживаете свой код, вам нужно отредактировать его только один раз, а изменения произойдут на обеих платформах. Однако на нативной стороне приложения не стоит выносить в общий код:
- весь интерфейс;
- привязку интерфейса к общей ViewModel из общей библиотеки кода;
- особенности платформ: работу с камерой, NFC, Touch ID или Bluetooth.
И в любом случае общий UI между платформами не является необходимостью. При обобщении UI требуется несколько итераций, чтобы сделать его и поведение приложения более нативными. Что, разумеется, требует дополнительных циклов разработки.
Flutter использует canvas из нативного SDK для разных платформ и рисует свои UI-компоненты на нем с помощью Material Design specifications. React Native использует собственные компоненты в JS-коде. React дает возможность обновлять логику приложения без повторной сборки проекта и загрузки в стор (JS-код загружается с серверов и сразу начинает работать на устройстве, без обновления всего приложения).
Что касается бизнес-логики, она является общей для Flutter и React Native. Соответственно, она пишется на языках Dart и JavaScript, с которыми мобильные разработчики, привыкшие к нативному стеку, не знакомы. Для этих платформ потребуется прослойка между нативным и ненативным кодом.
Согласованность дизайна для всех версий операционной системы и между операционными системами является еще одним преимуществом Flutter. Эта технология также позволяет легко создавать кастомный дизайн. Сравнивать высокую скорость разработки и высокую производительность Flutter с другими технологиями вряд ли есть смысл, так как это однозначно его фишка.
В Kotlin Multiplatform Mobile нет промежуточных слоев, что практически устраняет любые узкие места при взаимодействии. А поскольку Kotlin Multiplatform работает с нативными экосистемами каждой платформы, разработчики могут использовать инструменты и библиотеки, которые они всегда использовали, включая Swift UI и Jetpack Compose. Любые ограничения, с которыми вы сталкиваетесь, всегда можно обойти с помощью Kotlin, Swift или любого другого языка, который удобен для решения конкретных проблем с наименьшим риском. Но в случае с Flutter вы должны оставаться верным только Dart, а с React Native — только JS.
Kotlin Multiplatform не требует использования VM, в отличие от React Native. Несмотря на то что Flutter также не требует VM в разработке, вы должны писать на ненативном языке в ненативной экосистеме. В то же время в Kotlin Multiplatform очень легко писать собственный код на любом уровне абстракции и на любом уровне архитектуры.
В отличие от Flutter или React Native, где вы должны продолжать работу с их инфраструктурой, KMM может интегрироваться в любой существующий проект. Внедрение KMM может осуществляться поэтапно, без необходимости останавливать текущий процесс разработки. Мы готовим roadmap по расширению использования KMM в проекте, чтобы после каждого шага можно было выполнять релиз в стор. Также важно, что мы расширяем использование KMM с текущим кодом приложения, что помогает спасти проект от новых багов.
В KMM-проекте требуется только один специалист для создания общего кода и нативной части своей платформы. Специалиста другой платформы потребуется подключить только для внедрения пользовательского интерфейса в существующую логику. Код пишется только один раз, что исключает риск появления двух багов вместо одного.
В результате поддержка и разработка приложения становятся намного дешевле, эффективнее, реализация функций также будет заметно быстрее, и в то же время вы сохраняете полную нативность как для разработчика, так и для пользователя.
Хм. Интересная статья. Начинается описанием трех технологий кроссплатформенной разработки, а заканчивается восхвалением ОДНОЙ ЕДИНСТВЕННОЙ ПРАВИЛЬНОЙ. Я могу конечно ошибаться, но тут попахивает пропагандой, не более.
того же мнения, не знаю как на счет свифта, но на дарте кажется мне больше возможностей. и если фуксия выстрелит и ее примут как еще одну платформу, то в группу нативных языков можно добавить и дарт.
я вижу здесь описание плюсов всех 3х технологий, выбор тут будет только за разработчиком, с каким стеком работать.
Расул, мы лишь отражаем свой опыт работы и видим так эти технологии. Мы – независимый разработчик, нам нет профита восхвалять что-то определенное, мы – инженеры и выбираем тот инструмент, который лучше подходит под задачу.
Но восхваляете KMP.
И критерий "лучше" не озвучиваете.
Для прототипа или проверки гипотез "лучше" значит "быстрее", а значит, кроссплатформенный Flutter "лучше".
Для экономии средств, внутрикорпоративных приложений, мобильно-десктопных приложений, для Fuchsia OS, а также множества других причин "лучше" будет Flutter.
Почему пропаганда? Не вижу плакатов и лозунгов с призывом "восстаньте против ...или..."))Опишите ваше виденье пожалуйста
Тоже самое подумал, когда прочитал эту статью недавно на Хабре.
KMM ещё завоюет рынок))
Мне дико не нравится идея написания кода под две платформы на разных языках, который делает одно и тоже. Флаттер топ в общем.
Интересная статья.
А начинающему разработчику, который не знает еще языка Kotlin, не легче ли ему изучить Dart и начать разработку на Flutter? Какие могут быть там подводные камни?
К вопросу о новичках выскажу чистое ИМХО - нативная разработка никуда не денется и будет востребована ещё долго, не важно android или ios, по этому не вижу смысла касаться дарта, по тому что начав с котлина, можно унифицировать себя как нативщика и мультиплаформщика. То есть получить два пути развития одновременно, вместо одного, после освоения дарта.
Для андроид разрабов, не составит особых проблем перейти в мультиплатформенную разработку на родном котлине и тем самым дополнить стек своих же навыков не теряя при этом связи с нативкой
Борис, вы правы, нативный стек точно продолжит развиваться, что нельзя сказать про различные кроссплатформенные фреймворки (Cordova и иже с ними).
Натив может и умереть, когда для флаттера+дарта напишут кроссплатформенные библиотеки для юзания всех нативных фич
Вход в программирование на Flutter действительно ниже, благодаря материалам от Google, можно собрать своё простенькое приложение довольно быстро, но это не избавит вас от знания мобильных операционных систем и от специфики мобильных платформ, это всё равно нужно знать при создании мобильных приложений.
KMP еще в альфе сидит. Вылупится ли из этого релиз, когда и сколько раз придется по граблям пройти - вопросы интересные, но новичку не стоит на них тратить свое время, имхо
Здравствуйте! Да, но это не мешает нам уже 4.5 года использовать эту технологию. Вы правы, что пока это не станет релизом, каждый использует на свой страх и риск )
А для новичков мы прямо сейчас готовим обучающий курс по нативному айосу, андроиду и КММ, чтобы упростить вход в эти технологии.
Как вы думаете, исходя из вашего опыта, куда проще "вкатиться" android или ios разработчику, во Flutter или KMM?) И насколько КММ-подход позволяет сократить стоимость разработки, по сравнению с нативной?
Из нашего опыта, чтобы освоиться в проекте и в этих технологиях, андроид-программисту надо не больше 1-2 недель, айоснику - больше, может быть месяц, но всё сильно зависит от опыта и настроя специалиста :)
Круто) К я тому, что если делать приложуху на флаттере, то мы получим одинаковую бизнес-логику и ui для обеих платформ, это удобно в том случае, если дизайн одинаковый. А как быть, если дизайн разный, заказчик так захотел, придется возвращаться к нативу. КММ более гибок в таком вопросе, получается
Никто не мешает на том же flutter сделать вёрстку под iOS и Android различную. Опираясь на определение платформы на которой запускается приложение. Оставив при этом бизнес логику
Спасибо за ответ!)
Там даже есть разделение стандартных ui элементов на материал (андроид) и купертино (айос)