Case study · Micromobility · Mobile & IoT

E-scooter sharing app for iOS and Android

Published Sep 8, 2023 · Updated Sep 8, 2023 · By YuSMP Group Engineering

How we built a complete e-scooter rental platform — native iOS and Android rider apps, an IoT telematics control plane, geofencing, and an operations dashboard — for a micromobility operator that owned the scooters and the city permits but needed the software. The product now serves 5,000+ happy users across the US and EU.

IndustryMicromobility · Mobility

Project year2023

EngagementDiscovery + build

E-scooter sharing app — live GPS ride map with active trip metering on iOS, for the US and EU

The brief — turn a fleet of scooters into a rentable platform

The client was a micromobility operator with real assets — a fleet of electric scooters and the city permits to run them — but no in-house capability for the complex telematics and mobile engineering a shared-scooter business actually depends on. Owning the hardware is only half the business; the other half is the software that turns a parked scooter into a discoverable, unlockable, trackable, and billable asset for riders across the United States and the European Union. The brief was a complete IT platform: native rider apps for iOS and Android, an admin dashboard to manage the fleet, pricing, and operating zones, and — the part that makes or breaks a micromobility product — a reliable communication layer between the app and the scooter controllers for remote lock, unlock, and speed control. We built it from first principles with YuSMP Group, starting with hands-on hardware analysis of a physical scooter prototype rather than vendor spec sheets alone, and delivered a product that now supports 5,000+ users on the App Store and Google Play.

Project highlights

Live GPS scooter map QR-code unlock IoT telematics control plane Geofencing with auto speed limiting Failsafe remote lock / unlock In-app ride wallet & spend cap Admin fleet & zone dashboard App Store + Google Play live · US & EU

By the numbers

A snapshot of what the scooter-sharing build delivered across iOS, Android, and an IoT telematics control plane.

5,000+happy users on the rider apps across US and EU storefronts (documented headline)

2native platforms — iOS in Swift and Android in Kotlin, optimized per platform

3telematics commands at the core — unlock, lock, and geofence speed control

1physical scooter prototype reverse-engineered to map the controller protocol

2app stores live — Apple App Store and Google Play across US and EU storefronts

16–22 wktypical delivery window for a comparable micromobility rider-app MVP on both stores

E-scooter sharing live GPS map — available scooters with battery levels and QR scan-to-ride entry point

Why a server-relayed telematics architecture over direct device control

The architectural decision that dominates a micromobility build is how the rider's phone reaches the scooter. We deliberately chose a server-relayed telematics model — the app never commands the controller directly — over a direct device-to-phone control path. When a rider scans a QR code, the app sends an intent to the backend; the backend authenticates the ride, checks wallet balance and zone rules, then relays a signed command down the cellular telematics channel to the controller on the scooter. The controller acknowledges, and only then does the app flip ride state. This indirection is what makes the platform safe to bill against: every unlock, lock, and geofence action is a server-side event with an audit trail, not a fire-and-forget Bluetooth message that can be spoofed or lost without record. The same control-plane discipline carries into our custom software development practice across mobility products.

We mapped the controller's request-and-response protocol the hard way: cross-functional leadership — a business analyst, a systems architect, and a backend director — worked from a physical scooter prototype, not just a controller datasheet, and produced detailed sequence diagrams covering every rider interaction. The comparison below summarizes why the relay model won for a fleet that has to satisfy US and EU city regulators.

Server-relayed telematics vs direct Bluetooth control vs white-label SDK — at a glance
Dimension	Server relay (this build)	Direct Bluetooth	White-label SDK
Command audit trail	Every action is a logged server event	Local only — hard to reconcile with billing	Vendor-controlled, often opaque
Range to scooter	Anywhere with cellular — no proximity needed	Phone must be next to scooter	Varies by vendor
Geofence enforcement	Server pushes speed/stop on boundary cross	Requires app foreground & proximity	Bundled but not customizable
Failsafe on dropped signal	Command queue + acknowledgement protocol	Silent failure — rider may be mischarged	Depends on SDK implementation
Billing integrity	Charge only on confirmed unlock/lock	Hard to guarantee	Vendor-defined
Fleet observability	Central admin dashboard, real-time map	No central view	Vendor portal — limited
Customization & ownership	Full source — owned by the operator	App-side only	Licensed, lock-in risk

Platform references: Apple Core Location documentation, Android location services reference.

E-scooter QR unlock flow — scan to start ride with battery, range, and per-minute pricing on iOS

iOS build — Swift, Core Location, and the QR unlock flow

The iOS client is built in Swift with a one-screen-to-ride flow: a live map of nearby scooters, a scan-QR entry point, and a scooter detail card that shows battery, estimated range, start fee, and per-minute price before the rider commits. The map layer uses Apple's Core Location for the rider's position and streams scooter GPS positions from the backend, so the picker reflects the real fleet without blocking on a slow network round-trip. The QR unlock path is where most riders form their first impression of the product, and where we spent disproportionate engineering effort: scan, validate wallet and zone eligibility, send the unlock intent, and surface a clear ride-started state the moment the controller acknowledges.

