Нативный, кроссплатформенный или гибридный. Выбираем подход к мобильной разработке

В разработке мобильных приложений есть три основных метода: нативный, кроссплатформенный, гибридный.

Нативная разработка — создание продуктов только для одной мобильной платформы. Здесь используются специфичные языки и инструментарий разработки Android и iOS.

Такие приложения, как правило, работают быстрее и предлагают лучший пользовательский опыт. Главный минус: высокая стоимость и длинный период time-to-market.

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

Кроссплатформенные приложения могут работать медленнее, но разрабатывают их быстрее, поскольку здесь не нужно создавать отдельные версии для каждой операционной системы (ОС).

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

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

Нативная разработка

Нативная разработка использует преимущества устройства и ОС. Обычно такие приложения имеют прямой (как говорят, «на низком уровне») доступ к GPS, камере, микрофону, Bluetooth и NFC. Пользовательский опыт нативных продуктов лучше благодаря высокой производительности и дружественному интерфейсу с привычным поведением.

Основные проблемы нативного подхода:

• Для работы нужно привлечь столько команд разработки, сколько будет платформ;
  ‍
• Написанный код нельзя использовать для того же приложения на другой платформе. Фактически создаются две отдельные кодовые базы.

Оба пункта увеличивают бюджет и потенциально time-to-market проекта.

Инструментарий

Нативные приложения работают либо на Android, либо на iOS, поэтому для них используются разные языки программирования.

Android: самые ходовые — Java или Kotlin. Первый требует больше строк кода, но это один из главных языков программирования в мире. Второй лаконичнее, способен заменить Java, подходит для объектно-ориентированного и функционального программирования. Сегодня Kotlin — это основной язык Android-разработки.

iOS: здесь используют языки Objective-C, либо Swift. Оба созданы Apple на основе языка С исключительно для своей операционной системы. Objective-C старше и сложнее Swift, сегодня он используется редко. Swift же значительно моложе и производительнее, сейчас он в ходу для новых приложений.

Аргументы за

• Высокая производительность. Нативные приложения создаются для конкретной платформы и точно соответствуют гайдам ОС. Такие продукты эффективны, они быстро реагируют на действия пользователей.
  ‍
• Доступ ко всем фичам. Разработчики обращаются к штатным возможностям устройства, например, пуш-уведомления, встроенные покупки, сенсоры (Face ID, компас, гироскоп и т. д.). За счёт этого улучшается пользовательский опыт, так как приложение может предложить большой набор опций.
  ‍
• Безопасность. Нативная разработка использует встроенный функционал безопасности ОС, что повышает уровень защиты данных.
  ‍
• Улучшенная работа офлайн. Автономный режим работает производительнее благодаря прямому доступу к кэшированию, локальному хранилищу и более простой синхронизации.
  ‍
• Нативным приложениям проще получить фичеринг сторов — попасть в специальные тематические подборки App Store и Google Play.

Аргументы против

• Более высокая цена. Нативная разработка требует больших затрат, так как необходимо привлекать отдельные команды разработчиков для каждой платформы.
  ‍
• Увеличенное время. Команды, создающие одно и то же приложение для разных платформ, выполняют больше работы, чем в кроссплатформенной разработке. Также после релиза необходимо поддерживать и дорабатывать функционал, что сказывается на временных затратах и бюджете. Правда работы можно параллелить или планировать с небольшим временным лагом.

Примеры приложений

• Pinterest, Trello и Twitter (Kotlin)
  ‍
• Duolingo, WhatsApp и Instagram (Swift)

Когда нужна нативная разработка?

• Требуется создать продукт специально для одной платформы.
  ‍
• Когда основная задача — создать высококачественное приложение и обеспечить хороший клиентский опыт, а цена не так важна.
  ‍
• Если для работы приложению необходим прямой доступ к специфичным функциям, от которых требуется производительность и скорость: GPS, камера, Bluetooth и т. д.

Кроссплатформенная разработка

Кроссплатформенные приложения основаны на единой кодовой базе, которая адаптируется для разных ОС. В случае мобильной разработки для этого применяются фреймворки, использующие Android SDK и iOS SDK. SDK — это software development kit, пакет инструментов разработки.

Приложения используют элементы интерфейса, присущие ОС, что придаёт ощущение «нативности». Они также имеют доступ к нативным фичам через плагины и надстройки, то есть через прослойку, предоставляемую кроссплатформенным фреймворком.

Инструментарий

Кроссплатформенные приложения работают через специальные SDK и фреймворки:

• React Native (от Meta*) — код пишется основе JavaScript. Хорошо подойдёт, если нужен отзывчивый и интуитивно понятный интерфейс. Среды разработки: VS Code, Android Studio, WebStorm, Xcode, Atom.
  ‍
• Flutter (от Google) — один из самых популярных фреймворков на момент подготовки материала. Код создаётся на языке Dart, схожем с языками семейства C. Важное отличие Flutter от других инструментов — интерфейсы и бизнес-логика приложения не меняются в зависимости от ОС. Среды разработки: VS Code, Android Studio, IntelliJ.
  ‍
