Mobile App Development for Price Comparison
A price aggregator is first and foremost a data parsing and synchronization task. The mobile application itself isn't complex: product list, filters, price history, notifications. But the entire architecture depends on a backend that collects prices from dozens of sources and keeps them current. Without it — just a pretty shell with no data.
How Price Aggregation Works
Three data sources, each with its own pros and limitations:
Partner Store APIs. Official feeds from Yandex.Market, Google Shopping, Amazon Product Advertising API, partnerships with major retailers. Data is current, official SLA exists. Downside — coverage limited to affiliated stores.
Scrapers. For stores without APIs. Here begins war with anti-bot protection: Cloudflare, CAPTCHA, fingerprinting, rate limiting. Playwright/Puppeteer in headless mode, User-Agent rotation and IP via proxy pool. Legality is gray zone, depends on country and store ToS.
User Crowdsourcing. User scans barcode in store and fixes price. Works in niches with no official data (local markets). Requires verification: price from one user is suspicious, from three different ones within a day is reliable.
Barcode Scanner
Primary search method for offline shopping. On iOS: AVCaptureSession + AVMetadataObjectTypeEAN13Code, EAN8Code, UPCECode, QRCode. Important to add haptic feedback on success — UIImpactFeedbackGenerator — user doesn't always look at screen.
Barcode lookup: first local cache (LRU cache of last N products), then API request. If found in cache — instant result. This is critical: user in store stands at shelf and waits.
Price History
Each price change is a separate PriceHistory record with productId, shopId, price, currency, recordedAt. Don't overwrite current price — only append. Price change chart for 30/90/365 days is built from this table.
On mobile client we cache historical curve as compact binary format (not JSON — JSON bloats traffic). Protocol Buffers or MessagePack for transmitting price history.
Price Drop Notifications
PriceAlert — user sets target price for product. Backend checks on each price update: newPrice <= targetPrice. Delivery via FCM (Android) / APNs (iOS). Important: notification must arrive fast — user makes purchase decision in the moment. Delay over 30 minutes drops conversion.
Mobile App Structure
Search (text + barcode), product card with prices across shops, distance filter (geolocation to find nearest stores with right price), price history, watchlist with alerts. Offline-first for watchlist — local cache, sync when online.
"Basket" comparison: user adds several products, app calculates which store is cheapest overall. This requires unit normalization (1 kg vs 500 g × 2).
Work Process
Key decision at start — where to get price data. This determines 60% of architecture. If you have partnerships with stores — task simplifies. If not — budget scraping infrastructure. Define product categories, region, target store base.
Timeline Guidelines
Mobile app (without backend) with search, cards, price history from ready API — 4–7 weeks. Full product with own price collection backend, alerts and basket comparison — 14–22 weeks. Pricing is calculated individually.







