Marketplace Mobile App Development
A marketplace isn't just a multi-vendor store. It's three parallel apps in one: buyer, seller, admin. Architectural decisions made upfront determine how hard it is to add a new seller or product type in six months.
Where Marketplaces Break Technically
Multi-vendor catalog with filters. Standard UICollectionView / RecyclerView with paginated endpoints works until you have 50 sellers with overlapping categories. Problem: filtering "category + vendor + price range + sort" with offset pagination causes duplicates if a seller adds a product between page requests. Use cursor-based pagination (after=<last_item_id>) — stable with frequent catalog updates.
Cart with items from multiple vendors. User adds items from three sellers — checkout either splits into three orders or creates one composite order with sub-orders. This is a business decision affecting UI: vendor grouping in cart, separate delivery statuses, partial payment option. Agree on CartService architecture supporting VendorGroup upfront.
Real-time stock availability. Buyer views a product being bought. Classic: added to cart, at checkout — out_of_stock. Solution: WebSocket channel on product detail (wss://api/items/{id}/stock) updating stock counter. Cheaper: polling every 30 seconds via Timer when screen is active.
Seller App
Separate target/module or separate app — depends on feature scope. If seller only manages products and views orders — one target with role-based routing. If seller needs analytics, warehouse management, customer chat — separate app.
Mandatory seller features:
- Add/edit products with photos (upload to S3/Cloudinary via pre-signed URL directly, no server proxy)
- Incoming orders with push (
FCM/APNs, high priority) - Order status change: accepted → processing → shipped → delivered
- Sales report for period
Marketplace Payments
Hardest part — split-payment: buyer pays one sum, money splits between sellers and platform. Stripe Connect, PayPal Marketplace, or equivalent. Stripe Connect: buyer pays via PaymentIntent with transfer_data or application_fee_amount, money auto-distributes to each seller's Connected Account. On mobile — standard Stripe SDK (stripe-ios, stripe-android) for card form.
If split-payment not needed (platform collects, pays sellers separately) — simpler: normal payment gateway, seller payouts via separate system.
Search
Full-text search with autocomplete — not SQL LIKE. Elasticsearch or Meilisearch backend, mobile debounced query (300–500ms) on input. UISearchController (iOS) / SearchView (Android) with results in UITableView / RecyclerView. Previous searches in UserDefaults / SharedPreferences, show when field empty.
Architecture and Stack
For two-app marketplace (buyer + seller) React Native with shared core package — reasonable: reuse business logic (CartService, OrderService, AuthService), separate UI layers per role. Native Swift + Kotlin — when performance or hardware integration needed (NFC, barcode scanner).
Pattern: Clean Architecture with UseCases / Interactors — test business logic independently of UI. React Native: Zustand or Redux Toolkit for cart and catalog state.
Process
Discovery and design (roles, order flow, payments) → UI/UX for both apps → core modules (catalog, cart, orders, payments) → seller module → admin panel → load testing catalog and checkout → launch.
Timeline
MVP marketplace (catalog, cart, checkout, basic seller app): 6–10 weeks. Full platform with split-payment, real-time notifications, search, analytics: 3–5 months. Pricing calculated individually after requirements analysis.