Мобильное приложение — не обязательно отдельная кодовая база на отдельном языке. Для продукт-инженера, который уже владеет frontend на React и TypeScript, есть путь короче: написать приложение как веб-приложение и упаковать его в нативную обёртку для сторов. Это web-first мобильная разработка. Прежде чем выбирать стек, стоит понять три принципиально разных подхода и их цену — потому что выбор здесь определяет, сколько команд, языков и кодовых баз придётся тянуть годами.

Три подхода: web-first, гибрид, натив

Натив — приложение на платформенном языке: Swift (iOS) и Kotlin (Android), либо кросс-платформенный фреймворк React Native или Flutter, дающий из одного кода две сборки. Полный доступ к платформенным API, пиковая производительность, нативный UX — ценой отдельной кодовой базы и отдельного набора навыков.

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

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

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 копирует собранную веб-часть в них и подтягивает зависимости плагинов. Веб-код остаётся источником правды; нативная оболочка — это транспорт в сторы.

Почему продукт-инженеру выгоден web-first

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

Доступ к платформенным возможностям при этом не теряется. Capacitor даёт мост (bridge) к нативным 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 подставляет веб-реализацию). Подробнее про мост и нативные API и push-уведомления — в отдельных статьях.

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

Выигрыш web-first прямой: дешевле и быстрее в разработке, переиспользует frontend-навыки и кодовую базу, единый цикл выпуска для веба и обоих сторов, мгновенная доставка правок веб-части без выпуска в стор. Один баг чинится один раз, а не трижды.

Цена тоже честная. Веб в WebView уступает нативу в трёх местах: доступ к глубоким платформенным API (то, чего нет в готовых плагинах, требует писать нативный плагин руками); пиковая производительность (тяжёлая графика, сложные жесты, обработка видео в реальном времени); и нативный UX — нюансы анимаций, скролла и платформенных паттернов, которые требовательный пользователь чувствует. Для большинства продуктовых приложений — списки, формы, карточки, чаты, панели — этой разницы нет или она в пределах допустимого. WebView современных iOS и Android достаточно быстр, чтобы такой UI был неотличим от нативного.

Как выбрать

Правило: web-first по умолчанию, натив — когда доказана необходимость. Бери web-first, если приложение по сути CRUD-интерфейс поверх API, команда уже на React и TypeScript, а скорость выхода важнее последних процентов UX. Смотри в сторону натива (через React Native или Flutter, чтобы не плодить два нативных стека), если продукт строится вокруг тяжёлой графики, AR, сложной работы с камерой или сенсорами, фоновых задач, которых нет в плагинах, либо когда нативный UX — само ядро ценности продукта.

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

Где это в UCP

Выбор подхода к мобильной разработке — это инженерное решение о границе и цене, а не вопрос моды. Продукт-инженер выбирает web-first ровно по той же логике, по которой выбирает любой инструмент: минимум сущностей, максимум переиспользования, осознанная плата за гибкость только там, где она нужна. Мобильная специализация здесь — прямое продолжение frontend: тот же React и TypeScript, доведённые сначала до устанавливаемой PWA, а затем упакованные в стор через Capacitor.