Розробка мобільного 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%. Операції стали передбачуваними, а цикл випуску перестав упиратися в ручну перевірку.

Навіщо окремий застосунок, якщо вже є веб-вітрина?

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

У нативному клієнті сценарій купівлі зібраний в один потік. Гаманець підключається один раз і запам’ятовується на пристрої, підпис транзакції повертає користувача в ту саму картку лоту, а не в порожню вкладку браузера. Статус лоту, ціна та історія пропозицій оновлюються самі — перезавантажувати вручну не потрібно.

Робота з гаманцем на телефоні — окрема задача, а не кнопка «підключити». Потрібно обробити повернення із зовнішнього застосунку, повторне відкриття після згортання, відсутність установленого гаманця й відмову від підпису.

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

Повторні візити — друга причина. Застосунок залишається на екрані, сповіщення про новий лот або зміну ціни веде прямо в картку, а обране та історія покупок доступні в один тап. Вітрина для повернення потребує листа або переходу за посиланням — частина аудиторії на цьому губиться.

Вітрина й застосунок не конкурують: веб залишається точкою входу для пошуку й передавання посилань, нативний клієнт — для тих, хто торгує регулярно.

Технічні сумніви: гаманець, операції, модерація

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

Що бачить покупець, якщо операція підтверджується довго?

Мережа може підтверджувати переказ хвилини й довше, і це нормальний режим, а не збій. Статус операції показується одразу після надсилання, інтерфейс не блокується, а фонова задача дожимає підтвердження й оновлює картку лоту.

Якщо транзакцію скасовано або замінено, користувач отримує зрозуміле пояснення й кнопку повтору, а не «завислу» плашку.

Де зберігаються медіафайли колекції?

Важкі зображення й відео не записуються в мережу цілком: файл іде в об’єктне сховище, а в записі залишається посилання й контрольна сума. Це тримає картку лоту легкою та швидкою за слабкого мобільного інтернету.

Якщо зовнішній сервіс недоступний, лот відкривається за резервною копією, а прев’ю перезбираються автоматично.

Як відбувається модерація спірних лотів?

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

Що входить у підтримку після запуску?

Ведемо спостереження за вузькими місцями: час відгуку стрічки, частка незавершених операцій, помилки на конкретних моделях пристроїв, стан сховища. Правки виходять плановими релізами, для термінових випадків тримаємо окремий канал зв’язку. Опишіть свою задачу — повернемося з оцінкою та планом робіт.

Обговоримо задачу: порядок старту та зони відповідальності

Перша розмова про мобільний NFT-маркетплейс потрібна не для презентації, а щоб зафіксувати межі задачі. Нам важливо зрозуміти, що вже готово — опис продукту, макети, смарт-контракти в мережі, — і що належить спроєктувати з нуля.

За підсумками зустрічі повертаємося з оцінкою та планом робіт: етапами, складом команди й залежностями, які потрібно закрити до старту проєкту.

Як зазвичай виглядає старт:

• Розбір задачі. Дивимося, що є на вході: сценарії покупця й автора, випуск і перепродаж токенів, комісії, модерація контенту.
• Обмеження платформ. Перевіряємо вибрану мережу, вимоги магазинів застосунків до таких продуктів, оплату й ліміти операцій гаманця.
• Оцінка та план робіт. Розкладаємо продукт на етапи: каркас, вітрина, гаманець, виплати авторам, адмін-панель, публікація.
• Склад команди. Мобільні інженери під обидві платформи, фахівець із блокчейн-інтеграції, дизайнер, тестувальник, керівник.
• Зони відповідальності. На нас — архітектура, код, збірки, релізи й підтримка; на замовнику — продукт, доступи до акаунтів розробника та юридична частина.
• Перший крок. Прототип ключового сценарію, потім ітерації з демонстрацією та правками по ходу.

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