Parking Mobile App Development
User searches for a spot near a shopping center, the map shows "available" — he drives over and the parking lot is full. Data is 15 minutes stale. This is the most common failure scenario for parking apps: real parking occupancy is a stream of events, not a static table in a database updated once every N minutes.
Integration with Parking Equipment
Real occupancy data comes from barriers, loop detectors or ultrasonic sensors via MQTT or WebSocket protocol to a broker (mosquitto, EMQX). The mobile app subscribes to the parking topic and gets real-time updates. This requires persistent connection, which on mobile devices we implement via Starscream (iOS WebSocket) or OkHttp WebSocket (Android). The connection breaks when the app moves to background — for iOS use BGProcessingTask, for Android — WorkManager with periodic checks.
If budget doesn't allow hardware integration — use payment system data: entry is recorded when paying entrance, exit — when paying/barrier rises. Accuracy is worse, but data is real.
Seamless Payment
The most critical UX moment — parking payment without queuing at a terminal. Three common scenarios:
Pre-payment by license plate. User enters plate, chooses duration, pays. At exit, ANPR camera checks the number and opens the barrier. Integration with Russian ANPR systems (Vocord, ITRIUM) or international (Genetec, Milestone).
Scan & Pay. QR-code at entrance, user scans, app remembers entry time, payment at exit. Implemented via AVCaptureSession (iOS) or CameraX with BarcodeScanner from ML Kit (Android) — no need for separate SDK for QR.
NFC tags. Touch to NFC tag at entry/exit. Core NFC (iOS 11+) or NfcAdapter (Android). iOS limitation: NFC works only in foreground, can't scan in background without special entitlement.
For payment integrate Stripe, YooKassa or CloudPayments depending on geography — all three provide native SDK for iOS/Android.
Parking Map and Navigation to Free Spot
Parking map (per-level spot layout) displayed via SVG rendering or custom Canvas. Google Maps and MapKit aren't suitable — need indoor layout. Use SVG with IDs for each parking box, color them by status via DOM manipulation or native Canvas.drawPath.
Navigation to parking — standard Google Maps / MapKit deep link. Navigation inside parking (to free spot) — optional via BLE beacons (Estimote, Kontakt.io) with Indoor Positioning. This adds complexity and cost, justified only for large multi-level parking lots.
From Practice
App for parking network: 8 locations, ~2000 spots. First version updated occupancy via REST API with polling every 60 seconds. Complaints about "showing incorrect" came constantly. After switching to MQTT with WebSocket proxy and server events, update delay dropped to 1–2 seconds. Traffic consumption dropped — polling once per minute gave ~1440 requests daily, WebSocket with event-driven updates — 10–50 messages depending on parking activity.
Development Stages and Timeline
- Audit of existing equipment and payment infrastructure
- Design of integrations (MQTT/REST from controllers, ANPR, payment gateway)
- Design of parking layout and mobile interface
- Development — usually MVP in 6–10 weeks, full version with indoor navigation up to 4 months
- Testing on real equipment (barriers, sensors)
- Publication and monitoring via Firebase Crashlytics + Sentry
Cost depends on integration scope. Calculated individually after infrastructure audit.