Кроссплатформенная разработка приложений

Приложение состоит из трёх слоёв. Общий код содержит интерфейс и логику - это основная часть проекта, около 85-90% объёма. Мост Capacitor связывает его с платформой. Нативные плагины закрывают то, чего в веб-слое нет.

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

Границу правильнее назвать самому, чем услышать её от конкурента после подписания договора. Есть три класса задач, где кроссплатформенный подход честно хуже.

• Игры и тяжёлая графика: всё, где нужен стабильный кадр в сложной 3D-сцене
• Постоянная фоновая работа с железом: непрерывный трекинг маршрута, обработка звука в реальном времени, длительная работа с Bluetooth
• Приложения, весь смысл которых в самой свежей системной возможности через неделю после презентации Apple

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

Второй фактор - скорость исправлений. В гибриде правка в веб-слое доезжает до пользователей обновлением по воздуху, без ожидания ревью. Для продукта, который активно развивается, это недели сэкономленного времени за год.

Третий фактор редко озвучивают: гибридное приложение делает один человек. Нативная разработка требует минимум двух специалистов, и вопрос замены каждого из них становится вашим риском.

Тот же код даёт браузерную версию продукта. Это не всегда нужно, но там, где нужно, экономит отдельный проект: личный кабинет в вебе и приложение в сторах живут из одного репозитория.

На платформе событий так и сделано: приложение участника на iOS и Android и панель организатора в вебе используют общую основу, поэтому изменения в логике не приходится повторять в трёх местах.

Ключевой вопрос один: писали ли вы нативные плагины сами. Разница между командой, которая собирает приложение из готовых библиотек, и инженером, который может спуститься на уровень Swift или Kotlin, становится критичной ровно в тот момент, когда нужной библиотеки не оказывается.

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