Case study · Logistics · Last-mile · Mobile

Refactoring xRouten: an Android & iOS Last-Mile Logistics App for a German Operator

Published Oct 21, 2025 · Updated Oct 21, 2025 · By YuSMP Group Engineering

How we took a critically unstable legacy Android app — live with a German logistics operator and bleeding revenue on failed deliveries — stabilised it, refactored its routing core, and then shipped a ready-to-publish iOS counterpart. Multi-point route optimisation, real-time driver tracking, in-app invoicing and payments, delivered for production fleets in Germany and ready to scale across the European Union and the United States.

IndustryLogistics · Last-mile · Mobile

Project year2024

EngagementRefactor + new build

Book a discovery call See mobile development services

xRouten logistics app — multi-point route map on Android

The brief — stop the bleeding, then ship iOS

xRouten is a navigation and route-planning product for business fleets, built and operated out of Germany. When the client engaged YuSMP, the existing Android app was live with paying logistics operators but suffered from low performance, frequent errors, and critical bugs that directly disrupted business operations — failed deliveries, missed pickup windows, and real financial losses for the operator's end customers. The product team needed two things in a single engagement: first, an emergency stabilisation pass on the production Android app to halt user churn and restore trust; second, an iOS counterpart with full feature parity so the operator could expand its driver fleet onto iPhone hardware. We took on both — legacy refactoring of the unstable Android codebase in Kotlin, followed by a from-scratch iOS build in Swift sharing the same backend — and delivered a ready-to-publish product for both Google Play and the Apple App Store, live with a German logistics operator and ready to scale into the wider European Union and United States markets.

Project highlights

Legacy Android stabilisation in Kotlin High-speed multi-point route building Real-time driver location tracking In-app invoice generation Working payment system Redesigned modern UI Ready-to-publish iOS counterpart Live with a German logistics operator

By the numbers

A snapshot of what the xRouten engagement delivered across Android refactor and iOS new-build.

2native platforms — Android (Kotlin) refactored to a stable production baseline and iOS (Swift) built from scratch with feature parity

3core features rebuilt — multi-point routing, real-time tracking, and in-app invoicing with payment

DEprimary deployment — German-language interface and documentation, live with a German logistics operator

Real-timedriver location streaming on the dispatcher map, smooth movement between GPS samples without stuttering

0critical errors carried over from the previous version — the production-blocking bug class was eliminated in the refactor

10–16 wktypical schedule for a comparable Android stabilisation pass before iOS feature-parity work begins

xRouten multi-point route map — optimised stop sequence across a German city on Android

High-speed multi-point route building

The single most business-critical surface in xRouten is the route builder. A dispatcher or driver feeds the app a list of stops — sometimes a handful, often dozens — and the app must return an optimised sequence in a time short enough to feel instant. In the legacy build, this computation was unreliable: routes failed to calculate, timed out, or returned obviously suboptimal sequences that wasted driver hours and burned fuel. We rewrote the routing core against a mapping-SDK matrix API: the client submits the stop list to a server-side optimiser that fetches pairwise distance and ETA, runs a 2-opt heuristic over the resulting matrix, and returns a near-optimal stop sequence with turn-by-turn directions for each leg.

The mobile client renders the route, supports incremental re-optimisation when stops are added mid-shift or marked complete, and caches the matrix per route so that a single completed delivery does not trigger a full recomputation. The result is a route builder that returns instant calculation of optimal paths between dozens of stops — exactly the user-facing behaviour the client had asked for from the beginning of the relationship. The same architecture is reused in the iOS build with no backend changes: the optimiser is platform-agnostic and the mobile clients are thin renderers over a shared custom software development stack.