• Xamarin (от Microsoft) — платформа, использующая C# and XAML. Кодовую базу можно почти полностью использовать сразу для нескольких ОС. Предоставляет полный доступ к нативным API, что даёт высокую производительность, однако некоторые элементы интерфейса придётся писать отдельно. Среда разработки: Visual Studio.
  ‍
• Kotlin Mobile Multiplatform — синтаксис языка Kotlin напоминает Swift. Это не фреймворк, а технология. Сейчас используется не так активно как предыдущие три инструмента. Среды разработки: IntelliJ IDEA, Android Studio, Visual Studio Code.

• Apache Cordova позволяет программистам создавать приложения для мобильных устройств с помощью CSS3, HTML5 и JavaScript, вместо того, чтобы использовать конкретные платформы API, такие как Android и iOS.
  ‍
• Ionic создан на базе фреймворков AngularJS и Apache Cordova. Первый предназначен для фронтенд-разработки, второй — для разработки веб-приложений. Ionic Framework поддерживает код JavaScript, написанный с использованием фреймворков React, Vue.js и Angular.

В реальности инструментарий не ограничен. Например, можно написать часть продукта (чаще всего специфическую бизнес-логику) на C++, а получившуюся библиотеку можно будет встроить, как в нативный код, так и в кроссплатформенный.

Аргументы за

• Меньшие затраты. По разным оценкам разнятся экономия относительно нативной разработки может составлять 30-80%. Наш опыт показывает, что сэкономив на этапе разработки, можно потерять больше на этапе поддержки. В любом случае нужна только одна команда, которая хорошо разбирается в выбранном фреймворке.
  ‍
• Единая кодовая база. Повторное использование кода гарантирует, что приложение будет вести себя одинаково на всех платформах с минимальным количеством ошибок.
  ‍
• Упрощённая поддержка. На обновление кроссплатформенного приложения требуется меньше ресурсов, поскольку кодовая база одна — изменения вносятся именно в неё.

Аргументы против

• Увеличенный размер. Фреймворк, уровень связанности кода и плагины могут почти вдвое увеличить размер файла. Такие приложения не только требуют больше места для хранения на устройстве, но также больше времени и данных для загрузки.
  ‍
• Хуже адаптивность. Кроссплатформенные интерфейсы не всегда успешно подстраиваются под особенности устройств, и пользователь может заметить «ненативное» поведение приложения.
  ‍
• Сложная интеграция. Кроссплатформенные фреймворки поддерживают не все специфические функции ОС, поэтому отдельные части нужно создавать нативно.
  ‍
• Более низкая производительность. В кроссплатформенных фреймворках уровень вычислений выше — это снижает производительность.
  ‍
• Долгое ожидание обновления. Для доступа к новым возможностям ОС необходимо ждать отдельного обновления функциональности.
  ‍
• Кроссплатформенным приложениям сложнее получить фичеринг в App Store и Google Play.

Примеры приложений

• Skype, Facebook (React Native)
  ‍
• Google Play, Toyota, BMW (Flutter)
  ‍
• The World Bank, Alaska Airlines (Xamarin)

Когда нужна кроссплатформенная разработка?

• Для быстрого запуска на разных платформах при ограниченных ресурсах.
  ‍
• Целевая аудитория использует устройства и на iOS, и на Android.
  ‍
• Приложению не нужны специальные возможности ОС, у него нет сложного дизайна и графики.

Гибридный подход

Фактически это смесь нативных и любых других решений. Разработчики пишут ядро на любом нужном языке (JavaScript, Dart, С# или любом другом), а затем встраивают его в нативное приложение с помощью плагинов — например, Apache Cordova или Ionic. Они позволяют разработчикам получить доступ к нативным функциям. Для гибридного метода применяют фреймворки и SDK: React Native, Ionic, Xamarin, Flutter, NativeScript.

Иногда говорят, что гибрид и кроссплатформа — это одно и то же. Но их объединяет только возможность многократного использования кодовой базы.

Разработка гибридов может быть очень экономичной и быстрой по сравнению с другими методами. Например, создатели упомянутого Ionic говорят о сокращении времени разработки в 2-3 раза. Пользовательский опыт достойный, есть единая кодовая база. Однако добиться многофункционального интерфейса или высокой производительности в них сложнее, чем, например, в нативных продуктах.

Гибридный подход хорош для MVP и продуктов с очень сжатыми сроками планируемого релиза. Мы в arcsinus периодически используем гибридный подход при разработке — например, для создания мобильного приложения с конструктором укладки напольных покрытий известного производителя. Ключевая бизнес-логика была разработан на универсальном C++, чтобы впоследствии его можно было встроить в любой продукт для любой платформы — мобильное приложение или веб-сайт.

Заключение

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

Пример Airbnb: cначала они работали с React Native, чтобы написать код один раз и быстро распространить приложение. Позже приоритеты и цели бизнеса изменились — потребовалась более высокая производительность и ускоренная разработка. Компания переключилась на создание нативных приложений.

Поэтому нельзя определённо утверждать, что один метод разработки хуже, а другой лучше. Они просто разные, и их стоит рассматривать как бизнес-инструменты для различных задач.

‍

___________
*Meta, в том числе её продукты Facebook и Instagram, признана экстремистской организацией в России.