Разработка мобильных приложений: решения по Android и iOS

Когда приложение нужнее мобильного сайта

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

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

• Частота возвратов: посмотрите долю повторных визитов в статистике своего сайта — если она мала, установок будет мало тоже.
• Push-уведомления: в браузере на Android web-push работает, а на iOS он доступен только когда сайт добавлен на домашний экран. Если статус заказа или номер в очереди отправлять обязательно, проверьте это ограничение заранее.
• Офлайн-режим: торговая точка, склад и работа в дороге требуют работы без сети.
• Возможности телефона: камера, геолокация, сканер штрихкодов, уведомления, хранение данных на устройстве — что из этого действительно необходимо.
• Вход и платные операции: будет ли внутри личный кабинет или весь контент останется открытым.

Если «да» набирается больше трёх раз, приложение себя оправдывает. Иначе ускорение мобильного сайта потребует меньше работы. В списке услуг FAZO Web-разработка, Android-приложения и iOS-приложения стоят отдельными пунктами — приложение не продаётся вместо сайта.

Порядок выпуска Android-приложения определяет аналитика

Платформу выбирает отчёт, а не общее мнение. Откройте в аналитике распределение по устройствам и операционным системам: там видно, какая доля мобильных визитов приходится на Android, а какая на iOS.

Разделите и источники трафика: широкий поток из Telegram и Instagram и аудитория премиальной услуги дают разное распределение. Если доля iOS в отчёте окажется выше, чем вы ожидали, порядок меняется. План выхода второй платформы пишется сразу, иначе она не выходит вовсе.

• Разнообразие устройств: один макет ведёт себя по-разному на старых, слабых и крупноэкранных телефонах, поэтому тестирование на реальных устройствах закладывается в план.
• Память и батарея: фоновые процессы ограничены, поэтому синхронизацию и уведомления проектируют в начале, а не добавляют в конце.
• Push-уведомления и офлайн-поддержка: в услуге Android-приложения они перечислены как требование к продукту, а не как дополнительная опция.
• Публикация: аккаунт в Google Play Console, декларации о контенте и данных, тестовые каналы. Требования периодически меняются, поэтому их читают перед выпуском, а не на старте проекта.

На Android работает и нативный подход, и кросс-платформенный. В команде Жалолов Ойбек занимается Flutter и Android Native; выбор определяют аудитория и требования продукта, а не мода.

iOS-приложение: чем отличается экосистема Apple

iOS-приложение проще из-за небольшого числа устройств и строже из-за правил публикации. В App Store проверку проводит человек, и отказ чаще приходит не за ошибку в коде, а за продуктовое решение.

• Владелец аккаунта: спросите до начала работ, на чьё имя оформляется аккаунт разработчика. Если приложение осталось в чужом аккаунте, перенос станет отдельной работой.
• Приватность: нужно раскрыть, какие данные собирает приложение, дать ссылку на политику и объяснить, зачем запрашивается каждое разрешение.
• Тестовый аккаунт: если есть регистрация, проверяющему передаётся рабочий аккаунт — без него приложение просто не откроют и отклонят.
• Страница в App Store — часть продукта: название, скриншоты, описание и ключевые слова. App Store-оптимизация перечислена в услуге iOS-приложения как отдельная работа.

Нативный Swift или кросс-платформа — открыты оба пути. Важнее другое: интерфейс iOS не копируется с Android. Навигация, возврат назад, клавиатура и запросы разрешений подчиняются привычкам платформы. Мы не считаем дизайн украшением — это система, поэтому экраны на двух платформах не одинаковые, а работающие по одной логике.

Выбор между одной кодовой базой и двумя приложениями

Это решение определяет то, насколько глубоко продукт связан с устройством. Там, где интерфейс и бизнес-логика в основном общие — каталог, заказ, расписание, отчёты, личный кабинет, — подходит кросс-платформа.

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

• Общий код: логика пишется один раз, но тестирование и публикация выполняются дважды — эта работа не исчезает.
• Интерфейс: общие компоненты ускоряют сборку, но навигационные привычки каждой платформы сохраняются.
• Backend: оба приложения работают с одним API. Если API не спроектирован первым, приложения начнут расходиться в поведении.
• Версии: пользователь на старой версии приложения продолжает обращаться к API, поэтому механизм обязательного обновления продумывается сразу.

В нашем портфолио есть кросс-платформенные решения: Shashlik House собран на React и React Native (Expo) с backend на Node.js и MongoDB; Coffee Fresh сделан на React Native Expo как офлайн-меню, которому не нужен интернет, и его результат зафиксирован как «Офлайн-работа — 100% надёжность».

Что должно быть готово до публикации

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

1. Аккаунты магазинов: Google Play и App Store оформлены на компанию, владелец доступов известен.
2. Политика конфиденциальности: открытая ссылка, перечень собираемых данных и назначение сбора.
3. Тестовый аккаунт и инструкция: проверяющий должен пройти по всем экранам приложения.
4. Контент и возрастной рейтинг: описание совпадает с тем, что приложение действительно делает — функции, которой нет, обещать нельзя.
5. Ключи подписи и сертификаты: где хранятся и у кого резервная копия. Потерянный ключ означает, что обновление не выйдет.
6. Скриншоты и тексты: под требования каждой платформы и каждого языка.

Задайте этот список любому разработчику, с которым разговариваете: на кого оформлены аккаунты, у кого остаются ключи, кто исправляет отказ, кто отвечает за повторную подачу. Если ответы неточные, публикация станет самым слабым местом проекта.

Какая работа остаётся после публикации

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

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

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

Как FAZO ведёт разработку мобильных приложений

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

Что показано в мобильной части наших работ: UzAvtoSavdo — мобильное приложение платформы автомобильной торговли, где машины можно смотреть, сравнивать и отправлять заявку; MedHome — приложение для записи к врачу, консультаций и планирования медицинских услуг; Shashlik House — онлайн-меню ресторана с заказом и админ-панелью; Coffee Fresh — офлайн-меню, которому не нужен интернет.