Как стать автором
Обновить

KMP vs Flutter vs React Native

Время на прочтение4 мин
Количество просмотров15K

Сейчас существует широкий спектр кроссплатформенных технологий, среди которых 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-проекте требуется только один специалист для создания общего кода и нативной части своей платформы. Специалиста другой платформы потребуется подключить только для внедрения пользовательского интерфейса в существующую логику. Код пишется только один раз, что исключает риск появления двух багов вместо одного.

В результате поддержка и разработка приложения становятся намного дешевле, эффективнее, реализация функций также будет заметно быстрее, и в то же время вы сохраняете полную нативность как для разработчика, так и для пользователя.

Теги:
Хабы:
Всего голосов 10: ↑3 и ↓7-2
Комментарии25

Публикации

Истории

Работа

Ближайшие события

AdIndex City Conference 2024
Дата26 июня
Время09:30
Место
Москва
Summer Merge
Дата28 – 30 июня
Время11:00
Место
Ульяновская область