Die kurze Antwort: typische Zeiträume nach App-Typ
Bevor wir tiefer eintauchen, hier die Realität für reale Zeitpläne, die aus mehr als 30 ausgelieferten Projekten aggregiert wurden:
| App-Typ | Teamgröße | Zeitplan |
|---|---|---|
| Einfache App (1 Feature-Kern, Standardflows) | 2–3 Engineers | 3–5 Monate |
| Mid-Complexity App (mehrere Features, API-Integrationen) | 3–5 Engineers | 5–8 Monate |
| Komplexe App (Echtzeit, Fintech, HealthTech, Marktplatz) | 5–9 Engineers | 8–12+ Monate |
| MVP (Kernflow validieren, nicht vollständiges Produkt) | 2–3 Engineers | 2–4 Monate |
Diese Zeitpläne zählen die Phase von Projektbeginn bis zu einem funktionierenden, eingereichtem Build im App-Store — sie schließen weder Vorab-Verhandlungen noch Post-Launch-Iteration ein. Sie gelten für Cross-Platform-Apps (React Native oder Flutter) auf iOS + Android. Native iOS + Android jeweils separat fügen in der Regel 30–50 % mehr Zeit hinzu, weil zwei Codebasen gebaut und getestet werden müssen.
Phase 1: Discovery & Anforderungen
Typische Dauer: 2–4 Wochen
Discovery ist die Phase, die Erstprojektteams am häufigsten auslassen oder eilen lassen und die am häufigsten die Ursache nachträglicher Zeitplan-Verlängerungen ist. Eine gute Discovery-Phase liefert:
- Ein priorisiertes Feature-Set: was zu V1 gehört, was danach kommt
- User-Flow-Diagramme, die beschreiben, wie sich Nutzer durch das Produkt bewegen
- Technische Architekturskizze: Backend-Anforderungen, API-Abhängigkeiten, Datenmodelle, Drittanbieter-Integrationen
- Abhängigkeiten, die externe Systeme oder Genehmigungsprozesse beinhalten (Zahlungsprozessoren, Gesundheitsdaten-Compliance, Behörden-APIs)
- Risikoregister: was am wahrscheinlichsten ist, den Zeitplan später zu verlängern
Teams, die Discovery überspringen, bauen typischerweise das Falsche mit Präzision — was zu teuren Redesigns führt, wenn V1 die Nutzer nicht konvertiert, oder zu nachträglichen Architekturänderungen, die den Build-Zeitplan doppeln.
Phase 2: UX/UI-Design
Typische Dauer: 3–6 Wochen
Design umfasst Wireframes (Lo-Fi-Layouts und Flows), High-Fidelity-Mockups (pixel-genaue visuelle Designs) und den interaktiven Prototypen, der die App-Erfahrung vor dem Beginn der Entwicklung simuliert. Für eine einfache App dauert das 3 Wochen. Für eine App mit einem komplexen Multi-Step-Onboarding, einem Echtzeit-Dashboard und einer ungewöhnlichen Navigationsstruktur sind 6 Wochen realistisch.
Der kritische Punkt: Design-Entscheidungen während des Builds zu ändern kostet das Fünf- bis Zehnfache eines Design-Revisions vor dem Build-Start. Jedes Mal, wenn eine abgeschlossene Ansicht neu designed wird, werden bereits geschriebene Komponenten weggeworfen. Dieser Multiplikationseffekt ist der Hauptgrund, warum sorgfältige Design-Reviews vor dem Build-Start kein Luxus, sondern eine Zeitplan-Notwendigkeit sind.
Phase 3: Entwicklung (Frontend + Backend)
Typische Dauer: 6–20 Wochen (der größte variable Faktor)
Die Build-Phase überspannt Mobile-Frontend, Backend-API-Entwicklung, Drittanbieter-Integrationen und einen laufenden Zyklus aus Feature-Entwicklung und internem Review. Für eine einfache App mit sauberem Backend kann das 6–8 Wochen betragen. Für eine komplexe App mit Echtzeit-Features, benutzerdefinierter Authentifizierung, Zahlungsintegrationen und einem signifikanten Datenschicht erstreckt es sich auf 16–20 Wochen.
Der größte Zeitplan-Risikofaktor in dieser Phase ist Backend-Instabilität. Wenn Mobile-Engineers nicht gegen stabile, dokumentierte API-Endpunkte entwickeln können — weil das Backend sich schnell ändert oder hinter dem Mobile-Fortschritt hinterherhinkt — generiert jede API-Änderung Nacharbeit auf der Mobile-Seite. Das ist die häufigste Ursache für Zeitplan-Verschiebungen von „6 Monate“ auf „10 Monate“ in Projekten, die wir übernommen und wiederhergestellt haben.
Phase 4: QA & Testing
Typische Dauer: 2–4 Wochen (parallel zum Build, plus dedizierter Sprint)
QA läuft in reifen Teams kontinuierlich parallel zum Build — nicht als Batch-Phase am Ende. Dennoch gibt es fast immer einen dedizierten QA-Sprint oder zwei vor der Einreichung, in dem die gesamte App end-to-end durchgetestet wird: Geräte-Kompatibilität über mehrere iOS-Versionen und Android-Gerätefragmentierung hinweg, Edge-Case-Flows, Offline-Verhalten, Accessibility, Performance-Regression und Store-Compliance (Guidelines von Apple und Google, die sich regelmäßig ändern).
QA enthüllt routinemäßig Backend-Bugs, die beim Feature-by-Feature-Testing nicht sichtbar waren. Budgetieren Sie 20–30 % der Build-Zeit für QA; Apps, die weniger budgetieren, zahlen diesen Preis in Post-Launch-Vorfällen.
Phase 5: Store-Einreichung & Launch
Typische Dauer: 1–3 Wochen
App-Store-Einreichungen haben gelegentlich Überprüfungszeiten, die den Zeitplan verlängern, insbesondere für neue Developer-Accounts oder Apps mit Zahlungen, Gesundheitsdaten oder nutzergeneriertem Content — diese erfordern zusätzliche Compliance-Dokumentation und dauern länger in der Überprüfung. Für einen etablierten Account und eine sauber konforme App beträgt die Überprüfungszeit von Apple typischerweise 24–72 Stunden. Google Play ist schneller, normalerweise wenige Stunden bis ein Tag.
Fehler, die Verzögerungen verursachen: fehlende Datenschutzmanifeste (iOS 17+), unvollständige App-Privacy-Angaben (Apple), fehlende oder ungenaue Inhalts-Bewertung (Google), hardgecoded IP-Adressen statt Produktions-Endpunkte in den Einreichungs-Builds und Demo-Accounts für Reviewer, die auf eine Staging-Umgebung zeigen, auf die nur das interne Team zugreifen kann.
Phase 6: Laufende Wartung
Laufend: 15–20 % der jährlichen Build-Kosten
Mobile-Apps sind lebendige Produkte. iOS und Android veröffentlichen jährliche Hauptversionen, manchmal mit breaking changes in APIs, Berechtigungsmodellen und UI-Patterns. Der App Store und Google Play ändern ihre Richtlinien jährlich, wobei neue Richtlinien für bestehende Apps manchmal obligatorisch werden. Sicherheits-Patches in Drittanbieter-Abhängigkeiten müssen angewendet werden. Nutzer-Feedback enthüllt UX-Probleme, die im Produktionsbetrieb im Maßstab zum Vorschein kommen.
Lesen Sie unsere vollständige Aufschlüsselung der Mobile-App-Wartungskosten im Jahr 2026 für detaillierte Zahlen nach App-Kategorie und Komplexität.
Was den Zeitplan am meisten beeinflusst
Basierend auf 30+ Projekten sind dies die Faktoren, die Zeitpläne verschieben — geordnet nach Häufigkeit und Auswirkung:
- Spezifikationsklarheit. Der Einzelfaktor mit dem größten Einfluss. Vage Anforderungen, die in der Mitte des Builds präzisiert werden, sind für 40–60 % aller schwerwiegenden Zeitplan-Verschiebungen verantwortlich. Gründliche Discovery und Design-Review vor dem Build-Start lösen das weitgehend.
- Backend-Bereitschaft. Mobile-Engineers, die gegen instabile oder nicht existierende Backend-APIs entwickeln, generieren Nacharbeit bei jeder API-Änderung. Das verdoppelt effektiv die Feature-Build-Zeit. Backend und Mobile sollten nach Möglichkeit parallel geliefert werden, mit stabilem API-Vertrag.
- Entscheidungs-Latenz. Lange Feedback-Schleifen, bei denen Product-Owner-Reviews Tage statt Stunden dauern, komprimieren die verfügbare Build-Zeit still. Ein Team, das alle zwei Wochen zwei Tage auf Genehmigung wartet, verliert einen Monat Effizienz pro Quartal.
- Compliance-Komplexität. HealthTech, Fintech und Apps, die personenbezogene Daten europäischer Nutzer verarbeiten, erfordern Rechts- und Compliance-Überprüfungen, die reale Zeit kosten. Wenn ein Datenschutzanwalt Datenflüsse überprüfen muss, reservieren Sie 2–4 Wochen Puffer. Unsere Mobile-App-Sicherheits- und DSGVO-Compliance-Anleitung behandelt das im Detail.
- Third-Party-Integrationsrisiken. Payment-Gateways, Mapping-SDKs, Analytics-Bibliotheken — diese haben ihre eigenen Onboarding-Prozesse, Dokumentationslücken und gelegentliche Instabilitäten. Jede kritische Third-Party-Integration fügt 1–2 Wochen Risiko-Puffer hinzu.
FAQ
Wie lange dauert die Entwicklung einer einfachen Mobile-App?
Eine einfache App — Benutzerauthentifizierung, ein Kern-Feature-Flow, ein oder zwei Datenintegrationen und Store-Einreichung — dauert typischerweise 3 bis 5 Monate von Discovery bis zum ersten Live-Release. Das setzt voraus, dass die Anforderungen stabil sind, das Design zur Build-Phase hin keine größeren Überarbeitungen erfährt und QA keine großen Backend-Instabilitäten aufdeckt.
Was verlangsamt die App-Entwicklung am stärksten?
Nachträgliche Anforderungsänderungen — nach dem Beginn des Builds oder schlimmer, nach dem QA. Jede größere Änderung nach dem Design-Freeze löst eine Redesign-Schleife aus, die Feature-Entwicklung blockiert und QA-Arbeit ungültig macht. Der zweithäufigste Faktor ist Backend-Instabilität: wenn Mobile-Engineers nicht gegen stabile Endpunkte entwickeln können, macht jede API-Änderung bereits geschriebenen Code ungültig.
Dauert die Entwicklung für iOS und Android separat?
Bei Native: ja, typischerweise addiert man ~60–80 % mehr Zeit für die zweite Plattform. Bei Cross-Platform (React Native, Flutter): nein — beide Plattformen werden aus einer Codebasis geliefert. Der Zeitplan-Unterschied zwischen einer Single-Platform-nativen App und einer Cross-Platform-App, die beide Plattformen liefert, beträgt in der Regel nur wenige Wochen für plattformspezifisches Testing und Store-Einreichung.
Was dauert nach dem Launch noch lange?
Laufende Wartung, OS-Update-Anpassungen und Feature-Iteration. iOS und Android veröffentlichen jährliche Hauptversionen, die breaking changes in APIs, Berechtigungen und UI-Patterns einführen. Die Anpassung an eine neue iOS-Version dauert typischerweise 2–6 Wochen je nach Tiefe der nativen API-Nutzung. Dazu kommen Sicherheits-Patches, Store-Richtlinien-Updates und die ständige Iteration auf Features.
Zuletzt aktualisiert am 12. Juni 2026.
