Mobile NFT Marketplace Development on Swift/Kotlin with Web3

Mobile NFT Marketplace Development on Swift/Kotlin

Imagine a user opens your NFT marketplace on their smartphone, finds a rare token, taps "Buy" — and nothing makes sense. Instead of the usual card charge, they get a wallet signature request, the transaction hangs unconfirmed. We've seen this dozens of times. Our experience — 5+ years in mobile development and 30+ Web3 projects — lets us design UX so users don't lose conversion. Below we break down how we do it with Swift and Kotlin.

What a mobile marketplace solves

• Signing transactions without losing context. Users shouldn't guess what's happening. We explain each step: "Sign the approve to list the token for sale." We use WalletConnect v2 for smooth transitions.
• Fast gallery loading. IPFS gateways are slow — loading 100 tokens can take 30 seconds. We cache metadata on the device (up to 500 MB) and connect indexers like The Graph or Alchemy NFT API, response time 50–200 ms.
• Royalty support. By the ERC-2981 standard, the marketplace automatically calculates creator fees and displays them to the buyer. No hidden charges.

How to choose: Web3 Native or WalletConnect?

Two main approaches:

Native SDK (web3.swift / web3j) — full control over transactions, built-in ABI handling. Gives a better UX: users don't switch to another wallet. But requires more code for smart contract events.

WalletConnect v2 + WebView — faster to develop, suitable if the team knows React Native or Unreal Engine. QR code or deep link connects an external wallet. Downside: two transitions for an unprepared user.

More on the WalletConnect protocol in the official docs at WalletConnect.

We recommend native SDK for marketplaces with high user activity, WalletConnect for MVPs and test launches.

Technical implementation: NFT caching and indexing

// Android — NFT metadata caching with Coil + OkHttp val imageLoader = ImageLoader.Builder(context) .memoryCache { MemoryCache.Builder(context) .maxSizePercent(0.25) // 25% RAM .build() } .diskCache { DiskCache.Builder() .directory(context.cacheDir.resolve("nft_images")) .maxSizeBytes(500L * 1024 * 1024) // 500 MB .build() } .okHttpClient { OkHttpClient.Builder() .addInterceptor(IpfsGatewayInterceptor()) // replaces ipfs:// with https:// .build() } .build() 

IpfsGatewayInterceptor intercepts URIs like ipfs://Qm... and substitutes a fast gateway — Cloudflare (cloudflare-ipfs.com), NFT.storage, or your own. Add fallback: if the first gateway doesn't respond in 3 seconds, try the next.

For collections of several thousand tokens, don't fetch metadata directly from the blockchain. Use an indexer: The Graph, Alchemy NFT API, Moralis, OpenSea API. They already aggregate metadata — response time 50–200 ms instead of 10+ seconds.

What's included in the work: deliverables

• Architecture documentation: data flow diagrams (transaction signatures, contract interactions).
• Repository access with CI/CD (GitHub Actions) and Firebase App Distribution setup.
• Team training: workshop on WalletConnect and transaction signing.
• One month of support: monitoring, bug fixes, API updates.

Timelines and cost

MVP with catalog, fixed price purchase, and profile: 6–8 weeks. Full-fledged marketplace with auctions, offers, collections, and ratings: 2–3 months. Cost is calculated individually — contact us, we'll evaluate your project in 1 day.

Typical mistakes and how to avoid them

• No indexer for large collections. Direct blockchain queries cause timeouts. Connect The Graph or Alchemy before development starts.
• Ignoring royalties. Without ERC-2981, creators don't get fees — violating licensing agreements.
• Single point of failure for IPFS. Use 2–3 gateways with fallback to avoid losing metadata.

Our engineers hold certifications in Swift (iOS 15+) and Kotlin (Jetpack Compose). We guarantee compliance with App Store Review Guidelines (Section 4.2/5.1) and Google Play Console requirements. Request a consultation — we'll prepare a commercial proposal with architecture and timelines.