Разработка мобильного приложения для управления контентом AR-сцен

Разработка мобильного приложения для управления контентом AR-сцен

Команда маркетинга хочет обновить 3D-модель продукта в AR-приложении без участия разработчика. Сейчас это выглядит так: отправить задачу в Jira → разработчик заменяет файл → сборка → ревью → публикация → 2 недели. AR CMS решает это: контент-менеджер загружает новую USDZ-модель через веб-интерфейс → приложение подтягивает обновление при следующем запуске → без апдейта в App Store.

Архитектура AR Content Management System

Серверная часть. CMS для AR-контента — это по сути файловый менеджер с метаданными и CDN. Минимальный стек:

• Storage: S3 или аналог (Cloudflare R2 дешевле) для хранения USDZ/glTF/видео
• База данных: PostgreSQL с таблицами ar_scenes, ar_objects, ar_triggers
• API: REST или GraphQL для CRUD операций над сценами
• CDN: CloudFront или Cloudflare для быстрой доставки тяжёлых 3D-файлов по всему миру
• Admin UI: React или Vue для контент-менеджера

Структура AR-сцены в JSON:

{
  "sceneId": "product-launch-q4",
  "trigger": { "type": "image", "referenceImageUrl": "...", "physicalWidth": 0.2 },
  "objects": [
    {
      "modelUrl": "https://cdn.../product.usdz",
      "iosUrl": "https://cdn.../product.usdz",
      "androidUrl": "https://cdn.../product.glb",
      "position": [0, 0.1, 0],
      "scale": [1, 1, 1],
      "animation": "idle_loop"
    }
  ],
  "publishedAt": "2025-03-01T00:00:00Z",
  "expiresAt": "2025-06-01T00:00:00Z"
}

Мобильная сторона. При запуске (или по расписанию) приложение запрашивает актуальный манифест сцен. Сравниваем updatedAt с кешированной версией — если изменилось, скачиваем новые ассеты. Хранение локально: iOS — FileManager в Caches directory (очищается системой при нехватке места), Android — аналогично через getCacheDir(). Критичный контент — в Documents/filesDir (не очищается).

Lazy loading: не грузим все модели при старте, только после того как пользователь открыл конкретный AR-экран. URLSession.downloadTask с прогрессом для крупных файлов (>10 MB).

Versioning и rollback

Контент должен быть версионирован. Если новая модель имеет проблемы — быстрый откат без публикации апдейта. Реализуем через version поле в манифесте: CMS хранит историю версий, API принимает ?version=latest или конкретный ID. Rollback — смена current_version указателя в CMS без удаления файлов.

A/B тестирование контента: разные сцены для разных userId сегментов. Параметр variant в ответе API определяет какой контент загружать.

Валидация загружаемого контента

Контент-менеджер может загрузить сломанный USDZ. Нужна серверная валидация:

• Проверка формата: USDZ = ZIP с .usdc/.usda внутри. Парсим заголовок на сервере
• Размер: лимит на загрузку (например, 50 MB для модели)
• Превью: автоматически рендерим thumbnail из USDZ через SceneKit на macOS сервере или через Reality Composer CLI
• Предупреждение о высоком полигонаже: считаем poly count через USD Python API

Права доступа и воркфлоу публикации

Для корпоративных клиентов: роли (viewer, editor, publisher, admin), approval workflow (контент создан → проверен менеджером → опубликован). Temporal publishing: сцена становится активной в заданное время — для сезонных кампаний без ручного включения.

Сроки: базовый AR CMS с веб-интерфейсом, CDN и мобильным клиентом для iOS — 6–10 недель. Полная система с Android, версионированием, approval workflow и аналитикой просмотров — 3–5 месяцев. Стоимость рассчитывается индивидуально.