Технологии разработки мобильных приложений: выбор, этапы и сроки

Технологии разработки мобильных приложений выбирают по задачам продукта: для похожих сценариев на iOS и Android стоит рассмотреть Flutter с общей кодовой базой; для тесной работы с возможностями конкретной платформы — нативную разработку. Стоимость и сроки зависят от состава функций, готовности серверной части и интеграций. До публикации приложение проходит проектирование, разработку, тестирование и проверку магазинов.

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

Что определить до выбора технологии

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

• Аудитория: кто будет пользоваться приложением и какие устройства уже есть у этих людей
• Первая версия: какой законченный сценарий нужно выпустить, а какие функции могут подождать
• Данные: откуда приходят товары, цены, остатки и статусы заказов; кто отвечает за их актуальность
• Устройство: нужны ли камера, геолокация, Bluetooth, работа без сети или в фоне
• Распространение: в каких магазинах и странах продукт должен быть доступен
• Развитие: кто будет сопровождать приложение и какие изменения ожидаются после запуска

Например, в нашем приложении сети «Унидом» покупатели выбирают товары для дома, проверяют наличие в магазинах и оформляют заказы. Для продукта с такими сценариями при оценке нужно выяснить, как получать остатки и передавать заказ. Сам по себе выбор технологии интерфейса этих вопросов не решает.

Нативная или кроссплатформенная разработка: как выбрать

При нативном подходе приложение создают средствами конкретной платформы: например, на Swift для iOS и Kotlin для Android. Эти языки поддерживают сами разработчики платформ — Apple и Android. Для двух ОС потребуется отдельно реализовать платформенные части, хотя сервер, требования и часть проектирования могут быть общими.

Flutter позволяет использовать общую кодовую базу для iOS и Android, включая значительную часть интерфейса и логики. Он использует язык Dart и собственную систему отрисовки. При необходимости разработчики подключают код конкретной платформы — такой способ предусмотрен архитектурой Flutter. Общая база при этом не отменяет отдельные сборки и проверку на обеих ОС.

• Магазин, бронирование, программа лояльности или личный кабинет на двух платформах — начните сравнение с Flutter, если сценарии в основном совпадают
• Приложение только для одной ОС — сравните нативный вариант с Flutter без предположения, что общая кодовая база обязательно даст экономию
• Обработка видео, взаимодействие с оборудованием или сложная фоновая работа — сначала проверьте самый требовательный сценарий на реальном устройстве
• Уже работающий продукт и своя команда — оцените продолжение разработки на текущей технологии; смена стека должна решать конкретную проблему

Для разработки приложений на Flutter полезно заранее разделить общие функции и платформенные особенности. Если для важной функции нет подходящего готового модуля, в оценку нужно включить его разработку и поддержку. Нативный подход также не снимает ограничения самой ОС: фоновую работу и доступ к оборудованию проверяют в обоих вариантах.

Когда стоит начать с мобильного сайта

Технологии создания мобильных приложений стоит сравнивать и с уже доступным бизнесу каналом — сайтом. Если человек приходит один раз, чтобы изучить услугу и оставить заявку, сначала проверьте этот путь в мобильном браузере. Установка приложения добавит действие, пользу которого ещё нужно объяснить.

Отдельное приложение разумно обсуждать, когда есть повторяющийся сценарий и понятная причина возвращаться: история покупок, персональная программа, регулярная работа сотрудника. При этом наличие сайта не означает, что мобильная версия продукта почти готова. Нужно проверить, может ли его сервер предоставлять приложению нужные данные и принимать действия пользователей.

Этапы разработки мобильного приложения: что принимать заказчику

У каждого этапа должен быть результат, который можно проверить. Формулировка «дизайн готов» мало помогает, если не согласованы ошибки оплаты или пустая корзина. Ниже — порядок работы, который можно использовать при обсуждении проекта с подрядчиком; часть задач допускает параллельное выполнение.

• Идея и границы версии. Зафиксировать аудиторию, основной сценарий и функции, отложенные на будущее. Результат — согласованный состав первого выпуска
• Проверка ограничений. Разобрать интеграции, доступные данные и работу с устройством. Для спорной функции собрать технический образец, чтобы проверить её до основной разработки
• Прототип и требования. Показать переходы между экранами, описать правила и ошибки. Результат — понятный путь пользователя и условия приёмки
• Дизайн. Подготовить экраны вместе с состояниями загрузки, отсутствия данных, отказа в доступе и потери сети. Согласовать поведение на разных размерах экрана
• Разработка и интеграции. Собрать приложение, подключить сервер и внешние системы. Демонстрировать работающие сценарии целиком: от действия пользователя до результата в системе бизнеса
• Тестирование и приёмка. Проверить сценарии на согласованных устройствах и версиях ОС. Зафиксировать найденные ошибки и повторно проверить исправления
• Публикация и сопровождение. Подготовить материалы для магазинов, отправить сборки на проверку и обработать замечания. После выпуска следить за сбоями и обращениями пользователей

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

