The Real-Time Geometry of Parkaroo

How a SwiftUI client and Firebase backend orchestrate synchronous parking spot hand-offs between moving vehicles.

6 min read • View on GitHub • More from maximusrome

Two vintage cars connected by a glowing thread approaching a parking space in an isometric city grid — Parkaroo solves the "synchronous hand-off" problem, requiring two moving targets to converge on a single exact coordinate simultaneously.

Key Takeaways

The app uses a spatial Z-axis state machine to keep the map visible during all transaction phases.
Firestore listeners act as a real-time message broker to synchronize state between moving vehicles.
An internal token economy and mandatory rating system mitigate the physical friction of peer-to-peer hand-offs.
Parkaroo replaces expensive physical hardware sensors with a scalable software-only coordination layer.

The Moving Target Problem

Most parking applications solve a static problem. You reserve a concrete driveway or a numbered spot in a garage, and it waits for you. Parkaroo attacks a dynamic problem. Swapping a curbside street spot requires two people—a buyer and a seller—to be at the exact same coordinates at the exact same time.

This is a problem of physical geometry and real-time state synchronization. It is not enough to know a spot will be available. The system must orchestrate a live hand-off between two moving vehicles. To achieve this, the codebase splits the user experience into two distinct halves: `GetView` for the buyer and `GiveView` for the seller.

The Z-Axis State Machine

Standard iOS applications rely on the `NavigationStack`. Users tap a button, and a new screen pushes over the old one. Parkaroo abandons this paradigm entirely for its core flow. The map is the only context that matters, and hiding it behind a loading screen or a confirmation menu breaks the spatial awareness required for a real-time hand-off.

Instead, the app uses a massive SwiftUI `ZStack`. State changes trigger translucent UI panels to slide up from the bottom of the screen. The `MKMapView` remains permanently anchored in the background. As the transaction progresses from "Searching" to "Approaching" to "Rate User", the interface slides on the Z-axis rather than the X-axis.

A 3D exploded view of a mobile application interface showing Z-axis layering. The bottom layer is a static city map with a single dropped pin. Floating above it are three distinct

The Firebase Sync Layer

To keep the buyer and seller in lockstep, Parkaroo relies on a highly reactive Firebase backend. The heavy lifting happens inside `LocationTransfer.swift`. This ViewModel essentially uses Firestore as a real-time message broker.

When a seller marks a spot as available, the app opens a `ListenerRegistration`. If a buyer claims the spot, or if either party cancels, the Firestore document updates. The listener catches this change instantly, bypassing the need for manual API polling. The UI reacts immediately, updating the ZStack panels to reflect the new shared reality.

// Conceptual representation of the Firestore listener pattern in Parkaroo
func listenForSpotUpdates(pinId: String) {
    givingPinListener = db.collection(FBKeys.Pin.collection)
        .document(pinId)
        .addSnapshotListener { documentSnapshot, error in
            guard let document = documentSnapshot else { return }
            // Instantly react to the buyer claiming the spot
            self.handleStateTransition(with: document.data())
        }
}

Building a Trust Economy

Software cannot force a driver to wait. A seller might drive away before the buyer arrives, or a buyer might claim a spot and never show up. Parkaroo absorbs this physical friction using a token economy.

The codebase reveals an internal credit system implemented via `userInfo.AddOneCredit()`. Instead of processing direct cash micro-transactions for every parking spot, the app uses an abstraction layer of credits. Coupled with a mandatory rating system (`RateSellerView` and `RateBuyerView`), this ensures that bad actors are filtered out of the marketplace, while failed hand-offs can be refunded with internal tokens rather than complex Stripe chargebacks.

Software vs. Silicon

The smart parking industry is currently divided into two camps. The traditional approach relies on heavy infrastructure. Competitors install physical sensors in the asphalt and use cameras with Optical Character Recognition (OCR) to log license plates as vehicles enter.

Parkaroo represents the pure software alternative. It assumes the infrastructure is already there: the GPS chip in the user's phone and their willingness to coordinate. It trades the absolute certainty of a physical camera for the scalability of a peer-to-peer network.

A split illustration showing a mechanical camera turnstile on the left and two human hands passing a map pin on the right — Traditional smart parking relies on rigid hardware and cameras. Parkaroo relies entirely on human consensus and GPS.

System Type	Infrastructure Cost	State Verification	Primary Use Case
Parkaroo (P2P)	Near Zero	Human Consensus / GPS	Public Street Parking
Traditional Smart Parking	High (Cameras, Sensors)	OCR / Physical Triggers	Private Lots / Garages

Sources: Codebase analysis of the Parkaroo repository. The project architecture relies on Swift, MapKit, and Firebase.