С Новым годом, Хабр. Меня зовут Илья, я работаю Frontend разработчиком в компании Бастион. Январские выходные в самом разгаре, но уже многие, включая меня, наобещав себе свернуть горы в этом году, находятся в поиске полезной для мозга информации. Тогда присаживайтесь поудобнее, ибо сейчас мы будем разговаривать о такой замечательной технологии для разработки гибридных мобильных приложений, как Capacitor.

Начнем с сухого определения:

Capacitor — это среда выполнения с открытым исходным кодом для создания гибридных мобильных приложений для iOS, Android и PWA.

Понятно, но зачем нам это нужно? Самую большую пользу данная технология принесет командам, у которых уже есть готовое веб-приложение и нет времени или денег на переписывание всего этого добра на натив или другие кроссплатформенные решения.

Именно в этом случае идеально подходит Capacitor.

Проблема

Предположим, у вас есть:

  • SPA на React / Vue / Angular и т.д;

  • бизнес-задача: выйти в App Store и Google Play;

Варианты:

  1. Переписать все нативно. Дорого, долго и, как правило, нужны две команды. Не наш вариант.

  2. React Native. Вариант рабочий, но со своей специфичной экосистемой Expo / Metro. Все равно придется переписывать код из-за отсутствия DOM.

  3. Flutter. Переписать вообще все, да еще и на новом языке. Не наш вариант.

  4. Упаковать веб-приложение и дать ему доступ к нативным API. А вот это уже зона ответственности Capacitor.

Четвертый вариант, как правило, в общественном сознании считается плохим. Все из-за наследия Cordova.

Capacitor — это попытка сделать этот вариант как минимум приемлемым, а не последним выбором в стеке и то из-за безысходности.

Что такое Capacitor на самом деле

Архитектурно:

  • приложение работает в WebView;

  • поверх него есть bridge к нативным API;

  • iOS и Android — полноценные нативные проекты со своей файловой структурой;

Структура проекта выглядит примерно так:

  • dist/ — билд веб-приложения;

  • ios/ — Xcode-проект;

  • android/ — Gradle-проект;

  • плагины — npm-пакеты, мост между JS и Swift / Kotlin / Java;

Важно: Capacitor ничего от вас не скрывает. Вы можете в любой момент открыть Xcode или Android Studio и писать нативный код, если это необходимо.

Почему это не Cordova 2.0

Cordova:

  • динамически подгружала плагины;

  • имела устаревший API;

  • часто ломалась при обновлении SDK;

  • делала нативную часть магической коробкой.

Capacitor:

  • генерирует полноценные нативные проекты;

  • использует современные API iOS и Android;

  • плагины пишутся как обычные нативные модули;

  • обновляется синхронно с платформами.

Если упростить: Cordova пыталась спрятать натив, Capacitor, наоборот, делает его явным.

Capacitor vs нативная разработка

Критерий

Native

Capacitor

Время до релиза

Долго

Быстро

Команды

iOS + Android

Веб

Кодовая база

2

1

Производительность

Максимальная

Близкая к нативной

Обновления

Только через сторы

Возможны OTA

Доступ к API

Прямой

Через плагины

Capacitor — это не замена нативной разработке, но для большинства бизнес-приложений, админок, маркетплейсов, клиентских и внутренних систем разница в производительности не является критичной. А вот разница во времени разработки и стоимости вполне ощутима.

Capacitor vs React Native

Критерий

React Native

Capacitor

UI

Нативные компоненты

HTML / CSS

Совместимость с вебом

Частичная

Полная

Миграция существующего SPA

Сложная

Почти бесплатная

Экосистема

Большая, но разрозненная

Простая и предсказуемая

React Native делает вас мобильным разработчиком, который пишет на JavaScript.
Capacitor делает ваше веб-приложение мобильным.

Это принципиально разные подходы. Один не лучше другого, они решают разные задачи.

Почему именно сейчас Capacitor стал адекватным выбором

Здесь несколько факторов:

  • WebView давно стал быстрым и стабильным;

  • веб-фреймворки научились работать офлайн и эффективно кэшировать данные;

  • TypeScript стал стандартом;

  • CI/CD для мобильных приложений перестал быть экзотикой;

Когда Capacitor — плохая идея

  • игры и тяжелая графика;

  • сложные анимации;

  • жесткая зависимость от проприетарных SDK;

  • требования к максимальному FPS;

