Заказчик из корпоративного или госсектора почти всегда задаёт один вопрос: писать приложение нативно под iOS и Android, взять кросс-платформенный фреймворк или ограничиться Progressive Web App. Универсального ответа нет – выбор диктуют требования к устройству, бюджет на поддержку и режим работы пользователя. Разберём три подхода по делу.
Нативная разработка: контроль и доступ к железу
Нативное приложение пишут на Swift или Objective-C под iOS и на Kotlin или Java под Android. Вы получаете полный доступ к камере, NFC, биометрии, фоновым службам и push-уведомлениям без прослоек. Производительность предсказуема, интерфейс соответствует гайдлайнам платформы, а новые API из iOS 11 и Android 8 доступны сразу.
Цена за это – две кодовые базы и две команды. Бюджет и сроки фактически удваиваются, поддержка тоже. Нативный путь оправдан там, где приложение – основной канал работы с клиентом или сотрудником: мобильный банк, полевые приложения с офлайн-режимом, решения с интенсивной работой с датчиками. Для госсектора добавьте ещё один фактор: если приложение становится частью значимого объекта критической информационной инфраструктуры, требования к защите вы закладываете на старте, а не латаете потом – об этом мы писали в материале про ГосСОПКА и категорирование КИИ.
Кросс-платформа: одна команда на две системы
React Native и набирающий обороты Flutter позволяют держать общую логику и большую часть UI в одной кодовой базе. Экономия на разработке реальна – обычно 30–40% против двух нативных команд. К нативным модулям при необходимости спускаемся через мосты, так что доступ к камере или геолокации остаётся.
Платите за это компромиссами. Сложная анимация и тяжёлая графика идут хуже нативных, отладка мостов отнимает время, а каждое крупное обновление iOS или Android заставляет ждать поддержки от фреймворка. Кросс-платформа – здравый выбор для типовых корпоративных приложений: каталоги, заявки, согласования, личные кабинеты, дашборды. Там, где интерфейс важнее доступа к низкоуровневому железу, выгода очевидна.
PWA: без магазинов и установки
Progressive Web App – это веб-приложение, которое работает офлайн через Service Worker, ставится на домашний экран и шлёт push (на Android; в iOS Safari поддержки push пока нет). Установка не нужна, обновление мгновенное, App Store и Google Play обходим стороной. Одна кодовая база покрывает и десктоп, и мобильные.
Ограничения честные: на iOS возможности PWA урезаны, доступ к Bluetooth, NFC и фоновым задачам частичный, а место в офлайн-кэше ограничено. Зато PWA отлично закрывает внутренние порталы, B2B-сервисы и сценарии, где пользователь приходит по ссылке и не готов ставить приложение. Если вы уже строите бэкенд на контейнерах – см. наш разбор Kubernetes и cloud-native – PWA ложится на ту же инфраструктуру без отдельного релизного цикла под магазины.
Как выбрать
Начните с пользователя и сценария. Нужен ли офлайн, доступ к датчикам, высокая графическая нагрузка – берите нативное. Типовой корпоративный функционал на двух платформах при ограниченном бюджете – кросс-платформа. Быстрый охват без установки и единая база с вебом – PWA. Часто работает гибрид: PWA для широкой аудитории плюс нативный модуль для критичного сценария. Отдельно учитывайте интеграции – чат-бот в приложении мы рассматривали в материале про NLP и чат-боты.
Стек стоит подбирать под задачу, а не наоборот, и закладывать сопровождение продукта после релиза ещё на этапе выбора подхода к мобильной разработке.
