Development of a Parking Mobile App
Introduction
Developing a parking mobile app faces a core problem: real parking occupancy is a stream of events, not a static table. A user sees "free" spots on the map near a mall, drives there, and finds the lot full — data was 15 minutes stale. We solve this by directly integrating with hardware and payment systems, providing a trustworthy real-time picture.
Integration with Parking Equipment
Real occupancy data comes from barriers, loop detectors, or ultrasonic sensors via MQTT or WebSocket to a broker (mosquitto, EMQX). The mobile app subscribes to parking topics and receives live updates. This requires a persistent connection, implemented on mobile via Starscream (iOS WebSocket) or OkHttp WebSocket (Android). The connection drops when the app goes to background — for iOS we use BGProcessingTask, for Android WorkManager with periodic checks.
If the budget doesn't allow hardware integration, we use payment system data: entry is recorded upon payment, exit upon payment/barrier lift. Accuracy is lower, but data is real.
Seamless Payment
The most critical UX moment is paying for parking without queuing at a terminal. Three common scenarios:
- Prepayment by license plate. User enters plate, selects time, pays. At exit, an ANPR camera matches the plate and opens the barrier. Integration with Russian ANPR systems (Vocord, ITRIUM) or international ones (Genetec, Milestone).
-
Scan & Pay. QR code at entry, user scans, app records entry time, payment at exit. Implemented via
AVCaptureSession(iOS) orCameraXwithBarcodeScannerfrom ML Kit (Android) — no separate QR SDK needed. -
NFC tags. Tap an NFC tag at entry/exit.
Core NFC(iOS 11+) orNfcAdapter(Android). iOS limitation: NFC works only in foreground, cannot scan in background without special entitlement.
For payments we integrate Stripe, YooKassa, or CloudPayments depending on geography — all three provide native iOS/Android SDKs.
Payment Method Comparison — Parking App Development
| Method | Data Accuracy | Integration Complexity | Hardware Requirements |
|---|---|---|---|
| Prepayment (ANPR) | High | Medium | ANPR cameras |
| Scan & Pay (QR) | Medium | Low | QR sticker at entry |
| NFC Tags | High | Low (Android) / High (iOS) | NFC tags |
How to Ensure Live Parking Status?
The key is choosing the data exchange protocol. MQTT or WebSocket with an event-driven model. In one project for a network of 8 parking lots (about 2000 spaces), we replaced polling (every 60 seconds) with an event-driven architecture using MQTT and a WebSocket proxy. Update latency dropped from 60 to 1–2 seconds, and traffic reduced 30 times: 1440 requests per day vs. 10–50 messages. Result: real-time status became the main driver of user satisfaction.
Why Real-Time Status Is Critical in a Parking Mobile App?
When a driver sees a free spot and arrives to find it taken — that's lost time and trust. Polling at a one-minute interval gives stale data during peak hours. Event-driven architecture (MQTT/WebSocket) ensures users receive only actual changes, with no parasitic traffic. Comparison: event-driven beats polling by 30x in traffic volume and 30–60x in latency.
Load Comparison: Polling vs Event-Driven
| Parameter | Polling (every 60 sec) | Event-Driven (MQTT) |
|---|---|---|
| Requests per day per parking lot | 1440 | 10–50 |
| Update latency | up to 60 sec | 1–2 sec |
| Client traffic | 1.4 MB/day | 45 KB/day |
Map and Navigation to a Free Spot
We render the parking lot map (level-by-level spot layout) via SVG rendering or custom Canvas. Google Maps and MapKit don't fit — indoor layout is needed. We use SVG with identifiers for each parking bay, colored by status through DOM manipulation or native Canvas.drawPath.
Navigation to the parking lot uses standard Google Maps/MapKit deep links. Indoor navigation to a free spot is optional via BLE beacons (Estimote, Kontakt.io) with Indoor Positioning. This adds complexity and cost, justified only for large multi-level parking garages.
How to Implement Real-Time Status: Step-by-Step
- Audit parking equipment (barriers, sensors, payment terminals).
- Choose protocol: MQTT or WebSocket based on load.
- Set up broker (mosquitto, EMQX) and subscribe mobile app to topics.
- Implement persistent connection on mobile side (BGProcessingTask/WorkManager).
- Integrate with payment gateway (Stripe, YooKassa) to sync entries/exits.
- Test with real equipment for 2 weeks.
- Deploy and monitor (Firebase Crashlytics + Sentry).
What's Included in Turnkey Development
- Audit of existing equipment and payment infrastructure
- Integration design (MQTT/REST from controllers, ANPR, payment gateway)
- Design of parking layout and mobile interface
- MVP development in 6–10 weeks; full version with indoor navigation up to 4 months
- Testing on real equipment (barriers, sensors)
- Publication to App Store and Google Play, monitoring setup (Firebase Crashlytics + Sentry)
- 3-month warranty support, admin training
Stages and Timeline
| Stage | Duration |
|---|---|
| Audit of equipment and payment infrastructure | 1–2 weeks |
| Integration design (MQTT/REST, ANPR, payment gateway) | 1–2 weeks |
| Design of parking layout and mobile interface | 2–3 weeks |
| MVP development | 6–10 weeks |
| Full version (with indoor navigation) | up to 4 months |
| Testing on real equipment | 1–2 weeks |
| Publication and monitoring (Firebase Crashlytics + Sentry) | 1 week |
Typical Mistakes in Parking App Development
- Using polling instead of event-driven — leads to stale data and high traffic.
- Ignoring background processing on iOS/Android — connection loss causes no updates.
- No fallback payment scenarios (e.g., only NFC without ANPR/QR).
- Not accounting for iOS NFC limitations (only foreground).
Pricing is determined individually after an audit. We have many years of experience and have delivered over 15 projects for commercial parking lots. We'll evaluate your project within 2 days — get a consultation and timeline estimate tailored to your infrastructure. Contact us to discuss developing a mobile app for your parking lot.