Legacy xRouten Android vs refactored Kotlin build — at a glance
Dimension	Legacy build (pre-engagement)	Refactored build (post-engagement)
Multi-point route calculation	Timeouts and obviously-suboptimal sequences	Instant calculation against a matrix API + 2-opt solver
Driver location tracking	Sporadic updates, stuttering map markers	Smooth real-time streaming with adaptive sampling
Invoice & payment	Out-of-app workaround — drivers used external tools	In-app invoice generation + working payment system
Critical errors on production	Multiple — driving failed deliveries and revenue loss	Eliminated in the refactor
UI & brand perception	Dated; user complaints visible in store reviews	Redesigned modern interface improving UX
iOS availability	None — Android only	Ready-to-publish Swift build with feature parity

Platform references: Kotlin, Swift, Android Foreground Services, Apple CoreLocation.

xRouten driver-tracking dashboard — real-time fleet positions on a German city map

Real-time driver tracking — smooth, reliable, battery-aware

The second core feature was reliable real-time location streaming for the operator's drivers, rendered smoothly on a dispatcher map without the stutter and gaps that plagued the legacy build. On Android we lean on a Kotlin foreground service to keep GPS sampling alive across Doze mode and the aggressive battery optimisers shipped by Samsung, Xiaomi, OnePlus, and Pixel device families — without it, location updates die within minutes of the screen turning off. On iOS the equivalent surface uses CoreLocation with the appropriate background-location authorisation, paired with significant-change monitoring as a power-efficient fallback.

Sampling is adaptive: at low speeds in dense city traffic the driver's coordinates update every five to ten seconds; on the autobahn between German cities the sampling rate stretches out, because the dispatcher does not need 1 Hz precision when a vehicle is moving in a straight line at 120 km/h. The dispatcher view interpolates between samples so the marker glides instead of jumping, which makes a coarse sampling rate feel smooth to the operator. Location updates stream over a persistent WebSocket — the same transport choice used for chat in our consumer mobile app development work — so a brief connectivity hiccup (carrier handoff between LTE and 5G, common on long-distance German routes) recovers in under two seconds without losing the last-known position.

xRouten in-app invoice generation and payment confirmation screen

Digital documentation — invoices and payments inside the app

