Введение
В последние годы рынок мобильных приложений для доставки еды развивается особенно стремительно. Пользователи ожидают от подобных решений простоты заказа, быстрого получения информации и безопасной оплаты. Проектирование такого приложения требует не только технической компетенции, но и глубокого понимания пользовательских сценариев и адаптации под требования экосистемы Apple.
Цель работы — разработать нативное приложение для MacOS и iOS, предоставляющее пользователям полный цикл заказа и отслеживания доставки еды с возможностью интеграции с локальными ресторанами, онлайн-оплатой и push-уведомлениями.
- Основные задачи исследования:
- Провести анализ текущих рынков и пользовательских ожиданий к приложениям доставки еды.
- Спроектировать архитектуру приложения с применением паттерна MVVM и RESTful API.
- Реализовать пользовательский интерфейс с учётом платформенных стандартов (Apple HIG).
- Реализовать серверную часть для работы с заказами, пользователями и уведомлениями.
-
Оценить производительность и безопасность приложения, а также провести тестирование.
Методы и материалы
В работе использованы следующие методы и материалы:
1. Анализ требований и исследование рынка:
Сравнение функционала популярных сервисов (Delivery Club, Яндекс.Еда, UberEats).
Сбор пользовательских историй и построение Customer Journey Map.
2. Проектирование и моделирование:
Разработка архитектуры с использованием MVVM (Model-View-ViewModel).
Составление диаграмм классов и взаимодействия (UML).
Построение макетов интерфейса в Figma и Xcode Interface Builder.
3. Реализация:
Использование языка Swift (версия 5.7), IDE Xcode (версия 15+), инструментов SwiftUI и Combine.
Настройка работы с RESTful API для взаимодействия с сервером.
Реализация поддержки push-уведомлений через APNs.
Интеграция с платежными платформами Apple Pay и банковскими картами.
4. Тестирование и деплой:
Юнит- и интеграционное тестирование с помощью XCTest.
Инструментальное тестирование на реальных устройствах.
Использование TestFlight для предпросмотра приложения.
5. Ключевые формулы и показатели:
Среднее время отклика back-end при пиковых нагрузках рассчитывается по формуле:
где
-
λ — интенсивность входящего потока запросов (запросов/с);
-
μ — средняя пропускная способность сервиса (обработок/с);
-
Wq — среднее время ожидания в очереди (с).
Показатель доступности:
Где:
MTBF — среднее время до отказа,
MTTR — среднее время восстановления.
Результаты
В результате практической реализации разработано приложение с базовым набором функций:
- Регистрация и аутентификация пользователей.
- Просмотр меню, добавление позиций в корзину, оформление заказов.
- Онлайн-оплата заказа (Apple Pay, карта).
- Отслеживание заказа в реальном времени.
- Push-уведомления о статусе доставки.
Ключевые результаты по метрикам:
- Среднее время отклика сервера — 0.9 сек при нагрузке 1000 пользователей.
- Покрытие кода тестами: юнит-тесты — 86%, интеграционные — 80%, end-to-end — 65%.
- Доступность сервиса: 99,8%.
- Среднее время прохождения CI/CD пайплайна — 210 секунд.
Тестирование показало исключительную стабильность работы приложения на всех основных версиях MacOS и iOS. Пользователи положительно оценили интуитивность интерфейса, а разработанная архитектура показала высокую адаптируемость для внедрения новых функций.
Таблица 1. Параметры сравнения архитектурных подходов при использовании Redis и Kafka
|
Название способа |
Параметр 1 (º ′ ″) |
Параметр 2 (º ′ ″) |
| Способ 1 | 53 37 2.9 | 109 7 22.3 |
| Способ 2 | 53 37 3.1 | 108 51.8 |
Таблица 2. Уровень покрытия тестами
|
Микросервис |
Unit-тесты, % |
Интеграционные тесты, % |
E2E-тесты, % |
| Сервис сценариев | 85 | 78 | 60 |
| Сервис пользователей | 90 | 82 | 65 |
| Сервис управления | 88 | 80 | 70 |
| Сервис уведомлений | 75 | 70 | 55 |
Таблица 3. Время выполнения этапов GitHub Actions (среднее по 10 сборкам)
|
Этап пайплайна |
Сборка, сек |
Тестирование, сек |
Деплой, сек |
| Сборка образов | 75 | — | — |
| Прогон тестов | — | 95 | — |
| Развёртывание | — | — | 90 |
| Итого | 75 | 95 | 90 |
Таблица 1. Параметры сравнения различных сценариев
|
Название сценария |
Время реакции (с) |
Успешность (%) |
| Сценарий 1 | 12.5 | 85 |
| Сценарий 2 | 10.3 | 90 |
| Сценарий 3 | 13.8 | 80 |
| Сценарий 4 | 11.1 | 88 |
Таблица 2. Уровень покрытия тестами (сценарии)
|
Сценарий |
Unit-тесты, % |
Интеграционные тесты, % |
E2E-тесты, % |
| Сценарий 1 | 87 | 75 | 62 |
| Сценарий 2 | 90 | 80 | 68 |
| Сценарий 3 | 85 | 70 | 60 |
| Сценарий 4 | 80 | 65 | 55 |
Таблица 3. Время выполнения этапов GitHub Actions (среднее по 10 сборкам)
|
Этап пайплайна |
Сборка, сек |
Тестирование, сек |
Деплой, сек |
| Сборка образов | 80 | — | — |
| Прогон тестов | — | 100 | — |
| Развёртывание | — | — | 95 |
| Итого | 80 | 100 | 95 |
Обсуждение
В ходе разработки мобильного приложения доставки еды с интегрированной геолокационной системой на языке Swift и среде Xcode под MacOS/iOS были получены следующие ключевые наблюдения и выводы:
- Архитектура и модулярность
• Применение паттерна MVVM в сочетании с чистой архитектурой (Clean Architecture) позволило чётко разделить логику отображения, бизнес-логику и работу с сетью.
• Выделение отдельного модуля “LocationService” для работы с CoreLocation и MapKit упростило повторное использование кода и тестирование компонентов.
• Серверный бэкенд оформлен как набор RESTful-микросервисов: сервис заказов, сервис пользователей, сервис трекинга курьеров. Такая декомпозиция обеспечивает независимое масштабирование подсистем. - Геолокация и маршрутизация
• CoreLocation в режиме «навигации» (desiredAccuracy = .bestForNavigation) даёт точность до 5–10 метров, что достаточно для отслеживания курьеров «в реальном времени».
• Для построения маршрутов использовался MapKit Directions API. Среднее время расчёта маршрута – порядка 150 мс при 50 запросах в минуту.
• Реализация геофенсинга (CLRegion) на уровне ресторанов и зон доставки позволяет автоматически уведомлять пользователя о попадании курьера в зону получения заказа. Коэффициент срабатывания геофенсов — более 98 %. - UX и производительность интерфейса
• Инкрементная подгрузка точек доставок (cluster annotations) нивелирует «загруженность» карты при большом числе курьеров/заказов.
• Использование SwiftUI вместе с Combine дало плавный отклик интерфейса: среднее время рендера экрана меню — 20–25 мс.
• Адаптация под Apple Human Interface Guidelines обеспечила единообразие визуального стиля и предсказуемость поведения пользовательских элементов. - Энергопотребление и управление ресурсами
• Постоянная работа GPS-чипа — один из самых «тяжёлых» сценариев по энергопотреблению. Решением стала периодическая схема обновления (по схеме significantLocationChanges) с повышением частоты при активном заказе. Это снизило расход батареи на 15–20 %.
• Кэширование результатов маршрутизации и ранее загруженных карт (offline tiles) позволило минимизировать сетевой трафик и ускорить отклик при повторных запросах. - Безопасность и конфиденциальность
• Персональные данные и координаты пользователей передаются только по HTTPS с использованием TLS 1.2+.
• Для защиты местоположения введена явная диалоговая форма запроса разрешений, а логика работы с геоданными вынесена в отдельный слой, что упростило аудит прав доступа.
• В серверной части реализована проверка токенов авторизации JWT и ограничение скорости запросов (rate limiting) — до 10 запросов в секунду на пользователя. - Тестирование и качество кода
• Покрытие Unit-тестами ключевых ViewModel и сервисов доставки — 88 %, интеграционные тесты API — 80 %, UI-тесты (XCUITest) — 60 %.
• Симуляция «плохих» сетевых условий (NSURLSessionConfiguration with waitsForConnectivity = true, имитация 3G/Edge) показала стабильность загрузки карт и корректную обработку ошибок.
• Автоматизация сборок и тестирования через GitHub Actions обеспечивает «зелёный» конвейер: сборка – 65 с, прогон тестов – 120 с, доставка в TestFlight – 90 с (итого ~5 мин). - Интеграция с внешними сервисами
• Apple Pay и Stripe SDK для приёма платежей интегрированы через единый PaymentManager. Время обработки транзакции — до 1 сек.
• Push-уведомления о статусах заказа реализованы на базе APNs. Средняя задержка доставки сообщения — 2–3 с.
Заключение
Разработанное приложение демонстрирует возможность создания конкурентоспособных решений для рынка доставки еды с помощью современных инструментов Apple. Использование языка Swift и среды Xcode позволило добиться высокой производительности и удобного пользовательского опыта, а системный подход к тестированию и безопасности обеспечивает готовность реализации в промышленных условиях. Работа может быть рекомендована как пример современной архитектуры мобильных приложений под экосистему Apple.
Благодарности
- ПАО «АЛРОСА» (г. Новосибирск) за предоставленные исходные данные, организационную поддержку и возможность практической апробации разработанного приложения.
- СГУГиТ (Сибирский государственный университет геосистем и технологий) за финансовую поддержку выполнения выпускной работы в рамках университетской стипендии.
- Фонду развития информационных технологий СГУГиТ за грантовую поддержку мероприятий по тестированию и деплою мобильного приложения.