Разработка нативных приложений

Кейсы и релевантный опыт

Банкирро: две трети заявок ушли в приложение

В данных кейса указаны Swift, Kotlin, SwiftUI и Jetpack Compose: релевантный опыт нативной разработки.

Дело, которое идёт месяцами, клиент наконец видит

Нативный клиентский кабинет с авторизацией, биометрией, уведомлениями и связью с сервером.

Изображения интерфейсов — дизайн-концепты с демонстрационными данными. Описание выполненных работ находится в самом кейсе; визуализация не является скриншотом действующего продукта.

Приложение живёт в условиях устройства

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

iOS / Swift

Системные компоненты, жизненный цикл и требования платформы Apple.

Android / Kotlin

Варианты устройств, разрешения и поведение Android при ограничении фоновых задач.

Сеть и локальные данные

Очередь операций, повторная отправка и объяснение пользователю текущего состояния.

Проверка на устройстве

Матрица устройств, версии ОС, прерывание сценария и восстановление после ошибки.

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

Что меняет доступ к устройству

Выберите функцию. Она добавляет к экрану собственные разрешения и условия проверки.

Камера

Приложение запрашивает разрешение и обрабатывает невозможность съёмки.

Проверяем отказ, качество снимка и повтор операции.

• Разрешение камеры
• Состояние ошибки
• Повторная съёмка

Bluetooth

Подключение зависит от устройства, протокола и поведения ОС.

Проверяем поиск, разрыв связи и повторное подключение.

• Совместимость
• Разрыв связи
• Восстановление

Геолокация

Точность и режим доступа согласуются с необходимостью сценария.

Проверяем отказ, приблизительную точность и работу в фоне.

• Режим доступа
• Точность
• Фоновые ограничения

Интерактивный пример для обсуждения состава работ. Демонстрационные данные.

Когда важны возможности устройства

Сначала проверяем функции, зависящие от устройства. Камера, Bluetooth и фоновая работа могут определять архитектуру всего приложения.

Клиентский сервис

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

1. Вход
2. данные
3. действие
4. подтверждение

Состав первой версии

• Авторизация
• Основной сценарий
• Push-уведомления
• Состояния ошибок

Как проверить пользу: Завершение операции и стабильность приложения. Цели и исходные значения согласуем до запуска.

Работа с устройством

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

1. Разрешения
2. соединение
3. действие
4. сохранение

Состав первой версии

• Технический прототип
• Работа с SDK
• Обработка отказов
• Проверка устройств

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

Приложение сотрудника

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

1. Задание
2. выполнение офлайн
3. синхронизация
4. проверка

Состав первой версии

• Локальное хранилище
• Очередь изменений
• Ролевая модель
• Журнал синхронизации

Как проверить пользу: Конфликты данных, завершённые задания и ошибки обмена. Цели и исходные значения согласуем до запуска.

Приложение и его системные функции

Системные ограничения рассматриваем вместе с продуктовым маршрутом, разрешениями и серверными операциями.

Платформенный UX

Интерфейс следует сценариям и привычкам пользователей каждой платформы. Общая дизайн-система не обязана делать оба клиента визуально одинаковыми.

iOS

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

Android

Kotlin и платформенные компоненты. Учитываем разные размеры экранов, версии системы и особенности работы в фоне.

Backend и API

Авторизация, данные, события и правила операций. Сервер остаётся источником полномочий и критических состояний.

Устройство и офлайн

Локальное хранение, биометрия, камера или Bluetooth включаются только по задаче. Определяем безопасное поведение без сети.

Релиз

Сборки, подпись, тестирование и материалы для публикации. Аккаунты, требования площадок и обслуживание согласуем заранее.

Варианты технологий: Swift, Kotlin, SwiftUI, Jetpack Compose. Окончательный выбор зависит от задачи и условий сопровождения.

Нативное или кроссплатформенное?

Сравниваем подходы до разработки и объясняем ограничения каждого варианта.

Проверяем на целевых устройствах

Разрешения

Отказ пользователя не ломает приложение и сопровождается понятным объяснением.

Фон и возврат

После возвращения состояние соответствует согласованным системным ограничениям.

Обновление

Обновление приложения сохраняет необходимые данные и путь авторизации.