Сколько времени займёт разработка

Назвать срок по одному слову «магазин» нельзя. Каталог с готовым обменом данными и магазин, для которого ещё предстоит описать резервирование товара и возвраты, требуют разных планов. До оценки полезнее определить зависимости: какие работы команда может начать сразу, а для каких нужны решения или доступы заказчика.

Попросите календарный план с результатом каждого этапа и ответственными с обеих сторон. В нём должны отдельно стоять разработка, приёмка и публикация. Если несколько специалистов работают одновременно, их трудозатраты нельзя просто сложить и назвать сроком проекта. Но и удвоение команды не сокращает вдвое ожидание готовой интеграции.

• Нет доступа к учётной системе — определить владельца доступа и дату, после которой можно проверять обмен
• Меняются правила заказа — согласовать их до реализации связанных экранов и серверной логики
• Нужна работа без интернета — описать, какие данные доступны локально и что происходит после восстановления связи
• Запуск привязан к рекламной кампании — отдельно учесть тестирование, замечания магазинов и повторную отправку
• Объём вырос после согласования — пересчитать затронутые задачи и выбрать, переносить срок или сокращать состав выпуска

Дата готовности сборки, дата отправки на проверку и дата появления приложения в магазине — разные точки плана

Сколько стоит разработка мобильного приложения

В Quantum Dev кроссплатформенное приложение на Flutter — от 150 000 ₽, нативное приложение на Swift и Kotlin — от 200 000 ₽. Разработка структуры — от 50 000 ₽. Это стартовые цены из описания услуги, а не смета любого приложения с оплатой и личным кабинетом. Точная цена зависит от числа экранов, интеграций и личного кабинета; оценку присылаем за 1 день.

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

• Проектирование и дизайн: сценарии, прототип, экраны и их состояния
• Мобильная часть: функции приложения, адаптация под платформы и работу с устройством
• Сервер и управление: хранение данных, права доступа, административная панель
• Интеграции: обмен с 1С или CRM, оплата, доставка, обработка ошибок внешних сервисов
• Проверка и выпуск: устройства для тестирования, исправления, материалы магазинов и работа с замечаниями
• Расходы после запуска: инфраструктура, внешние сервисы, сопровождение и новые функции

Общая кодовая база может сократить повторную работу над мобильной частью, но сервер и обмен данными всё равно нужны. Поэтому процент экономии следует считать по двум сопоставимым оценкам конкретного проекта. Чтобы уменьшить бюджет первой версии, убирайте целые необязательные сценарии: например, отложите рекомендации, сохранив законченный путь покупки.

Что подготовить для публикации в магазинах

Аккаунты разработчика и ответственных за выпуск определите заранее. Подготовьте описание, иконку, скриншоты, контакт поддержки и сведения об обработке данных. Для приложения с авторизацией проверяющим нужен доступ к функциям: Apple просит предоставить демонстрационный аккаунт или подходящий деморежим, а сервер должен работать во время проверки. Это указано в требованиях App Store.

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

Срок модерации не находится под контролем подрядчика. В справке Google Play сказано, что для отдельных аккаунтов проверка может занимать до семи дней, а в исключительных случаях — дольше. Это не гарантированный срок для каждого приложения. Перед запуском сверяйтесь с условиями публикации Google Play и оставляйте в плане время на замечания.

Как принять приложение и сохранить возможность его развивать

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

До завершения проекта согласуйте передачу исходного кода, инструкции по сборке и необходимых доступов. Аккаунты магазинов и инфраструктуры должны оставаться под контролем компании. Отдельно договоритесь, что относится к исправлению ошибок, а что — к развитию продукта, и кто реагирует на сбои после публикации. В Quantum Dev исключительные права на результат после оплаты переходят заказчику.

Соберите описание основного сценария, нужных платформ и интеграций, добавьте имеющиеся макеты, экраны и ссылки. С этим набором можно обсуждать разработку мобильного приложения: Quantum Dev поможет определить состав первой версии, сравнить Flutter и нативный подход и оценить работы до договора.