Because the controller acknowledgement can lag on weak cellular, the iOS flow is built around explicit ride states — idle, unlocking, ride started, ending — rather than optimistic UI that pretends the scooter unlocked before it confirmed. A rider is never moved into a billable ride until the backend has a confirmed unlock from the controller, which is the single most important correctness property in a scooter app. The end-to-end iOS surface is delivered as part of our mobile app development practice.

E-scooter active ride screen — live trip metering with lock control and geofenced ride zone on Android

Android build — Kotlin, foreground service, and the live ride

The Android client is written in Kotlin and runs the active ride inside a foreground service. The foreground service is mandatory: on Samsung, Xiaomi, OnePlus, and Pixel device families, aggressive battery optimizers terminate background-only processes within minutes, and a scooter ride cannot afford to lose its connection to the trip-metering and geofencing logic mid-ride. The service keeps the ride session alive, streams the rider's GPS position back to the backend for fleet tracking and geofence checks, and updates the live distance, elapsed time, and running price on screen while exposing an in-ride lock control.

The geofencing logic is the regulatory heart of the platform. As the rider moves, the backend compares the scooter's GPS position against the operating-zone polygons configured in the admin dashboard. Crossing into a slow zone pushes a speed-limit command to the controller; crossing a hard boundary stops the scooter; reaching a parking zone enables ride-end. This server-side enforcement is what lets a US or EU city sign off on the fleet at all, and it works on the same control plane that handles the location streaming reference described in Android location services. The same engineering team carries iOS and Android in lockstep as part of our iOS and Android engineering practice.

E-scooter in-app ride wallet — spend cap budget control with geofenced map, privacy-aligned ride data

Ride wallet, telematics control plane, and privacy posture

The in-app wallet lets a rider preload a balance and set a spend cap, so a single subscription-grade payment state resolves cleanly across rides without re-authorizing a card each trip. Underneath it sits the telematics control plane — a backend that holds the fleet map, the operating-zone polygons, the per-scooter command queue, and the billing ledger. The command queue is the failsafe layer: if a lock or unlock command is sent and the controller does not acknowledge — dropped cellular, depleted battery, controller reboot — the queue retries with backoff and reconciles ride state so a rider is never charged for a scooter that did not actually respond. Identifiers are scoped tightly: the rider's location stream feeds geofence checks and fleet tracking, and is retained as ride history under explicit, region-aware consent rather than mined as a continuous tracking profile.

Data-handling is built to align with GDPR obligations for riders in the European Union and CCPA / CPRA obligations for riders in California and the broader United States — location data is collected for the operational purpose of the ride and geofencing, disclosed plainly, and not repurposed. The fleet operations console, built with React, gives staff a real-time map, zone editor, pricing controls, and per-scooter telematics health.

Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.

Delivery methodology

A five-phase build that took the platform from a physical scooter prototype to production across iOS, Android, and an IoT telematics control plane.

Phase 1

Discovery & hardware analysis

Hands-on analysis of a physical scooter prototype, controller request-and-response protocol mapping, rider-interaction sequence diagrams, US + EU city-permit and geofencing requirements, GDPR + CCPA posture mapping.

Phase 2

Telematics control plane

Laravel backend skeleton, server-relayed command model, failsafe command queue with acknowledgement and backoff, fleet map, operating-zone polygon model, billing ledger.

Phase 3

Platform builds

Swift iOS rider app and Kotlin Android rider app — live GPS map, QR unlock, ride states, foreground-service trip metering, in-app wallet and spend cap.

Phase 4

Geofencing & QA

Geofence enforcement with auto speed limiting and stop zones, dropped-signal and low-battery failsafe QA, billing-integrity testing, admin React operations dashboard.

Phase 5

Launch & telemetry

App Store + Google Play submission across US and EU storefronts, fleet rollout, real-time fleet observability, and ride-level telemetry feeding pricing and zone tuning.

The admin dashboard — fleet, pricing, and zone management

A shared-scooter business lives or dies by its operations console, so the React admin dashboard was treated as a first-class deliverable rather than an afterthought. Staff get a real-time map of every scooter with its battery level, lock state, and telematics health, and can dispatch field operations for low-battery swaps or relocations. Pricing is fully configurable — start fee, per-minute rate, and time-of-day or zone-based adjustments — without a code release, because micromobility pricing is tuned constantly against demand and city agreements. The zone editor is the regulatory tool: staff draw and edit no-ride zones, slow zones, and parking areas as map polygons, and those polygons flow straight into the geofencing engine that enforces them on the scooters in real time. Because the operating zones, pricing, and fleet inventory all live behind the same control plane, an operator can onboard a new US or EU city as a configuration exercise — new polygons, new pricing, new permit parameters — rather than a code fork, which is exactly the leverage a software platform is supposed to give a hardware business.

