Разработка мобильного NFT-маркетплейса на Swift/Kotlin с Web3

Мобильный NFT-маркетплейс: где ломается на старте

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

Первый типовой отказ — рассинхрон кошелька и витрины: выкупленный лот ещё висит в ленте, потому что экран читает кэш, а не подтверждённое состояние сети. Пользователь жмёт «купить», получает ошибку и больше не возвращается. Лечится это отдельным слоем чтения: индексер собирает события и отдаёт витрине явную метку актуальности, а мобильное приложение для NFT не доверяет собственному кэшу при спорном статусе.

Второе узкое место маркетплейса — зависшие операции. Транзакция ушла в сеть, комиссия оказалась ниже рыночной, и подтверждения нет часами. Если приложение списало баланс заранее и не умеет откатывать состояние, пользователь видит «в обработке» до перезапуска, а поддержка — поток однотипных обращений.

Третье — нагрузка на пиковых продажах: поток событий вырастает на порядки, очередь не успевает, витрина отдаёт устаревшие данные, часть запросов обрывается по времени ответа. Здесь помогает не «мощнее сервер», а схема: разделение чтения и записи, идемпотентные повторы, ограничение частоты запросов на устройстве и предпрогрев кэша под анонсированный старт.

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

Нативный маркетплейс: скорость, конверсия, надёжность

Нативная витрина на Swift и Kotlin меняет три вещи, которые сразу видны в метриках: долю завершённых сделок, скорость выпуска обновлений и класс отказов, доходящих до пользователя.

Доля завершённых сделок

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

Обновления витрины в тот же день

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

Отказоустойчивость потока сделок

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

Удержание и повторные визиты

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

Форматы реализации: нативная сборка, кроссплатформа, гибрид

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

Какой формат под какую задачу

Выбор формата фиксируем до прототипа: перенос крипто-слоя на середине проекта означает переписать подпись, хранение ключей и уведомления. Кроссплатформа снижает объём дублирующего кода, но нативные модули для Swift и Kotlin всё равно нужны — если ядро торгов упирается в кошелёк, гибридная витрина остаётся лишь быстрым входом, а не основой продукта.

Этапы инженерной работы: от схемы до передачи

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

1. Аудит мобильного решения. Разбираем сборку, зависимости, покрытие тестами, состояние ключей подписи и узкие места на реальных устройствах. На выходе — отчёт с рисками и границами работ.
2. Проектирование схемы данных. Фиксируем модель лотов, ставок и транзакций, правила локального кэша каталога и очередь на подтверждение операций в блокчейне. Это задаёт, где клиент видит статус «в обработке», а где готовый результат.
3. Сборка приложения. Модульная структура, экраны ленты, фильтров и истории, подпись транзакций на устройстве. Ключи не покидают защищённое хранилище системы.
4. Проверка на нагрузке. Прогоняем сценарии с одновременными покупателями, смотрим гонки при равных ставках и поведение при обрыве связи. Замеряем время отклика каталога и время до подтверждения операции.
5. Релиз и проверки безопасности. Проверяем хранение ключей, защиту от подмены данных и корректность обработки отказов. Выпуск идёт постепенно, с быстрым откатом версии.
6. Передача проекта. Отдаём исходники, схемы, конфигурации сборки и подписи, регламент выпуска и инструкции по инцидентам, разбираем их с инженерами заказчика.

Артефакты передачи: исходники, схемы, регламенты

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

• Исходный код приложения — репозитории для обеих платформ (Swift и Kotlin) с историей изменений, структурой модулей и воспроизводимой сборкой из чистого клона на вашем сборочном сервере.
• Схема интеграций — карта связей с узлами сети, индексером, хранилищем метаданных и платежами: какие вызовы идут, где кэш, где повтор при сбое, какие точки отказа внешние.
• Политики доступа и ключи — роли в панелях, матрица прав, порядок ротации ключей подписи сборок и сервисных учётных записей, с явным разделением зон ответственности.
• Документация по сопровождению — описание модулей и конфигураций сред, известные узкие места, пошаговые инструкции по восстановлению: откат релиза, переиндексация каталога, повтор зависших операций.
• Регламент выпуска обновлений — ветвление, обязательные проверки до сборки, порядок согласования, каналы тестовой и публичной раздачи, условия блокировки релиза.
• Схемы данных и порядок миграций — модель коллекций, токенов, заказов и кошельков с безопасным применением изменений без потери пользовательских записей.

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

Кейс: сократили долю неудачных операций и время выпуска

Маркетплейс коллекционных предметов CollectHub на нативных клиентах Swift и Kotlin на пиках выпуска коллекций терял до 12–14% операций: предмет списывался с баланса, а подтверждение не доходило до покупателя.

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

Что изменили

• Очередь операций на устройстве: у каждой свой ключ идемпотентности и явные статусы вместо «отправлено».
• Отдельный слой подписи и отправки с автоповтором и затухающей задержкой.
• Сверка кошелька и предметов при запуске приложения, а не по жалобе пользователя.
• Метрики на каждом шаге и оповещение при росте доли незавершённых операций.
• Автотесты на покупку, выпуск предмета и вывод вместо ручного прогона.

Результат

Доля неудачных операций упала с 12–14% до 2–3%, и лишь одна из десяти таких ситуаций доходит до ручного разбора — остальное закрывает автоматический повтор. Зависшие операции перестали быть отдельной линией поддержки: клиент досчитывает состояние при следующем запуске и показывает актуальный статус.

Выпуск обновления сократился с трёх недель до 4–5 дней, доля путей под автотестами выросла с трети до 75%. Операции стали предсказуемыми, а цикл выпуска перестал упираться в ручную проверку.

Зачем отдельное приложение, если уже есть веб-витрина?

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

В нативном клиенте сценарий покупки собран в один поток. Кошелёк подключается один раз и запоминается на устройстве, подпись транзакции возвращает пользователя в ту же карточку лота, а не в пустую вкладку браузера. Статус лота, цена и история предложений обновляются сами — перезагружать вручную не нужно.

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

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

Витрина и приложение не конкурируют: веб остаётся точкой входа для поиска и передачи ссылок, нативный клиент — для тех, кто торгует регулярно.

Технические сомнения: кошелёк, операции, модерация

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

Что видит покупатель, если операция подтверждается долго?

Сеть может подтверждать перевод минуты и дольше, и это нормальный режим, а не сбой. Статус операции показывается сразу после отправки, интерфейс не блокируется, а фоновая задача дожимает подтверждение и обновляет карточку лота. Если транзакция отменена или заменена, пользователь получает понятное объяснение и кнопку повтора, а не «зависшую» плашку.

Где хранятся медиафайлы коллекции?

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

Как проходит модерация спорных лотов?

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