Я Алексей, разработчик Appex.Media. Выбор технологии для приложения кажется сугубо техническим вопросом, но он напрямую влияет на бюджет, сроки, скорость выхода новых функций и то, что приложение вообще сможет делать. Ошибка на этом этапе обнаруживается через год, когда понадобится функция, которую выбранная технология поддерживает плохо, или когда поддержка двух отдельных приложений начнёт съедать бюджет на развитие. Ниже объясню разницу простыми словами, расскажу, как выбираем мы, и покажу, когда приложение лучше заменить сайтом или ботом.
Чего опасаются заказчики
Заказчики обычно приходят с двумя противоположными страхами. Первый: «кроссплатформа это дёшево и медленно, приложение будет тормозить». Он остался с тех времён, когда такие технологии действительно были сырыми. Второй: «натив это вдвое дороже, нам не по карману». Он верен лишь отчасти, потому что разница в цене зависит от функций, а для простых приложений бывает меньше, чем кажется. Правильный выбор начинается с вопроса, что именно должно делать приложение, и только потом с вопроса о технологии.
Нативная разработка
Для iPhone приложение пишут на Swift, для Android на Kotlin. Получается два отдельных приложения с двумя кодовыми базами. Каждое из них написано на «родном» языке платформы и использует её стандартные инструменты.
Плюсы: максимальная производительность, полный доступ к возможностям устройства (камера, датчики, Bluetooth, работа в фоне), интерфейс полностью соответствует привычкам пользователей каждой платформы, новые функции iOS и Android доступны сразу после их выхода.
Минусы: две команды или двойной объём работы, дольше и дороже разработка и поддержка. Каждую новую функцию нужно сделать и протестировать дважды, и версии для iOS и Android со временем могут расходиться.
Кроссплатформенная разработка
Одна кодовая база работает на обеих платформах. Самые популярные инструменты: Flutter от Google и React Native от Meta. Код пишется один раз, а на выходе получаются два приложения для двух магазинов.
Плюсы: заметно меньше затрат на разработку и поддержку, функции выходят одновременно на iOS и Android, проще найти и масштабировать команду. Для бизнеса это значит, что тот же бюджет позволяет сделать больше функций или выйти на рынок раньше.
Минусы: сложные анимации, работа с нестандартным оборудованием и некоторые системные функции требуют дополнительной нативной разработки. Новые возможности платформ появляются с задержкой, пока их не поддержит сам инструмент. Размер приложения обычно немного больше.
Flutter или React Native
Оба инструмента зрелые и используются в крупных приложениях. Flutter рисует интерфейс сам, поэтому приложение выглядит одинаково на всех устройствах и хорошо подходит для насыщенного визуального дизайна. React Native использует системные элементы интерфейса и удобен, если у вас уже есть веб-команда на JavaScript и React: часть логики можно переиспользовать между сайтом компании и приложением. В профильных сообществах на Reddit разработчики спорят о выборе годами, и общий вывод обычно такой: оба подходят для большинства бизнес-приложений, а решает опыт команды, которая будет приложение развивать.
Как мы выбираем
- Каталог, запись, личный кабинет, программа лояльности, доставка: кроссплатформа почти всегда оптимальна.
- Тяжёлая работа с камерой, AR, фоновые задачи, Bluetooth-устройства, игры: нативная разработка или гибрид.
- Ограниченный бюджет и нужно проверить идею: кроссплатформенный MVP, а нативные модули добавляем при необходимости.
- Есть своя веб-команда на React: смотрим в сторону React Native, чтобы она могла участвовать в развитии.
Три типовые задачи и наш выбор
Кофейня или салон с бонусами и онлайн-записью. Главное здесь быстро выйти на обе платформы и регулярно добавлять акции, поэтому выбираем кроссплатформу. Возможностей Flutter или React Native хватает с запасом, а бюджет уходит на функции, которые возвращают клиентов.
Приложение для выездных мастеров или курьеров. Нужны геолокация, фото с камеры, работа без интернета и синхронизация, когда связь появится. Обычно это кроссплатформа с нативными модулями для работы в фоне и камеры: так мы получаем одну кодовую базу и надёжную работу там, где она критична.
Сервис, который управляет внешним устройством по Bluetooth, или приложение с дополненной реальностью. Здесь каждая задержка заметна пользователю, а доступ к оборудованию нужен глубокий. Выбираем нативную разработку, иначе большая часть кода всё равно будет написана отдельно под каждую платформу.
Гибридный подход
Выбор не обязательно делать раз и навсегда. Основная часть приложения пишется кроссплатформенно, а отдельные модули, которым нужны возможности устройства, делаются нативно и подключаются к общему коду. Так работает большинство наших проектов среднего размера: например, приложение с каталогом и записью на кроссплатформе, а модуль работы с камерой для сканирования документов на нативном коде.
Как технология влияет на бюджет и сроки
Для типового бизнес-приложения кроссплатформенная разработка обычно заметно дешевле двух нативных. Экономия продолжается и после запуска: исправление ошибки или новая функция делается один раз. Нативная разработка оправдывает себя, когда приложение и есть продукт компании, а его качество и скорость напрямую влияют на выручку, например в банковских, медицинских или игровых сервисах. Ориентиры по стоимости разработки собраны в статье «Сколько стоит разработка мобильного приложения».
Поддержка и обновления
Каждый год Apple и Google выпускают новые версии систем и меняют требования магазинов. Нативное приложение получает доступ к новинкам сразу, но обновлять приходится два проекта. Кроссплатформенное ждёт, пока инструмент поддержит изменения, зато обновление делается один раз. Для бизнеса важнее второе: стабильный бюджет на поддержку и предсказуемые сроки. Перед стартом стоит спросить подрядчика, как часто он обновляет приложения под новые версии систем и сколько это стоит.
Ошибки при выборе технологии
- Выбирать модную технологию без оглядки на то, кто будет поддерживать приложение через два года.
- Сразу делать два нативных приложения для проверки идеи, у которой ещё нет пользователей.
- Не учитывать функции второй версии: если через год понадобится AR или работа с внешними устройствами, это стоит обсудить сейчас.
- Не проверять приложение на недорогих телефонах, которыми пользуется значительная часть аудитории.
А может, вообще не приложение?
Иногда задачу лучше решает веб-приложение (PWA) или Telegram-бот: их не нужно скачивать из магазина, и запускаются они быстрее. Если пользователи будут открывать сервис раз в месяц, скачивать приложение ради этого они вряд ли станут. PWA можно добавить на главный экран телефона, и выглядит оно почти как приложение. Telegram-бот хорошо подходит для записи, уведомлений и простых заказов, а ИИ-агент в мессенджере ещё и отвечает на вопросы клиентов по вашей базе знаний. Подробнее о том, когда приложение окупается, в статье «Мобильное приложение для бизнеса».
Что вы получите
- Обоснованный выбор технологии под ваши задачи и бюджет.
- Оценку стоимости для разных вариантов.
- Приложение, которое легко поддерживать и развивать.
Частые вопросы
Заметит ли пользователь, что приложение кроссплатформенное?
В типовом бизнес-приложении, сделанном аккуратно, обычно нет. Разница видна в сложных анимациях и тяжёлых сценариях вроде обработки видео.
Можно ли потом переписать приложение на натив?
Можно, и серверная часть при этом останется прежней. Но чаще достаточно переписать нативно отдельные модули.
Что выбрать для MVP?
Почти всегда кроссплатформу: она позволяет быстрее выйти на обе платформы и проверить идею с меньшим бюджетом.
Опишите, что должно уметь ваше приложение, и я порекомендую технологию с оценкой сроков и бюджета. Получить консультацию по разработке приложения.
Алексей, разработчик Appex.Media