Launching across the United States and the European Union

The platform launched on Apple App Store and Google Play with storefronts active across the United States and the European Union, and now serves 5,000+ users on a single English-language build per platform. Micromobility is one of the most locally regulated software categories there is, so the architecture pushes city-specific rules into configuration: each operating zone, speed limit, and parking constraint is data in the admin dashboard, not a per-city codebase. Consent flows are region-aware at the client layer — riders in the EU and EEA receive a GDPR-style granular consent screen covering ride-location processing, and riders in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure in the same flow. Data-handling practices are aligned with GDPR for European users and with the US state-privacy patchwork — CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA — with ride-location data scoped to the operational purpose of the trip and geofencing.

On the European side the platform is structured to support rollout across cities in the Netherlands, Germany, France, Sweden, and Ireland, where shared-scooter permits hinge on demonstrable geofencing and speed control — exactly the capability the control plane was built around. The engineering team behind the build runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and incident response, which is the window that lets a US-facing product team and an EU engineering team share four hours of live overlap every day. Both the App Store age rating and the Google Play content rating were calibrated for a transportation app handling live location.

Tech stack and roadmap

Swift iOS Core Location Kotlin Android Foreground Service Android Location Services Laravel PHP React PostgreSQL Redis MQTT telematics Geofencing engine WebSocket fleet stream Stripe Docker Kubernetes Terraform Prometheus Grafana

The active custom software development roadmap includes dynamic, demand-based pricing, a damage-and-photo ride-end check, a rider rewards tier, and deeper fleet-health analytics that flag scooters trending toward maintenance before they fail in the field. Infrastructure plans include further automation of the telematics command pipeline and a hardened, observable control plane scaffolded into the cloud & DevOps roadmap, so the operator can add US and EU cities without re-architecting. The platform serves the broader logistics and mobility space, where the same GPS-tracking and IoT-control patterns recur across shared vehicles and last-mile fleets.

Build a micromobility platform like this — talk to us

If you are planning an e-scooter or shared-mobility product where the software has to turn a hardware fleet into a billable, regulator-friendly service for audiences in the US and EU, we have shipped this stack end-to-end — rider apps, telematics control plane, geofencing, and operations dashboard — and can compress the build timeline meaningfully. The case is documented at yusmpgroup.ru, and the engineering team behind it sits inside YuSMP Group. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.

Book a discovery call See mobile development services

Frequently asked questions

How much does it cost to build an e-scooter sharing app like Lime or Bird?

A micromobility MVP covering iOS and Android rider apps, a GPS scooter map, QR unlock, trip metering, and a basic admin dashboard typically costs $140k–$280k. Adding a full IoT telematics control plane, geofencing with auto speed limiting, failsafe lock handling, an in-app wallet, and dynamic pricing brings a complete platform to $320k–$700k. The dominant cost drivers are the scooter-controller communication layer, the geofencing engine, and the operations dashboard for fleet, pricing, and zone management.

How does remote lock and unlock work in a scooter sharing app?

The rider app never talks to the scooter directly. A QR scan or a tap sends an intent to the backend, which relays a signed lock or unlock command down the telematics channel to the controller on the scooter. The controller acknowledges, and the app updates ride state. The hard part is the failsafe path: the command queue must handle dropped cellular signal, low battery, and partial acknowledgements so a rider is never charged for a scooter that did not actually unlock.

What is geofencing and why does a scooter platform need it?

Geofencing defines virtual boundaries on the map — no-ride zones, slow zones, and parking areas. When a scooter's GPS position crosses a boundary, the platform sends the controller a command to reduce speed or stop. This is a core urban-safety and regulatory requirement: most US and EU cities license shared scooters on the condition that operators can enforce speed limits and keep scooters out of pedestrian areas, so the geofencing engine is not optional, it is the permit.

How long does it take to launch a scooter sharing app on iOS and Android?

A focused MVP with a GPS scooter map, QR unlock, trip metering, an in-app wallet, and both store submissions typically takes 16–22 weeks. Adding the full IoT telematics control plane, geofencing with auto speed limiting, failsafe lock handling, and the operations dashboard adds 8–12 weeks. The hardware-integration discovery — working with a physical scooter prototype to map the controller's request and response protocol — is frequently underestimated and should be budgeted as its own phase.

Why hire a software team to build a micromobility platform if you already own the scooters?

Owning the hardware and the city permits is one half of the business; the other half is the software that turns a parked scooter into a rentable, trackable, billable asset. Complex telematics, GPS fleet tracking, geofencing, and a payment-grade ride wallet are specialized engineering domains. A team that has shipped this stack for iOS and Android can map the controller protocol from a physical prototype, build the failsafe command layer, and stand up the admin platform far faster than building that capability in-house from scratch.

Related cases

More mobile & mobility platform builds

Mobility · Booking

Share this case

LinkedIn X

Plan a similar build

Book a discovery call

← Previous case MakeWake Next case → Light Rent