KMP vs Flutter vs React Native

Сейчас существует широкий спектр кроссплатформенных технологий, среди которых Flutter, React Native и, конечно же, Kotlin Multiplatform Mobile (KMP). Какую технологию стоит выбрать и почему именно ее? Давайте попробуем разобраться!

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

Ребята из JetBrains проделали невероятную работу для оптимизации затрат на разработку и переиспользование кода. Причем повторное использование возможно не только внутри одной платформы, но и между разными платформами (Android и iOS). Если ваша команда разработчиков хочет сохранить нативный UI для каждой платформы, то Kotlin Multiplatform Mobile — идеальный вариант.

Это связано с тем, что Kotlin Multiplatform вообще не поддерживает пользовательский интерфейс. Вместо этого она позволяет реализовывать бизнес-логику для приложений на Android и iOS. Из-за особой конфигурации можно создать проект, который будет скомпилирован в библиотеке Android с конкретным кодом для Android, а во фреймворке iOS — с соответствующим кодом для iOS. С технической точки зрения больше нет проблем с одновременным использованием одного и того же кода на iOS и Android. Когда вы отлаживаете свой код, вам нужно отредактировать его только один раз, а изменения произойдут на обеих платформах. Однако на нативной стороне приложения не стоит выносить в общий код:

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

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