Нативная или кроссплатформенная разработка: как выбрать подход к мобильному приложению

В каждом проекте мобильного приложения рано или поздно встаёт этот вопрос: разрабатывать отдельно для iOS и Android с помощью собственных нативных инструментов каждой платформы (Swift/Kotlin) или один раз написать приложение на кроссплатформенном фреймворке вроде Flutter или React Native и выпустить его на обе платформы из общей кодовой базы. Универсально правильного ответа нет: в умелых руках оба подхода дают отличные приложения, и выбор зависит скорее от того, что приложение должно уметь, чем от того, какой вариант звучит современнее.

Что даёт нативная разработка

Нативная разработка — это работа напрямую с SDK каждой платформы и полный доступ ко всем новым возможностям ОС с первого дня, как только Apple или Google их выпускают. Производительность здесь, как правило, максимальная, особенно для всего, что связано с интенсивной графикой, обилием анимаций или тесной интеграцией с железом: обработка изображения с камеры, дополненная реальность, отслеживание местоположения в фоне, сложное объединение данных с датчиков. Кроме того, приложение выглядит и ощущается в точности как родное для своей платформы, потому что построено на её собственных UI-компонентах, а не на общем слое абстракции, который пытается приблизительно воспроизвести обе.

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

Что даёт кроссплатформенная разработка

Фреймворки вроде Flutter и React Native позволяют написать большую часть приложения один раз и выпустить его и на iOS, и на Android. Для огромного числа реальных приложений это действительно серьёзная экономия и времени разработки, и затрат на дальнейшую поддержку: в большинстве бизнес-приложений, контентных приложений и приложений для электронной коммерции, а также в большинстве внутренних инструментов подавляющая часть кода приходится на бизнес-логику, вызовы API, формы и стандартный интерфейс, а не на глубокую платформенную специфику, где у нативной разработки есть явное преимущество.

Современные кроссплатформенные фреймворки во многом сократили отставание по производительности, которое раньше было весомым аргументом против них. Flutter, в частности, компилируется в нативный код и сам отрисовывает интерфейс, а не работает через JavaScript-мост, и в подавляющем большинстве приложений пользователи разницы не замечают. Где кроссплатформенные решения всё ещё отстают, так это в доступе к совсем новым возможностям ОС с первого дня (обычно проходит какое-то время, прежде чем фреймворк поддержит то, что Apple или Google только что анонсировали), а также в по-настоящему требовательных к железу сценариях, где нужен абсолютный потолок производительности, доступный только нативной разработке.

Как сделать выбор на практике

• Выбирайте нативную разработку, если для приложения критичны графика или производительность (игры, AR, интенсивная обработка в реальном времени), нужен глубокий и немедленный доступ к новым возможностям ОС или если на двух платформах приложение действительно должно вести себя очень по-разному, а не разделять большую часть логики.
• Выбирайте кроссплатформенную разработку, если вы создаёте типичное бизнес-приложение, контентное приложение, приложение для электронной коммерции или утилиту; если нужно двигаться быстро и проверить продукт на обеих платформах, не удваивая команду; или если бюджет ограничен и поддерживать две полноценные нативные кодовые базы нереально.
• Рассмотрите гибридный подход: кроссплатформенная разработка для большей части приложения и нативный модуль для той единственной функции, которой он действительно нужен. Большинство крупных фреймворков это поддерживают без необходимости всё переписывать.

Решение, которое важнее выбора технологий

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

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