WebTeamStorm 
Тендеры и лиды
Информация
В предыдущем материале я разобрал ситуацию с тремя самыми доступными способами разработки мобильных приложений, а также основными их плюсами и минусами. Рекомендую ознакомиться с ним, прежде чем переходить к следующим вариантам, особенно если вы сейчас только анализируете рынок. Более того, под конец составим сводную таблицу, где соберем основные тезисы и особенности каждого из вариантов.
Следующие варианты уже ближе к полноценной разработке заказного продукта. Они дают значительно больше свободы, но вместе с этим требуют больших бюджетов и более серьезного подхода к архитектуре и поддержке.
В основном предыдущие решения сводились к простой формуле: меньше стоимость, но и меньше функциональность. Если ваши бюджеты позволяют или задачи не лежат в плоскости “создания простеньких страничек”, то для вас открывается куда более широкий перечень возможностей.
React Native (кроссплатформенная разработка) — уже более серьезное решение по сравнению с вариантами, которые мы рассмотрели ранее. Специалистов на этом стэке достаточно много, а его инструменты позволяют реализовать достаточно объемные и функциональные приложения.
Вы уже не так сильно зависите от ограничений сторонней платформы. Правильная архитектура позволяет создать более сложное ПО с последующей поддержкой без боязни упереться в лимиты, а пользователи будут ощущать более шустрые интерфейсы. При этом исходный код остается у вас.
Например, среди наших кейсов можно ознакомиться с VurvHealth - достаточно большое и многофункциональное приложение в США, с множеством внутренних интеграций, которые открывают доступ к медицинским услугам клиник.
Кроссплатформа может выйти от 250–350 тыс. руб. и ценовой потолок будет упираться лишь в объем поставленных целей или заложенных фантазий.
Впрочем, минусы у данного варианта все же есть. При этом очень крупные и сложные приложения могут потребовать дополнительной оптимизации. Особенно это становится заметно при большом количестве тяжелых анимаций, сложных вычислений, больших списков и активном использовании нативных функций устройства.
Сборка Android и iOS-проектов может потребовать больше ручной настройки и иногда доставляет разработчикам больше проблем при обновлении зависимостей или подготовке релиза.
Flutter (высокопроизводительная кроссплатформа) — на самом деле для большинства предпринимателей этот вариант будет тот потолок, который переступать особо не имеет смысла.
Ощущения от продуктов на Flutter — немного лучше RN за счет более высокопроизводительного кода, а реализовать можно хоть небольшой органайзер для записи, хоть крупную площадку для селлеров. В правильных руках разработчика можно развивать продукт годами особо не заморачиваясь над объемом внутреннего контента. Ну, и сборка значительно проще, быстрее, что не доставит лишней головной боли программисту перед дедлайном.
Стоимость, разумеется, будет повыше. Тут средняя кроссплатформа редко может выйти дешевле 300–400 тыс. руб.
Кроме этого, в предыдущих двух вариантах есть еще пара бонусов - например, можно собирать отдельную версию приложения под Huawei AppGallery (особенно актуально в текущей парадигме), а про второй напишу чуть ниже.
Kotlin/Swift (нативное приложение) — разработка на нативных языках является самым дорогим вариантом из рассмотренных, поскольку для Android и iOS фактически создаются отдельные версии приложения.
Данный вариант подходит в том случае, если у вас очень сложные графические интерфейсы, требующие хорошей оптимизации и использования ресурсов смартфона. Нативный подход также может быть оправдан для крупного корпоративного ПО, если проект активно использует возможности конкретной платформы или предъявляет повышенные требования к производительности.
По цене здесь все еще суровее и вряд ли на момент написания материала средние предложения опустятся ниже 500 тыс. руб. Я бы сказал, что реальные бюджеты чаще начинаются примерно от 1–2 млн. руб.
Данная опция также лишена упомянутых бонусов выше.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13731 тендер
проведено за восемь лет работы нашего сайта.
PWA (Progressive Web App) — на самом деле это уже дополнительный вариант, который можно использовать для создания мобильного продукта. Да, способов как их сделать действительно много, поэтому я изначально и решил дробить материалы, чтобы не перегружать сразу дополнительной информацией.
Однако, я все-таки вынес его как дополнительные, а не основной способ разработки, так как это не отдельное нативное приложение, а веб-приложение, которое можно установить на устройство и использовать практически как обычное мобильное приложение.
Flutter и React Native позволяют предусмотреть веб-версию приложения на этапе разработки, однако для этого все равно потребуется отдельная настройка и адаптация интерфейса. При этом PWA можно рассматривать как дополнительный канал доступа к сервису. Если приложение критически важно для бизнеса, наличие веб-версии позволяет сохранить доступ к основным функциям даже в ситуации, когда мобильное приложение временно недоступно в магазине.
Подойдет для небольших платежных систем, инструментов, фитнес трекеров или магазинчиков.
Восприятие и скорость работы, разумеется, не будет особо отличима от обычного сайта, но все же есть ухищрения, например с кэшированием файлов, чтобы было быстрее.
Самая распространенная ошибка, с которой я сталкиваюсь регулярно и по сей день, — обратиться сразу с вопросом: «Сколько стоит мобильное приложение?». Особенно если ранее не были подготовлены хоть какие-то начальные материалы: прототип, наброски, бриф или краткое ТЗ.
На данный вопрос невозможно дать нормальный ответ, пока не станет ясно, что именно должно быть внутри и какие объемы заказчик готов заложить в разработку. Приложение для записи в салон красоты и медицинский сервис с интеграциями, личным кабинетом и онлайн-оплатой — это совершенно разные по всем параметрам продукты, даже если оба формально называются «мобильным приложением».
Поэтому я бы советовал начинать не с технологии и даже не с бюджета, а с описания задач, которые приложение должно решать. Какие действия совершает пользователь? Нужна ли регистрация? Оплата? Push-уведомления? Интеграция с CRM? Геолокация? Работа с камерой? Нужна ли отдельная административная панель и серверная часть?
После этого уже можно выбирать технологию и получать адекватную оценку.
При этом хорошая оценка должна включать не только разработку интерфейса, а полный перечень работ, необходимых для запуска приложения.
И еще один важный момент: если подрядчик на основании двух предложений сразу называет точную стоимость разработки, я бы отнесся к такой оценке крайне осторожно. На старте гораздо честнее получить вилку стоимости и список допущений, а уже после детальной проработки требований переходить к точной оценке.
Как я и обещал в начале, заканчиваем статью сравнительной таблицей, где каждый может определить подходящую под его бизнес и задачу - решение.
Если отбросить маркетинг и посмотреть на вопрос исключительно с точки зрения бизнеса, то выбор получается довольно простым. WebView и PWA позволяют дешево проверить гипотезу, AI хорошо подходит для прототипирования, коробочные решения — для типовых задач. Если же приложение является полноценным коммерческим продуктом с планами на развитие, я бы в большинстве случаев смотрел в сторону React Native или Flutter. Нативную разработку имеет смысл выбирать тогда, когда ее дополнительные возможности действительно нужны бизнесу.
P.S.
Если после прочтения у вас остались вопросы по выбору технологии или вы пока не понимаете, какой вариант подойдет именно вашему проекту, можете обратиться к нам в личные сообщения или через Workspace.
Поможем оценить задачу, подобрать подходящий вариант разработки и сориентировать по возможному бюджету — без привязки к какой-то одной технологии.