В этих случаях стоит выбрать нативную разработку или специализированные фреймворки.

Что будет дальше

Это вводная статья из цикла материалов про Capacitor. Дальше будет больше практики:

  • миграция на Capacitor: чек-лист и реальные баги;

  • как написать свой плагин для Capacitor;

  • CapacitorUpdater и Capgo: безопасные обновления в обход сторов (обновленная статья);

  • CI/CD для Capacitor;

  • интеграция Firebase / Push / Background handlers;

  • производительность: как профилировать WebView и сократить bridge calls;

  • PWA, Electron, Capacitor Desktop: что выбрать и почему;

  • сборка готового приложения;

  • Security & Privacy checklist перед публикацией;

На этом у меня все. Пишите любые интересующие вас вопросы в комментарии и в личку.

Ссылки:

Комментарии (11)


  1. Bardakan
    05.01.2026 12:35

    у вас сборка готового приложения почему-то идет в самом конце. Может ее стоит вынести куда-то в начало, а потом уже будут статьи про "навороты"?


    1. sudondie Автор
      05.01.2026 12:35

      В целом имеет смысл вынести ее после темы про плагины, как раз уже будет готовый тестовый проект который можно собрать. Пожалуй так и сделаю. Спасибо за комментарий


  1. ASGAlex
    05.01.2026 12:35

    Есть у нас приложение, 2018 года рождения, писали на React под Electron. В ходе эволюции прикрутили туда ещё и Cordova, где-то тогда же, в 18-19 году...

    Годы идут, разработчики меняются, несколько раз из-за недостаточной информированности пробовали скомпилить под мобилку капаситором. Но ничего с пол пинка не заводилось. В итоге на текущий момент у нас причесанная схема сборки под Electron и Cordova, и, в целом, не видим причин с неё съезжать. Разве что там совсем поддержку прекратят... Но, вроде, не прекращают.

    Это я к чему: закидываю заявку на рассказ, есть ли реально какие-то бенефиты от перехода на капаситор для уже написанного проекта, кроме "ну теоретически он более современный"? Что-нибудь, ради чего действительно стоит страдать? Ну и про Capacitor Desktop тоже интересно, насколько он лучше/хуже Electron. У нас целая эпопея, чтобы оно заработало и в windows, и в разношёрстном разнообразии российских Линуксов, которые каждый на свой лад работают и порой требуют персональных фиксов.... Некоторые из которых мы даже не могли применить, пока не провели работу по обновлению реакта и электрона до последних версий, где нужные фичи только появились.

    А то когда разработка выходит из стадии Hello World в стадию "большое приложение с наследием" - открывается много чего, о чем в туториалах не говорили :-)


    1. sudondie Автор
      05.01.2026 12:35

      Спасибо за подсказку для раздела следующей статьи. Расскажу про преимущества для старых проектов


  1. Gumus171991
    05.01.2026 12:35

    Раз уж сравнили Capacitor с нативными штуками как React Native, то хотелось бы увидеть сравнение и с похожими технологиями. Например, с Tauri


  1. codecity
    05.01.2026 12:35

    Имх, имеет смысл. Возможно посмотрю. Но мы привыкли что подобные продукты разрабатывают корпорации, а не одиночки, по этому серьезно никто не относится.


    1. sudondie Автор
      05.01.2026 12:35

      Из крупных игроков его используют Electronic Arts,и, если не ошибаюсь, мобильное приложение Burger King. Хотя это спокойно может быть просто WebView а не конкретно Capacitor


  1. martrix
    05.01.2026 12:35

    Увы, капаситор, как и кордова сейчас никому не интересны. Как и Ionic ....


    1. sudondie Автор
      05.01.2026 12:35

      Попытаюсь это исправить


      1. martrix
        05.01.2026 12:35

        Увы, сомневаюсь что получится. В моде React и как следствие React Native. Хотя для простых, ненагруженных приложений, Webview и мост Cordova/Capacitor вполне себе. Знаю несколько довольно успешных приложений на этом стеке. Но как только дело касается производительности или натива - этот стэк сдувается.


        1. ASGAlex
          05.01.2026 12:35

          ...и это хорошо же, так и должно быть, пусть так будет и дальше. Не хочется, чтобы требования к железу телефонов росли так же, как требования к ПК, потому что программисты не хотят ни о чем думать, а хотят писать на своем любимом js - и не важно, какая задача.