The third pillar of the refactor was a digital documentation module: at the point of delivery, the driver generates an invoice for the customer directly from the app, sends it from the same screen, and collects payment without leaving the workflow. In the legacy product, drivers had improvised around this gap using paper or unrelated apps — a documentation trail that broke German compliance expectations and slowed down every drop. The new module produces a structured invoice (PDF for the customer, structured data for the operator's back office), attaches delivery proof, and routes payment through an integrated payment gateway — not App Store in-app purchase, which Apple explicitly excludes for physical goods and services.

Reliability comes from a two-phase commit between the invoice issuance and the payment intent: a network drop in the field cannot result in a charge without a corresponding invoice, and cannot result in an invoice without a recorded payment outcome. The flow accepts a successful capture, a deferred capture (driver is in a basement and offline — invoice is queued for sync on next connection), and a hard failure (card declined — driver sees an inline error and can take an alternative payment in the same screen). The result is the working payment system the client had asked for from the beginning, with transaction reliability that matches what the operator's customers expect from any modern German last-mile service.

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

xRouten refactor architecture — before vs after module diagram

Working on legacy code, in a foreign language, under production stakes

Three project characteristics made xRouten a non-trivial engagement and shaped how we ran the work. First, the codebase was a legacy product with an unstable existing surface — we were not greenfielding into empty space, we were stabilising a running system that real drivers depended on. That meant every change had to be defensible against the existing user base: refactor in layers, gate new code paths behind feature flags, ship intermediate releases that incrementally retired the worst bug classes rather than a single big-bang rewrite that would have stranded operators on a broken build for weeks.

Second, the stakes were high in a way that consumer apps rarely are: an app error did not produce a bad user experience, it produced a failed delivery and a real financial loss for the operator's end customer. That asymmetry pushed us toward defensive engineering — explicit error states surfaced to the driver, retries with exponential backoff for any network operation that mutated state, and offline-first behaviour for the in-field surfaces so a connectivity gap never silently lost work.

Third, there were language and geographic barriers: the entire product interface and documentation are German, and validating the routing layer required testing against German maps and German address conventions from a Russia-based engineering team. We treated that as an engineering discipline rather than a problem — German-speaking review on every UI string, German address fixtures in the routing test suite, and a QA matrix that exercised the app against real Deutsche Post and DHL pickup patterns rather than synthetic test data. That discipline is the same one we apply when we run a dedicated development team for any US or EU customer where the operating market is not the engineering team's first language.

Delivery methodology

A five-phase engagement that took xRouten from an unstable live Android product to a ready-to-publish iOS and Android pair.

Phase 1

Triage & stabilisation

Audit of the legacy Android codebase, critical-bug inventory, prioritisation by business impact (failed deliveries first), hotfix releases to halt user churn while the deeper refactor is scoped.

Phase 2

Routing core refactor

Rewrite of the multi-point route builder in Kotlin against a mapping-SDK matrix API with a 2-opt heuristic, regression suite over real German address fixtures, incremental rollout behind a feature flag.

Phase 3

Tracking & documentation

Foreground-service-based real-time location streaming, dispatcher-side smooth interpolation, in-app invoice generator and payment-gateway integration with two-phase commit semantics.

Phase 4

UI redesign & iOS build

Modern redesigned interface applied to both platforms, Swift iOS client built against the same backend with feature parity for routing, tracking, invoicing, and payments.

Phase 5

Release & handover

Production Google Play release for the refactored Android app, ready-to-publish iOS build for App Store submission, German-language QA pass, runbook and on-call handover to the client.

What the refactor delivered

By the end of the engagement, the xRouten product had moved from an unstable Android app generating support escalations into a production-ready release for both App Store and Google Play. The critical errors that had been driving failed deliveries in the legacy version were eliminated; the redesigned modern interface improved both user experience and brand perception for the operator's drivers and customers; the in-app payment system delivered transaction reliability the previous build had simply not offered; and the refactored architecture is structured so the operator's product team can add new features — additional payment methods, fleet-level analytics, multi-tenant support for sub-contractors — without inheriting the technical debt of the original build. The same shared backend serves both the Android refactor and the iOS new build, so a single product roadmap drives both platforms going forward.

Live in Germany — ready for the EU and the US

xRouten is live with a German last-mile logistics operator and built on the same engineering posture we use across our work for customers in the United States and the European Union. The app is German-first today — German interface, German-language documentation, validated against German addresses, road networks, and delivery patterns — but the architecture is region-agnostic. The mapping-SDK abstraction supports US street networks and address formats without code changes, the payment gateway integration can swap regional processors per market, and the foreground-service and CoreLocation stacks behave identically on US-issued and EU-issued devices.

Privacy posture mirrors the rest of our portfolio: the app is aligned with GDPR for European users — relevant immediately in Germany, France, the Netherlands, Ireland, and Sweden — and ready to meet the US state-privacy patchwork: CCPA / CPRA in California, VCDPA in Virginia, CPA in Colorado, CTDPA in Connecticut, UCPA in Utah, TDPSA in Texas, and Oregon CPA. Driver location data is the most sensitive surface in a logistics app — it is, by definition, employee monitoring data — and the architecture separates location streams from identity at the storage layer, with retention windows configurable per operator to match the German Works Council expectations that govern this category of data in the EU.

Tech stack and roadmap

Kotlin Swift Android Foreground Services CoreLocation Mapping SDK + matrix API 2-opt route optimiser WebSocket streaming Geocoding Payment gateway REST API backend PostgreSQL Redis PDF / invoice generation APNs + FCM Docker GitHub Actions Crashlytics

The roadmap for xRouten extends the refactored foundation in directions the operator could not safely attempt on the legacy build: fleet-level analytics (driver productivity, route cost per drop, fuel and time variance against the optimised plan), multi-tenant support so sub-contracted couriers can run their own driver pools inside the operator's account, additional regional payment methods (SEPA direct debit, Klarna, Apple Pay and Google Pay), and a dispatcher-side web console that mirrors the mobile app's data model. Infrastructure plans include a tighter SLO on the routing optimiser (sub-second response for routes up to 50 stops) and EU data-residency commitments backed by region-pinned database partitions to match the German operator's privacy expectations under GDPR.

Frequently asked questions

How much does it cost to refactor a legacy Android logistics app and add an iOS counterpart?

A focused legacy stabilisation pass on an Android app — eliminating critical errors, refactoring the routing core, and shipping a production-ready release — typically costs $80k–$180k depending on codebase size and test coverage. Building an iOS counterpart with feature parity (multi-point routing, real-time tracking, invoicing, payments) on top of a shared backend usually adds $120k–$250k. Cost drivers include the mapping SDK choice, payment gateway integrations, and the QA effort required to validate route optimisation against real German addresses and traffic data.

How do you build high-speed multi-point route optimisation on mobile?

Multi-point route optimisation on mobile is a variant of the Travelling Salesman Problem. For business fleets with dozens of stops per route, the calculation runs server-side against a mapping provider's matrix API (distance and ETA between every stop pair), with a heuristic solver — typically a 2-opt or Lin–Kernighan variant — finding a near-optimal sequence in milliseconds. The mobile client renders the result and handles incremental re-optimisation when stops are added, removed, or completed in the field. Caching the matrix per route and only re-querying changed pairs keeps response times low even as drivers progress through deliveries.

What does real-time driver tracking actually require in production?

Production real-time driver tracking has three moving parts: a foreground service on Android (and a background location authorisation on iOS) that keeps GPS sampling alive across device sleep and battery optimisers; a transport layer — WebSocket or MQTT — that streams location updates to a backend with sub-second latency; and a dispatcher view that interpolates between samples to render smooth movement on a map without stuttering. Battery is the dominant constraint: sampling at 1 Hz drains a phone fast, so a real build adaptively samples at 5–30 second intervals depending on speed and route geometry.

How do you handle in-app invoicing and payments inside a logistics workflow?

In-app invoicing for a logistics workflow generates a structured invoice document (PDF or compliant German XRechnung-style data) at the point of delivery, attaches the driver's signature and delivery proof, and sends it to the customer via email or in-app link. Payment is typically handled by a separate payment gateway (Stripe, Adyen, or a German-market processor) rather than the App Store's in-app purchase, because the goods being paid for are physical deliveries, not digital content — App Store IAP rules explicitly exclude this category. Reliability comes from a two-phase commit between the invoice issuance and the payment intent, so a network drop in the field cannot create a charge without a corresponding invoice record.

How long does it take to refactor an existing logistics Android app and ship iOS?

A legacy Android stabilisation pass — auditing critical bugs, refactoring the routing core, and shipping a fixed release to Google Play — typically takes 10–16 weeks for an app the size of xRouten. Building the iOS counterpart with full feature parity, including invoicing and payment flows, adds 14–20 weeks. The dominant schedule risks are mapping-SDK licensing alignment, German-market QA (testing routes against real Deutsche Post and DHL pickup patterns), and App Store / Google Play review cycles when a previously-unstable app re-enters the store with substantially changed permissions.

Plan a logistics app build or refactor — talk to us

If you operate a last-mile or fleet logistics product — anywhere in the United States, the European Union, or in a market like Germany where compliance and language nuance matter — and you are weighing a legacy refactor, an iOS or Android extension, or a new build, we have shipped this stack end-to-end for a live German operator and can compress the build timeline meaningfully. The engineering team behind xRouten sits inside YuSMP Group. We work fixed-price for well-scoped refactors 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.

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

Book a discovery call See mobile development services

Related services