Что остаётся у заказчика

• Документ: матрица возможностей платформ
• Документ: результат проверки критической возможности
• Документ: прототипы ios и android
• Исходный код и инструкции сборки согласованных частей
• Результаты проверки и инструкция выпуска

От устройства до публикации

Рискованные возможности проверяем на устройстве до детализации всех экранов и разработки полного продукта.

Выделяем системные зависимости

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

Результат этапа: Матрица возможностей платформ

Проверяем риск на телефоне

Создаём техническую проверку критической функции. Учитываем отказ в разрешении и ограничения фонового выполнения.

Результат этапа: Результат проверки критической возможности

Проектируем платформенный маршрут

Согласуем навигацию, системные диалоги и состояния возврата. Отдельно описываем потерю связи и восстановление сессии.

Результат этапа: Прототипы iOS и Android

Разрабатываем клиент и обмен

Реализуем функции устройства и контракты с сервером. Не повторяем операции при восстановлении связи.

Результат этапа: Тестовые сборки для целевых платформ

Проверяем реальное устройство

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

Результат этапа: Матрица устройств и результатов

Готовим публикацию

Собираем метаданные, сборки и сведения для магазинов. Срок проверки и решение магазина остаются у его оператора.

Результат этапа: Пакет публикации и инструкция обновления

Кто работает над проектом

Мобильный аналитик описывает системные сценарии. iOS- и Android-разработчики проверяют возможности платформ, дизайнер учитывает привычки пользователей, QA работает на согласованной матрице устройств.

Познакомиться с командой

Что влияет на нативную разработку

Оценка учитывает выбранные платформы, использование возможностей устройства, состояние API и тестовую матрицу, а не только количество макетов.

Платформы

Один или два клиента, поддерживаемые версии ОС и устройства.

Устройство

Фоновая работа, SDK, Bluetooth, мультимедиа и офлайн-сценарии.

Система продукта

Новый backend, состояние API, миграция пользователей и требования к защите данных.

Приложение для одной платформы

Начинаем с iOS или Android, если аудитория и задача это оправдывают.

Когда нужна одна целевая платформа.

Два нативных клиента

Согласуем общий сервер и отдельные платформенные реализации.

Когда важны возможности обеих ОС.

Системный модуль

Проверяем и реализуем сложную функцию существующего приложения.

Когда нужен доступ к устройству.

Разберём основной мобильный сценарий

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

• Целевые платформы и минимальные версии ОС
• Камера, Bluetooth, геолокация и фоновые операции
• Серверное API и требования офлайн-работы
• Аккаунты публикации и обязательные политики приложения

Оценить проект

Вопросы о нативном приложении

Когда оправдана отдельная разработка для iOS и Android?

Когда основной сценарий сильно зависит от системных API, производительности или различий платформ. Для стандартных форм и кабинетов сначала сравниваем нативный и кроссплатформенный подход.

Нужно ли начинать с обеих платформ?

Не всегда. По аудитории и способу проверки продукта можно выбрать одну платформу, сохранив общую модель API и данных для следующего этапа.

Будет ли приложение работать без интернета?

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

Кто заводит аккаунты в магазинах приложений?

Обычно аккаунты оформляются на заказчика. Требования, доступность публикации и необходимые материалы проверяем для выбранных площадок до подготовки релиза.

Как проверяются push-уведомления?

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

Связанные услуги

• Кроссплатформенная разработка
• Разработка личных кабинетов и порталов
• Доработка и сопровождение программных продуктов

Подробнее о проектировании

• Мобильное приложение для мероприятий: программа, запись и билет
• Вход по биометрии в приложение: сессия, отказ и повторный вход
• Сканирование штрихкодов в приложении: от камеры до операции
• Офлайн-режим мобильного приложения: данные, синхронизация и конфликты
• Push-уведомления в приложении: полезные сценарии, согласия и проверка доставки
• Безопасность мобильных приложений: чек-лист OWASP Mobile Top 10
• Нативная или кроссплатформенная разработка приложения
• Мобильное приложение для сотрудников компании: сервис, склад, продажи
• Монетизация мобильного приложения: модели и рынок России

Все услуги · Оценка стоимости