Fallstudie · Logistik · Last-Mile · Mobile
Wie wir eine kritisch instabile Legacy-Android-App — live bei einem deutschen Logistikbetreiber und mit Umsatzverlusten durch fehlgeschlagene Zustellungen — stabilisiert, ihren Routing-Kern überarbeitet und dann ein veröffentlichungsbereites iOS-Pendant ausgeliefert haben. Mehrpunkt-Routenoptimierung, Echtzeit-Fahrer-Tracking, In-App-Rechnungsstellung und -Zahlungen, geliefert für produktive Flotten in Deutschland und bereit, über die Europäische Union und die USA hinweg zu skalieren.
xRouten ist ein Navigations- und Routenplanungsprodukt für Geschäftsflotten, das in Deutschland entwickelt und betrieben wird. Als der Kunde YuSMP beauftragte, war die bestehende Android-App bei zahlenden Logistikbetreibern live, litt aber unter niedriger Performance, häufigen Fehlern und kritischen Bugs, die den Geschäftsbetrieb direkt störten — fehlgeschlagene Zustellungen, verpasste Abholfenster und echte finanzielle Verluste für die Endkunden des Betreibers. Das Produktteam benötigte zwei Dinge in einem einzigen Engagement: erstens einen Notfall-Stabilisierungsdurchlauf an der produktiven Android-App, um die Nutzerabwanderung zu stoppen und Vertrauen wiederherzustellen; zweitens ein iOS-Pendant mit voller Funktionsparität, damit der Betreiber seine Fahrerflotte auf iPhone-Hardware ausweiten konnte. Wir übernahmen beides — Legacy-Refactoring der instabilen Android-Codebasis in Kotlin, gefolgt von einem iOS-Build von Grund auf in Swift, der dasselbe Backend nutzt — und lieferten ein veröffentlichungsbereites Produkt sowohl für Google Play als auch den Apple App Store, live bei einem deutschen Logistikbetreiber und bereit, in die breiteren Märkte der Europäischen Union und der USA zu skalieren.
Ein Überblick darüber, was das xRouten-Engagement über Android-Refactoring und iOS-Neuentwicklung hinweg geliefert hat.
Die mit Abstand geschäftskritischste Oberfläche in xRouten ist der Routenplaner. Ein Disponent oder Fahrer gibt der App eine Liste von Stopps ein — manchmal eine Handvoll, oft Dutzende — und die App muss eine optimierte Reihenfolge in einer Zeit zurückgeben, die kurz genug ist, um sich sofort anzufühlen. Im Legacy-Build war diese Berechnung unzuverlässig: Routen ließen sich nicht berechnen, liefen in einen Timeout oder lieferten offensichtlich suboptimale Reihenfolgen, die Fahrerstunden verschwendeten und Kraftstoff verbrannten. Wir schrieben den Routing-Kern gegen eine Mapping-SDK-Matrix-API neu: Der Client übermittelt die Stopp-Liste an einen serverseitigen Optimierer, der paarweise Distanz und ETA abruft, eine 2-opt-Heuristik über die resultierende Matrix laufen lässt und eine nahezu optimale Stopp-Reihenfolge mit Turn-by-Turn-Anweisungen für jede Etappe zurückgibt.
Der mobile Client stellt die Route dar, unterstützt die inkrementelle Neuoptimierung, wenn Stopps mitten in der Schicht hinzugefügt oder als abgeschlossen markiert werden, und speichert die Matrix pro Route zwischen, sodass eine einzelne abgeschlossene Zustellung keine vollständige Neuberechnung auslöst. Das Ergebnis ist ein Routenplaner, der die sofortige Berechnung optimaler Wege zwischen Dutzenden Stopps liefert — genau das nutzerseitige Verhalten, das der Kunde von Beginn der Beziehung an gefordert hatte. Dieselbe Architektur wird im iOS-Build ohne Backend-Änderungen wiederverwendet: Der Optimierer ist plattformunabhängig, und die mobilen Clients sind schlanke Renderer über einem gemeinsamen Stack für individuelle Softwareentwicklung.
| Dimension | Legacy-Build (vor dem Engagement) | Überarbeiteter Build (nach dem Engagement) |
|---|---|---|
| Mehrpunkt-Routenberechnung | Timeouts und offensichtlich suboptimale Reihenfolgen | Sofortige Berechnung gegen eine Matrix-API + 2-opt-Solver |
| Ortung des Fahrerstandorts | Sporadische Updates, ruckelnde Kartenmarker | Flüssiges Echtzeit-Streaming mit adaptivem Sampling |
| Rechnung & Zahlung | App-externe Notlösung — Fahrer nutzten externe Tools | In-App-Rechnungserzeugung + funktionierendes Zahlungssystem |
| Kritische Fehler in der Produktion | Mehrere — verursachten fehlgeschlagene Zustellungen und Umsatzverluste | Im Refactoring beseitigt |
| UI & Markenwahrnehmung | Veraltet; Nutzerbeschwerden in Store-Bewertungen sichtbar | Neugestaltete moderne Oberfläche, die die UX verbessert |
| iOS-Verfügbarkeit | Keine — nur Android | Veröffentlichungsbereiter Swift-Build mit Funktionsparität |
Plattform-Referenzen: Kotlin, Swift, Android Foreground Services, Apple CoreLocation.
Die zweite Kernfunktion war ein zuverlässiges Echtzeit-Standort-Streaming für die Fahrer des Betreibers, flüssig auf einer Disponentenkarte dargestellt, ohne das Ruckeln und die Lücken, die den Legacy-Build plagten. Auf Android setzen wir auf einen Kotlin-Vordergrunddienst, um das GPS-Sampling über den Doze-Modus und die aggressiven Batterie-Optimierer von Samsung-, Xiaomi-, OnePlus- und Pixel-Gerätefamilien hinweg am Leben zu halten — ohne ihn sterben die Standort-Updates innerhalb von Minuten, nachdem der Bildschirm ausgeschaltet wurde. Auf iOS nutzt die entsprechende Oberfläche CoreLocation mit der passenden Hintergrund-Standortberechtigung, gepaart mit Significant-Change-Monitoring als energieeffizientem Fallback.
Das Sampling ist adaptiv: bei niedrigen Geschwindigkeiten im dichten Stadtverkehr aktualisieren sich die Koordinaten des Fahrers alle fünf bis zehn Sekunden; auf der Autobahn zwischen deutschen Städten dehnt sich die Sampling-Rate, weil der Disponent keine 1-Hz-Genauigkeit braucht, wenn sich ein Fahrzeug geradlinig mit 120 km/h bewegt. Die Disponenten-Ansicht interpoliert zwischen den Messpunkten, sodass der Marker gleitet statt zu springen, was eine grobe Sampling-Rate für den Betreiber flüssig wirken lässt. Standort-Updates streamen über einen persistenten WebSocket — dieselbe Transportwahl, die wir für Chat in unserer Consumer-Mobile App-Entwicklung verwenden — sodass ein kurzer Konnektivitäts-Aussetzer (Mobilfunk-Übergabe zwischen LTE und 5G, häufig auf langen deutschen Routen) in unter zwei Sekunden behoben wird, ohne die zuletzt bekannte Position zu verlieren.
Die dritte Säule des Refactorings war ein digitales Dokumentationsmodul: Am Zustellpunkt erzeugt der Fahrer direkt aus der App eine Rechnung für den Kunden, sendet sie vom selben Bildschirm aus und kassiert die Zahlung ein, ohne den Workflow zu verlassen. Im Legacy-Produkt hatten Fahrer diese Lücke mit Papier oder fremden Apps improvisiert — eine Dokumentationsspur, die deutsche Compliance-Erwartungen verletzte und jede Zustellung verlangsamte. Das neue Modul erzeugt eine strukturierte Rechnung (PDF für den Kunden, strukturierte Daten für das Back-Office des Betreibers), hängt den Zustellnachweis an und leitet die Zahlung über ein integriertes Zahlungs-Gateway — nicht über App-Store-In-App-Käufe, die Apple für physische Güter und Dienstleistungen ausdrücklich ausschließt.
Die Zuverlässigkeit kommt von einem Zwei-Phasen-Commit zwischen der Rechnungsausstellung und der Zahlungsabsicht: Ein Netzwerkausfall im Feld kann keine Belastung ohne eine entsprechende Rechnung ergeben und keine Rechnung ohne ein erfasstes Zahlungsergebnis. Der Ablauf akzeptiert eine erfolgreiche Erfassung, eine aufgeschobene Erfassung (der Fahrer ist in einem Keller und offline — die Rechnung wird zur Synchronisation bei der nächsten Verbindung in die Warteschlange gestellt) und einen harten Fehlschlag (Karte abgelehnt — der Fahrer sieht einen Inline-Fehler und kann im selben Bildschirm eine alternative Zahlung annehmen). Das Ergebnis ist das funktionierende Zahlungssystem, das der Kunde von Anfang an gefordert hatte, mit einer Transaktionszuverlässigkeit, die dem entspricht, was die Kunden des Betreibers von jedem modernen deutschen Last-Mile-Service erwarten.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Drei Projektmerkmale machten xRouten zu einem nicht-trivialen Engagement und prägten, wie wir die Arbeit gestalteten. Erstens war die Codebasis ein Legacy-Produkt mit einer instabilen bestehenden Oberfläche — wir entwickelten nicht auf der grünen Wiese, wir stabilisierten ein laufendes System, auf das echte Fahrer angewiesen waren. Das bedeutete, dass jede Änderung gegenüber der bestehenden Nutzerbasis vertretbar sein musste: Refactoring in Schichten, neue Code-Pfade hinter Feature-Flags absichern, Zwischen-Releases ausliefern, die die schlimmsten Bug-Klassen inkrementell ausmusterten, statt einer einzigen Big-Bang-Neuentwicklung, die Betreiber wochenlang auf einem kaputten Build gestrandet hätte.
Zweitens war der Einsatz hoch, wie es bei Consumer-Apps selten der Fall ist: Ein App-Fehler erzeugte kein schlechtes Nutzererlebnis, er erzeugte eine fehlgeschlagene Zustellung und einen echten finanziellen Verlust für den Endkunden des Betreibers. Diese Asymmetrie drängte uns zu defensivem Engineering — explizite Fehlerzustände, die dem Fahrer angezeigt werden, Wiederholungen mit exponentiellem Backoff für jede Netzwerkoperation, die einen Zustand veränderte, und Offline-First-Verhalten für die Feldoberflächen, sodass eine Konnektivitätslücke niemals stillschweigend Arbeit verlor.
Drittens gab es sprachliche und geografische Barrieren: Die gesamte Produktoberfläche und Dokumentation sind auf Deutsch, und die Validierung der Routing-Schicht erforderte Tests gegen deutsche Karten und deutsche Adresskonventionen durch ein in Russland ansässiges Entwicklerteam. Wir behandelten das als Engineering-Disziplin statt als Problem — deutschsprachiges Review bei jedem UI-String, deutsche Adress-Fixtures in der Routing-Testsuite und eine QA-Matrix, die die App gegen echte Abholmuster von Deutsche Post und DHL statt gegen synthetische Testdaten durchexerzierte. Diese Disziplin ist dieselbe, die wir anwenden, wenn wir ein dediziertes Entwicklerteam für einen US- oder EU-Kunden betreiben, bei dem der Betriebsmarkt nicht die Muttersprache des Entwicklerteams ist.
Ein fünfphasiges Engagement, das xRouten von einem instabilen, live laufenden Android-Produkt zu einem veröffentlichungsbereiten iOS- und Android-Paar führte.
Audit der Legacy-Android-Codebasis, Inventar kritischer Bugs, Priorisierung nach Geschäftsauswirkung (fehlgeschlagene Zustellungen zuerst), Hotfix-Releases zum Stoppen der Nutzerabwanderung, während das tiefere Refactoring abgegrenzt wird.
Neuschreiben des Mehrpunkt-Routenplaners in Kotlin gegen eine Mapping-SDK-Matrix-API mit einer 2-opt-Heuristik, Regressionssuite über echte deutsche Adress-Fixtures, inkrementeller Rollout hinter einem Feature-Flag.
Vordergrunddienst-basiertes Echtzeit-Standort-Streaming, flüssige Interpolation auf Disponentenseite, In-App-Rechnungsgenerator und Zahlungs-Gateway-Integration mit Zwei-Phasen-Commit-Semantik.
Modern neugestaltete Oberfläche auf beide Plattformen angewendet, Swift-iOS-Client gegen dasselbe Backend gebaut mit Funktionsparität für Routing, Tracking, Rechnungsstellung und Zahlungen.
Produktiver Google-Play-Release für die überarbeitete Android-App, veröffentlichungsbereiter iOS-Build für die App-Store-Einreichung, deutschsprachiger QA-Durchlauf, Runbook und On-Call-Übergabe an den Kunden.
Bis zum Ende des Engagements hatte sich das xRouten-Produkt von einer instabilen Android-App, die Support-Eskalationen erzeugte, zu einem produktionsreifen Release für sowohl App Store als auch Google Play gewandelt. Die kritischen Fehler, die in der Legacy-Version fehlgeschlagene Zustellungen verursacht hatten, wurden beseitigt; die neugestaltete moderne Oberfläche verbesserte sowohl das Nutzererlebnis als auch die Markenwahrnehmung für die Fahrer und Kunden des Betreibers; das In-App-Zahlungssystem lieferte eine Transaktionszuverlässigkeit, die der vorherige Build schlicht nicht geboten hatte; und die überarbeitete Architektur ist so strukturiert, dass das Produktteam des Betreibers neue Funktionen hinzufügen kann — zusätzliche Zahlungsmethoden, Flotten-Analytics, Mandantenfähigkeit für Subunternehmer — ohne die technischen Schulden des ursprünglichen Builds zu erben. Dasselbe gemeinsame Backend bedient sowohl das Android-Refactoring als auch die iOS-Neuentwicklung, sodass eine einzige Produkt-Roadmap beide Plattformen künftig vorantreibt.
xRouten ist bei einem deutschen Last-Mile-Logistikbetreiber live und auf derselben Engineering-Aufstellung gebaut, die wir in unserer gesamten Arbeit für Kunden in den USA und der Europäischen Union verwenden. Die App ist heute Deutsch-first — deutsche Oberfläche, deutschsprachige Dokumentation, validiert gegen deutsche Adressen, Straßennetze und Zustellmuster — aber die Architektur ist regionsunabhängig. Die Mapping-SDK-Abstraktion unterstützt US-Straßennetze und Adressformate ohne Code-Änderungen, die Zahlungs-Gateway-Integration kann regionale Prozessoren je Markt austauschen, und die Vordergrunddienst- und CoreLocation-Stacks verhalten sich auf in den USA und in der EU ausgegebenen Geräten identisch.
Die Datenschutz-Aufstellung spiegelt den Rest unseres Portfolios: Die App ist mit der DSGVO für europäische Nutzer ausgerichtet — sofort relevant in Deutschland, Frankreich, den Niederlanden, Irland und Schweden — und bereit, den Flickenteppich der US-Bundesstaaten-Datenschutzgesetze zu erfüllen: CCPA / CPRA in Kalifornien, VCDPA in Virginia, CPA in Colorado, CTDPA in Connecticut, UCPA in Utah, TDPSA in Texas und Oregon CPA. Fahrerstandortdaten sind die sensibelste Oberfläche in einer Logistik-App — sie sind per Definition Mitarbeiterüberwachungsdaten — und die Architektur trennt Standort-Streams auf der Speicherebene von der Identität, mit Aufbewahrungsfenstern, die pro Betreiber konfigurierbar sind, um den Erwartungen des deutschen Betriebsrats zu entsprechen, die diese Datenkategorie in der EU regeln.
Die Roadmap für xRouten erweitert das überarbeitete Fundament in Richtungen, die der Betreiber auf dem Legacy-Build nicht sicher hätte versuchen können: Flotten-Analytics (Fahrerproduktivität, Routenkosten pro Zustellung, Kraftstoff- und Zeitabweichung gegenüber dem optimierten Plan), Mandantenfähigkeit, sodass beauftragte Kuriere ihre eigenen Fahrer-Pools innerhalb des Betreiberkontos betreiben können, zusätzliche regionale Zahlungsmethoden (SEPA-Lastschrift, Klarna, Apple Pay und Google Pay) sowie eine disponentenseitige Web-Konsole, die das Datenmodell der mobilen App spiegelt. Die Infrastrukturpläne umfassen ein strengeres SLO für den Routing-Optimierer (Antwort im Sub-Sekunden-Bereich für Routen mit bis zu 50 Stopps) und EU-Datenresidenz-Verpflichtungen, gestützt auf regional gebundene Datenbankpartitionen, um den Datenschutzerwartungen des deutschen Betreibers unter der DSGVO zu entsprechen.
Ein fokussierter Legacy-Stabilisierungsdurchlauf einer Android-App — Beseitigung kritischer Fehler, Refactoring des Routing-Kerns und Auslieferung eines produktionsreifen Releases — kostet typischerweise 80.000–180.000 $, abhängig von Codebasis-Größe und Testabdeckung. Der Bau eines iOS-Pendants mit Funktionsparität (Mehrpunkt-Routing, Echtzeit-Tracking, Rechnungsstellung, Zahlungen) auf einem gemeinsamen Backend ergänzt üblicherweise 120.000–250.000 $. Zu den Kostentreibern gehören die Wahl des Mapping-SDK, die Zahlungs-Gateway-Integrationen und der QA-Aufwand, der erforderlich ist, um die Routenoptimierung gegen echte deutsche Adressen und Verkehrsdaten zu validieren.
Mehrpunkt-Routenoptimierung auf Mobilgeräten ist eine Variante des Problems des Handlungsreisenden. Für Geschäftsflotten mit Dutzenden Stopps pro Route läuft die Berechnung serverseitig gegen die Matrix-API eines Mapping-Anbieters (Distanz und ETA zwischen jedem Stopp-Paar), wobei ein heuristischer Solver — typischerweise eine 2-opt- oder Lin–Kernighan-Variante — in Millisekunden eine nahezu optimale Reihenfolge findet. Der mobile Client stellt das Ergebnis dar und übernimmt die inkrementelle Neuoptimierung, wenn Stopps im Feld hinzugefügt, entfernt oder abgeschlossen werden. Das Zwischenspeichern der Matrix pro Route und das erneute Abfragen nur geänderter Paare hält die Antwortzeiten niedrig, selbst während Fahrer Zustellungen durchlaufen.
Echtzeit-Fahrer-Tracking in der Produktion hat drei bewegliche Teile: einen Vordergrunddienst auf Android (und eine Hintergrund-Standortberechtigung auf iOS), der das GPS-Sampling über Geräteruhezustand und Batterie-Optimierer hinweg am Leben hält; eine Transportschicht — WebSocket oder MQTT — die Standort-Updates mit Latenz im Sub-Sekunden-Bereich an ein Backend streamt; und eine Disponenten-Ansicht, die zwischen Messpunkten interpoliert, um flüssige Bewegung auf einer Karte ohne Ruckeln darzustellen. Die Batterie ist die dominierende Einschränkung: Sampling mit 1 Hz entleert ein Smartphone schnell, daher tastet ein echter Build adaptiv in Intervallen von 5–30 Sekunden ab, abhängig von Geschwindigkeit und Routengeometrie.
In-App-Rechnungsstellung für einen Logistik-Workflow erzeugt am Zustellpunkt ein strukturiertes Rechnungsdokument (PDF oder konforme Daten im deutschen XRechnung-Stil), hängt die Unterschrift des Fahrers und den Zustellnachweis an und sendet es per E-Mail oder In-App-Link an den Kunden. Die Zahlung wird typischerweise von einem separaten Zahlungs-Gateway (Stripe, Adyen oder ein Prozessor für den deutschen Markt) statt vom In-App-Kauf des App Store abgewickelt, weil die bezahlten Güter physische Zustellungen sind, keine digitalen Inhalte — die App-Store-IAP-Regeln schließen diese Kategorie ausdrücklich aus. Die Zuverlässigkeit kommt von einem Zwei-Phasen-Commit zwischen der Rechnungsausstellung und der Zahlungsabsicht, sodass ein Netzwerkausfall im Feld keine Belastung ohne einen entsprechenden Rechnungsdatensatz erzeugen kann.
Ein Legacy-Android-Stabilisierungsdurchlauf — Prüfung kritischer Bugs, Refactoring des Routing-Kerns und Auslieferung eines korrigierten Releases an Google Play — dauert typischerweise 10–16 Wochen für eine App in der Größe von xRouten. Der Bau des iOS-Pendants mit voller Funktionsparität, einschließlich Rechnungs- und Zahlungsabläufen, ergänzt 14–20 Wochen. Die dominierenden Zeitplanrisiken sind die Abstimmung der Mapping-SDK-Lizenzierung, die QA für den deutschen Markt (Testen von Routen gegen echte Abholmuster von Deutsche Post und DHL) und die Prüfzyklen von App Store / Google Play, wenn eine zuvor instabile App mit wesentlich geänderten Berechtigungen erneut in den Store gelangt.
Wenn Sie ein Last-Mile- oder Flotten-Logistikprodukt betreiben — irgendwo in den USA, der Europäischen Union oder in einem Markt wie Deutschland, wo Compliance und sprachliche Nuancen wichtig sind — und Sie ein Legacy-Refactoring, eine iOS- oder Android-Erweiterung oder eine Neuentwicklung erwägen, dann haben wir diesen Stack Ende-zu-Ende für einen live laufenden deutschen Betreiber ausgeliefert und können den Build-Zeitplan deutlich verkürzen. Das Entwicklerteam hinter xRouten sitzt innerhalb von YuSMP Group. Wir arbeiten zum Festpreis für gut abgegrenzte Refactorings und mit dedizierten Entwicklerteams für laufende Lieferung, mit einem MEZ-Arbeitstag und einem garantierten Überlappungsfenster zur US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Response.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Verwandte Leistungen
iOS-, Android- und plattformübergreifende Apps vom Konzept bis zum App Store mit App-Store-tauglichem Qualitätsanspruch.
Mobile App-Entwicklung entdecken →
AWS-, Azure- und GCP-Migrationen, Kubernetes-Plattformen, CI/CD und Observability für US- & EU-Teams.
Cloud & DevOps entdecken →
Durchgängiges Product Engineering für ambitionierte US- & EU-Unternehmen, gebaut von Senior-Teams nach DSGVO-konformen und SOC-2-orientierten Praktiken.
Individuelle Softwareentwicklung entdecken →Verwandte Fälle
Native iOS- + Android-Social-Plattform mit Geo-Radar-Discovery, Echtzeit-Chat und einer virtuellen Coins-Ökonomie — App Store + Google Play, USA & EU.
Fall ansehen → FinTech · OperativHändler-Web-Plattform mit Bitrix24-CRM-Sync, Dadata-Vorausfüllung und Echtzeit-Sprachbenachrichtigungen — ein einziger Eingangskanal für jede Auto-Finanzierungsanfrage.
Fall ansehen → Consumer-Datenschutz · VPNNative iOS- + Android-VPN mit WireGuard, No-Logs-Backend, Split-Tunnel und App-Store- + Google-Play-Launch für die USA & EU.
Fall ansehen →
Architektur-zuerst-Enterprise-Plattformen mit audit-bereiter Compliance und Integration mit SAP, Salesforce, Workday, Okta.
Mehr erfahren →
Strangler-Fig-Migration von Legacy-Stacks (.NET Framework, Java 8, Monolith) ohne Rip-and-Replace-Risiko.
Mehr erfahren →AWS-, Azure-, GCP-Plattformen mit IaC, Observability und Zero-Downtime-Deploys.
Mehr erfahren →