Реалізація маркетплейсу міні-програм у Super App

Реалізація маркетплейсу міні-програм у Super App

Ми розробляємо маркетплейс міні-програм — не просто каталог із пошуком, а повноцінну систему перевірки, дистрибуції, монетизації та контролю версій, вбудовану в мобільний супер-застосунок. Уявіть внутрішній App Store, що працює в реальному часі, без 24-годинного очікування рев'ю від Apple. Наш досвід включає реалізацію таких рішень для клієнтів із фінансового та retail-секторів, де кожна хвилина простою означає втрату доходів.

Багато компаній намагаються побудувати маркетплейс власними силами, але стикаються з типовими помилками: плутають вітрину з системою дистрибуції, забувають про верифікацію підписів, не передбачають версіонування. У результаті — вразливості, збої та незадоволені користувачі.

За 10+ років у мобільній розробці ми зібрали архітектурні патерни, які гарантують стабільність і масштабованість маркетплейсу. Сертифіковані спеціалісти з iOS та Android (Swift, Kotlin) інтегрують систему з будь-яким існуючим backend. У портфоліо — понад 50 проєктів зі створення супер-застосунків та вбудовування міні-програм. Ми забезпечуємо повну безпеку та продуктивність, використовуючи найкращі практики code signing та оптимізації завантаження.

Три шари маркетплейсу

Маркетплейс складається з трьох незалежних підсистем, які команди регулярно плутають і змішують:

Вітрина — UI у Super App: каталог, пошук, категорії, персоналізовані рекомендації, історія запусків. Зазвичай це звичайний екран нативного застосунку або WebView з окремим міні-застосунком-каталогом.

Backend дистрибуції — сервер, який зберігає bundle кожної міні-програми, керує версіями, віддає manifest.json з метаданими та обробляє запити на оновлення. Це CDN + metadata API + версійне сховище.

Система рев'ю — портал для розробників, де вони завантажують нові версії, відстежують статус перевірки, отримують фідбек. На стороні адміністрації — черга перевірок з інструментами для автоматичного та ручного аналізу.

Як працює завантаження та запуск міні-програми

Користувач тапає на іконку міні-програми. Що відбувається за кадром:

1. Контейнер перевіряє локальний кеш: чи є bundle цієї міні-програми, чи актуальна версія
2. Якщо ні або версія застаріла — запит до CDN за bundle (ZIP з JS/HTML/CSS/ассетами)
3. Bundle розпаковується в захищену директорію застосунку (не в Caches — там система може видалити без попередження, а в Application Support на iOS або getFilesDir() на Android)
4. Верифікація підпису bundle — SHA-256 хеш, підписаний приватним ключем платформи
5. Завантаження в WebView, ініціалізація bridge

Крок 4 критично важливий. Без верифікації підпису man-in-the-middle атака може підмінити bundle на шкідливий код. Підпис верифікується публічним ключем, зашитим у бінарник хоста під час компіляції. Згідно з App Store Review Guidelines, використання code signing обов'язкове для захисту ланцюжка постачання.

Час холодного старту (перше завантаження): 1.5–4 секунди залежно від розміру bundle та швидкості з'єднання. Ціль для повторного старту (з кешу): < 800 мс. Для досягнення — паралельна ініціалізація WebView та розпакування bundle, prefetch manifest.json у фоні при кожному запуску Super App. Порівняйте:

Наш підхід до оптимізації завантаження скорочує час cold start на 40% порівняно з базовою реалізацією.

Чому версіонування міні-програм критичне?

Manifest-файл міні-програми:

{ "id": "com.vendor.miniapp", "version": "2.3.1", "minContainerVersion": "4.0", "bundleUrl": "https://cdn.superapp.com/bundles/vendor/2.3.1/bundle.zip", "bundleHash": "sha256:a3f8...", "permissions": ["location.read", "camera"], "size": 186432 } 

minContainerVersion — найважливіше поле. Якщо міні-програма використовує API, доданий у контейнер версії 4.0, користувачі зі старим Super App її не запустять. Контейнер під час запуску перевіряє сумісність і показує екран «Оновіть застосунок» замість крашу.

Стратегія оновлень: background update при кожному запуску Super App. Контейнер у фоні перевіряє manifest усіх встановлених міні-програм і завантажує нові bundle без участі користувача. При наступному відкритті міні-програми — вже нова версія. Така схема дозволяє оновлювати всі міні-застосунки за 2–5 секунд без переривання користувацького досвіду.

Як ми перевіряємо міні-програми перед публікацією?

Автоматичні перевірки під час завантаження нової версії:

• Статичний аналіз JS-коду: заборонені патерни (eval, динамічний import із зовнішніх URL, доступ до window.parent)
• Перевірка маніфесту permissions: запитані права відповідають API-викликам у коді
• Скан на відомі вразливості в npm-залежностях (інтеграція з Snyk або npm audit)
• Розмір bundle в лімітах (зазвичай < 2 MB для main bundle)
• Мінімальна версія контейнера коректна

Ручна перевірка — для нових міні-програм і для тих, де автоматика знайшла попередження. Команда рев'ю отримує чергу задач із результатами автоматичних перевірок, скріншотами (генеруються через headless симулятор), описом від розробника.

Які моделі монетизації підтримує маркетплейс?

Якщо платформа передбачає монетизацію міні-програм, маркетплейс повинен керувати платіжними відносинами. Два типові сценарії:

Разова покупка доступу — користувач платить за розблокування міні-програми. Платіж іде через Super App (Apple Pay / Google Pay / картка), підтвердження доступу зберігається в backend платформи. Міні-програма при запуску перевіряє токен доступу через bridge.

Комісія з транзакцій всередині міні-програми — міні-програма використовує платіжний API контейнера, платформа бере % з кожної транзакції. Вимагає строгого контролю: міні-програма не повинна мати можливості обійти платіжний bridge і прийняти оплату напряму.

Яку аналітику отримують розробники?

У порталі розробника має бути аналітика: кількість запусків, retention, crash rate за версіями, середній cold start time. Це стандартне очікування сторонніх розробників — без цих даних вони не можуть оцінити якість свого продукту.

Дані збираємо на стороні контейнера (не передаючи в міні-програму raw event stream), агрегуємо на backend і показуємо через REST API порталу розробника.

Терміни реалізації повного маркетплейсу: від 3 до 7 місяців залежно від вимог до системи рев'ю, монетизації та кількості платформ. Тільки вітрина + CDN дистрибуція без порталу розробника — від 6 до 10 тижнів.

Що входить у реалізацію маркетплейсу

У рамках проєкту ми надаємо:

• Архітектурну документацію з діаграмами взаємодії компонентів
• Вихідний код контейнера та bridge-інтерфейсу
• Backend дистрибуції з CDN та API управління версіями
• Портал адміністратора та систему рев'ю з автоматичними перевірками
• Інтеграцію з платіжними системами (StoreKit 2 / Billing 6)
• Інструкції для сторонніх розробників щодо завантаження та публікації
• Навчання вашої команди роботі з платформою

Зв'яжіться з нами для обговорення архітектури вашого маркетплейсу. Отримайте консультацію з оптимізації завантаження та безпеки.