← назад к разделу

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

Как раньше делали мобильные приложения

Исторически мобильное приложение означало «отдельное приложение для iOS и отдельное для Android». iOS пишется на Objective-C или Swift, Android — на Java или Kotlin. Это два разных языка, два разных проекта, две команды. Любая новая функция реализуется дважды.

Для больших компаний это приемлемо. Для небольших команд или одиночных разработчиков — слишком дорого. Именно поэтому появились гибридные и web-first подходы.

Три подхода

Натив

Приложение написано на платформенном языке: Swift для iOS, Kotlin для Android. Или на кросс-платформенном фреймворке — React Native или Flutter — который из одной кодовой базы собирает два нативных приложения.

Преимущества: полный доступ ко всем платформенным возможностям, наилучшая производительность, точное соответствие платформенным паттернам интерфейса. Цена: отдельная кодовая база, отдельные навыки, отдельный цикл выпуска.

Гибрид

Веб-приложение, исполняемое внутри нативного WebView-контейнера. Логика и разметка — те же HTML, CSS и JavaScript, что в браузере, но завёрнутые в нативную оболочку и опубликованные в сторах.

Web-first

Это дисциплинированный гибрид. Одна кодовая база на React и TypeScript доводится до PWA (service worker, web app manifest, работа офлайн), а затем упаковывается в нативную WebView-обёртку через Capacitor для публикации в App Store и Google Play.

Тот же код живёт и как сайт в браузере, и как устанавливаемая PWA, и как приложение в сторе. Одна кодовая база — три канала распространения.

Как работает web-first на практике

Capacitor — это инструмент, который берёт готовую веб-сборку и упаковывает её в нативные проекты для iOS и Android.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm install @capacitor/ios @capacitor/android
npx cap add ios
npx cap add android
npx cap sync

cap add генерирует нативные проекты Xcode и Android Studio. cap sync копирует собранную веб-часть в них и подтягивает зависимости плагинов. Веб-код остаётся источником правды — нативная оболочка это транспорт в сторы.

Доступ к платформенным возможностям не теряется. Capacitor предоставляет мост к нативным API через плагины: камеру, геолокацию, push-уведомления подключают как обычные npm-пакеты.

npm install @capacitor/camera @capacitor/geolocation @capacitor/push-notifications
npx cap sync

import { Camera, CameraResultType } from "@capacitor/camera";

async function takePhoto() {
  const photo = await Camera.getPhoto({
    quality: 90,
    resultType: CameraResultType.Uri,
  });
  return photo.webPath;
}

Тот же вызов работает и в WebView на телефоне, и в браузере — там Capacitor подставляет веб-реализацию.

Что выигрываешь и что теряешь

Web-first экономит время и деньги на старте: одна кодовая база вместо трёх (веб + iOS + Android), один язык, один набор навыков — те, что уже есть у frontend-разработчика. Баг чинится один раз, а не трижды. Правки веб-части доставляются без выпуска новой версии в стор.

Цена тоже честная. Веб в WebView уступает нативу в трёх местах:

  • Глубокие платформенные API — то, чего нет в готовых плагинах, потребует писать нативный плагин вручную.
  • Пиковая производительность — тяжёлая графика, сложные жесты, обработка видео в реальном времени.
  • Нативный UX — тонкие нюансы анимаций, скролла и платформенных паттернов, которые требовательный пользователь чувствует.

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

Как выбрать

Простое правило: web-first по умолчанию, натив — когда необходимость доказана.

Берите web-first, если:

  • приложение — это CRUD-интерфейс поверх API;
  • команда уже работает с React и TypeScript;
  • скорость выхода важнее последних процентов качества UX.

Смотрите в сторону натива (React Native или Flutter, чтобы не плодить два независимых стека), если:

  • продукт строится вокруг тяжёлой графики, дополненной реальности или сложной работы с камерой;
  • нужны фоновые задачи, которых нет в готовых плагинах;
  • нативный UX — само ядро ценности продукта.

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

Коротко

  • Три подхода: натив (Swift/Kotlin или React Native/Flutter), гибрид (WebView-обёртка), web-first (дисциплинированный гибрид: PWA + Capacitor).
  • Web-first — одна кодовая база на React и TypeScript, три канала: браузер, PWA, стор.
  • Capacitor генерирует нативные проекты и предоставляет мост к платформенным API через npm-плагины.
  • Слабые стороны web-first: глубокие платформенные API, пиковая производительность, тонкости нативного UX.
  • Для большинства продуктовых приложений (формы, списки, чаты) разница с нативом незаметна.
  • Выбирайте web-first по умолчанию; переходите в натив только там, где это доказанно необходимо.

Что почитать дальше

  • PWA: устанавливаемое веб-приложение — service worker, web app manifest, работа офлайн.
  • Capacitor: упаковка в стор — нативные проекты, плагины, мост к API.
  • Нативные API через Capacitor — камера, геолокация, файловая система.
  • Push-уведомления — как подключить и настроить.
  • Когда нужен натив — критерии перехода от web-first к нативному стеку.