Leistung
Mobile-App-Entwicklung
Apps, die weiterarbeiten, wenn das Netz es nicht tut.
Für Teams, deren Nutzer nicht am Schreibtisch sitzen — Außendienst, Bauleiter, Lieferteams, Vertrieb unterwegs — und für kundennahe Apps, bei denen die erste Minute darüber entscheidet, ob sie bleibt. Was hier technisch zählt, ist Offline-Verhalten und Sync, nicht die Bildschirme.
Die Entscheidung
Wann das die richtige Wahl ist.
Die meisten mobilen Apps werden im Büro-WLAN vorgeführt und an einem Baustellentor auf lückenhaftem 4G benutzt. Genau in dieser Lücke scheitern sie. Eine App, die Verbindung voraussetzt, bekommt die Schuld für Daten, die sie nie erhalten hat — und wenn das Außendienstteam ihr einmal nicht mehr traut, geht es zurück zum Papier, also genau zu dem Ergebnis, das das Projekt verhindern sollte.
Sync ist der schwierige Teil und meist derjenige, der in einem Satz abgehandelt wurde. Was passiert, wenn zwei Leute denselben Datensatz offline bearbeiten, wenn ein Telefon nach drei Tagen zurückkommt, wenn der Server inzwischen die Regeln geändert hat. Das sind Designentscheidungen, und trifft sie niemand, trifft die App sie selbst — schlecht.
Wir entscheiden das Konfliktmodell vor dem Bauen, machen Offline zum Normalfall statt zum Fehlerfall und testen auf gedrosselter Verbindung statt im WLAN. Die Bildschirme sind die leichtere Hälfte.
Was Sie bekommen
Was die Arbeit umfasst.
Offline-first-Daten
Lokale Speicherung als Quelle der Wahrheit für die Sitzung, mit einer Warteschlange, die das Beenden der App übersteht, und einer bewusst gewählten Konfliktregel.
Sync, den Sie prüfen können
Der Sync-Status ist für Nutzer und Support sichtbar, sodass aus „wurde nicht gespeichert“ eine Frage mit Antwort wird.
Nativ oder Cross-Platform
Kotlin und Swift dort, wo Hardware, Hintergrundarbeit oder Performance es verlangen; eine geteilte Codebasis dort, wo die App überwiegend aus Bildschirmen besteht und die Ersparnis real ist.
Hintergrundarbeit, die wirklich läuft
Geplanter Sync und Upload, der unter Androids Akkubeschränkungen weiterläuft, getestet auf den Hersteller-Skins, die ihn brechen.
Authentifizierung, die sicher scheitert
Token-Ablauf sauber behandelt — eine abgelaufene Sitzung meldet den Nutzer ab, statt eine tote Anfrage endlos zu wiederholen.
Release-Engineering
Signierte Builds, stufenweiser Rollout, Absturzberichte und In-App-Update-Hinweise, damit ein schlechtes Release gestoppt werden kann.
Stack
Womit wir es bauen.
Je Projekt gewählt. Nichts davon wird standardmäßig gesetzt, und das Team, das es pflegen wird, wiegt so schwer wie das Problem.
Android
Kotlin mit Jetpack Compose, Room für lokale Speicherung, WorkManager für Hintergrund-Sync.
iOS
Swift mit SwiftUI und der plattformeigenen Persistenz statt einer Brückenschicht.
Cross-Platform
React Native oder Flutter, wo die App bildschirmgetrieben ist und eine Codebasis die Arbeit wirklich halbiert.
Backend
Dieselbe API, die Ihre Webplattform nutzt, versioniert, damit eine alte App im Feld weiterläuft.
Distribution
Play Store und App Store, oder verwaltete Unternehmensverteilung, wenn die App intern ist.
Vergleich
Cross-Platform oder nativ.
Die erste echte Entscheidung in einem Mobilprojekt. Wir bauen beides, deshalb ist diese Tabelle die tatsächliche Begründung und keine Werbung für unsere Vorliebe.
| Aspekt | Cross-Platform | Nativ |
|---|---|---|
| Am besten geeignet für | Formulare, Listen, Sync — Apps, die überwiegend Bildschirme über einer API sind | Kamera, Standort im Hintergrund, Bluetooth oder dauerhafte Performance |
| Kosten für zwei Plattformen | Etwa ein Build plus plattformspezifischer Feinschliff | Nahe an zwei Builds, und danach zwei Codebasen zu pflegen |
| Offline und Sync | Vollkommen machbar; das Sync-Design zählt weit mehr als das Framework | Dasselbe — das ist eine Entscheidung über das Datenmodell, nicht über die Plattform |
| Hardware- und Betriebssystemfunktionen | Für die gängigen in Ordnung; alles Ungewöhnliche braucht ohnehin ein natives Modul | Direkter Zugriff, und keine Brücke zu debuggen, wenn ein Hersteller sein Verhalten ändert |
| Hintergrundarbeit unter Androids Akkubeschränkungen | Machbar, aber die aggressiven Hersteller-Skins müssen so oder so getestet werden | Leichter zu steuern und leichter zu diagnostizieren, wenn ein Gerät den Prozess beendet |
| Langfristige Wartung | Eine Codebasis, dazu ein Framework mit eigenem Upgrade-Zyklus | Zwei Codebasen, jede aber auf dem gut dokumentierten Weg ihrer Plattform |
Wie es abläuft
Vom ersten Gespräch bis live.
Richtwerte für Arbeit dieser Art. Der Pilot ist nicht optional — nichts wird umgestellt, bevor die Nutzer sagen, dass es trägt.
- 1 Woche
Discovery
Wir entscheiden das Konfliktmodell und das Offline-Verhalten, bevor irgendetwas entworfen wird. Beides nachzurüsten kommt einer Neuentwicklung nahe.
- 4-8 Wochen
Kernentwicklung
Zuerst lokale Speicherung, die Sync-Warteschlange und der wichtigste Arbeitsweg, getestet auf gedrosselter Verbindung statt im Bürо-WLAN.
- 2-3 Wochen
Feldpilot
Echte Nutzer auf ihren eigenen Telefonen — auch den günstigen — während der Papierprozess weiterläuft. Hier werden Offline-Annahmen korrigiert.
- 1-2 Wochen
Release
Store-Einreichung oder verwaltete Verteilung, stufenweiser Rollout, Absturzberichte und ein In-App-Update-Hinweis, damit ein schlechter Build gestoppt werden kann.
Nach dem Launch
Was sich ändert.
- Das Außendienstteam nutzt sie auch nach dem zweiten Monat noch, und das ist der einzige echte Maßstab für eine Feld-App.
- Aus „wurde nicht gespeichert“ wird eine Frage mit Antwort, weil der Sync-Status für Nutzer und Support sichtbar ist.
- Ein Telefon, das drei Tage offline war, gleicht ab, ohne dass jemand Arbeit verliert.
- Eine alte Version im Feld läuft weiter, weil die API versioniert ist statt als aktuell vorausgesetzt.
Bewusst qualitativ beschrieben. Wir veröffentlichen keine Prozentangaben, die wir nicht einem namentlich genannten Kunden mit dessen Zustimmung zuordnen können.
Fragen
Häufige Fragen.
Nativ oder Cross-Platform — was sollen wir wählen?
Besteht die App überwiegend aus Formularen, Listen und Sync, stimmt meist die Rechnung für Cross-Platform. Hängt sie an Kamera, Standort im Hintergrund, Bluetooth-Hardware oder dauerhafter Performance, spielt nativ die Mehrkosten wieder ein. Wir empfehlen danach, was die App tatsächlich tut, nicht nach Hausgeschmack.
Funktioniert es ohne Internet?
Das wird von Anfang an eingeplant, wo der Anwendungsfall es verlangt. Datensätze werden lokal geschrieben, in eine Warteschlange gelegt und synchronisiert, sobald eine Verbindung zurückkehrt — und diese Warteschlange übersteht das Beenden der App oder einen Neustart des Telefons.
Veröffentlichen Sie für uns in den Stores?
Ja, einschließlich Store-Einträgen, Screenshots und Antworten auf Bewertungen. Die Konten bleiben auf Ihren Namen — wir halten nie das Store-Konto eines Kunden.
Kann es neben unserem bestehenden System laufen?
Ja. Die meisten mobilen Apps, die wir bauen, sind eine feldseitige Oberfläche über einem bereits bestehenden System, kein eigenes Produkt mit eigenen Daten.
Können Sie eine App übernehmen, die jemand anderes gebaut hat?
Meistens ja. Wir beginnen mit einer kurzen Prüfung der Codebasis, des Release-Setups und der Store-Konten und melden uns damit, was nötig wäre. Wenn die ehrliche Antwort lautet, dass eine Neuentwicklung günstiger ist als die Übernahme, sagen wir das und zeigen die Begründung.
Brauchen wir überhaupt eine App, oder täte es eine mobile Website?
Eine responsive Website deckt sehr viel ab und kostet weit weniger. Eine App verdient ihre Kosten, wenn Sie Offline-Fähigkeit, Hardwarezugriff, Hintergrundarbeit oder Push-Benachrichtigungen brauchen. Trifft nichts davon zu, weisen wir Sie auf die günstigere Antwort hin.