Mobile-App-Entwicklung: Zeitplan, Kosten & Launch-Playbook

Ein Food-Delivery-Startup aus Kairo kam einmal neun Monate nach Projektstart zu uns. Die Agentur hatte eine optisch ansprechende iOS-App gebaut. Android war ein Nachgedanke, das Zahlungs-Gateway nicht integriert, und die App-Store-Einreichung war zweimal abgelehnt worden. Rund EGP 850.000 waren ausgegeben – und kein einziger Live-User. Die Probleme begannen nicht in der Entwicklung, sondern im Briefing.

Dieser Leitfaden richtet sich an Unternehmer, die genau dieses Szenario vermeiden wollen. Wir behandeln Tech-Stack-Entscheidungen, realistische Kostenbereiche für Ägypten und den Golf, Einreichungs-Playbooks und die stillen Fehler nach dem Launch, die Apps langsam zum Scheitern bringen.

Native, Flutter oder Web-Wrapper: Die Entscheidung, die alles prägt

Diese Wahl beeinflusst Zeitplan, Budget und das Nutzererlebnis bei jedem Tippen. Hier die ehrliche Einschätzung:

Native iOS + Android (Swift / Kotlin)

Zwei separate Codebasen. Beste Performance, bester Zugriff auf Hardware (Kamera, Biometrie, Bluetooth). Die richtige Wahl, wenn der Kernwert der App in der Hardware-Interaktion liegt – etwa Fitness-Tracker, AR-Funktionen oder alles, bei dem eine Verzögerung von 50ms spürbar stört. Langfristig bedeutet das: zwei Codebasen, zwei Teams.

Flutter

Eine Codebasis, zwei Stores. Googles Flutter-Framework ist inzwischen ausgereift genug, dass die meisten Business-Apps – Marktplätze, Buchungstools, Field-Service-Apps, interne Dashboards – darauf laufen, ohne dass Nutzer einen Unterschied bemerken. Die Entwicklungszeit sinkt deutlich. Ein Projekt, das nativ 6 Monate dauert, ist in Flutter oft in 3,5 Monaten fertig. Für die meisten ägyptischen und Golf-KMUs sowie mittelständische Unternehmen ist Flutter die richtige Entscheidung.

Web-Wrapper (React Native / Capacitor)

Schnell zu bauen, aber Apples App-Store-Reviewer sind gegenüber dünnen Web-Wrappern zunehmend kritisch. Ist die App im Wesentlichen eine Website mit App-Icon, sind Ablehnungen vorprogrammiert. Dieser Ansatz eignet sich nur als Übergangslösung – eine temporäre Veröffentlichung, während die eigentliche App entsteht.

Realistische Zeitpläne (nicht die optimistischen Angaben von Agenturen)

Agenturen kalkulieren Zeitpläne unter der Annahme, dass alles reibungslos läuft. Was tatsächlich passiert:

• Discovery & Wireframes: 2–3 Wochen (wird dieser Schritt übersprungen, folgen später 6 Wochen Nacharbeit)
• UI-Design: 3–4 Wochen für ein solides, getestetes Design-System
• Flutter-Entwicklung, MVP-Scope: 10–14 Wochen
• Backend & API-Integration: läuft oft parallel; bei Neuentwicklung kommen 2–4 Wochen hinzu
• QA + Gerätetests: 2–3 Wochen – MENA-Nutzer verwenden überraschend viele verschiedene Geräte: Samsung-Mittelklasse, iPhone 11–13 und ältere Huawei-Geräte ohne Google Play Services
• App Store / Play Store Einreichung: 1–2 Wochen (dazu mehr weiter unten)

Realistischer Gesamtaufwand für ein solides MVP: 5–6 Monate. Wer 8 Wochen für eine voll ausgestattete App anbietet, bereitet eine schmerzhafte Übergabe vor.

Kostenbereiche: Ägypten vs. Golf

Kosten variieren je nach Umfang – hier realistische Richtwerte für Mitte 2025:

• Ägyptische Agentur, MVP Flutter-App: USD 15.000–35.000
• Ägyptische Agentur, vollständige App mit Backend: USD 35.000–80.000
• Golf-Agentur (VAE, Saudi-Arabien): in der Regel 2–3× der ägyptischen Preise bei gleichem Umfang
• Freelancer (Ägypten): USD 8.000–18.000 – geringere Kosten, höheres Koordinationsrisiko

Viele Gulf-Unternehmen beauftragen heute gezielt Kairoer Agenturen, weil diese Lücke so groß ist. Das technische Niveau ist vergleichbar; der Overhead nicht. Wer Gulf-Markt-Compliance benötigt (VAE-Datenresidenz, VAT-Integration, Arabisch RTL), sollte sicherstellen, dass die ägyptische Agentur bereits für diese Märkte geliefert hat – nicht nur theoretisches Wissen darüber besitzt.

Eine detaillierte Aufschlüsselung, wie der Projekttyp die Zahlen beeinflusst, bietet der Leitfaden unter /de/insights/mobile-app-cost-timeline-flutter-egypt-gulf mit einer tiefergehenden Scope-zu-Kosten-Zuordnung.

App Store & Play Store Einreichung: Das Playbook

Ersteinreichungen werden häufiger abgelehnt als nicht. Darauf vorbereiten – nicht davon überrascht sein.

Apple App Store

• Mindestens 2 Wochen vor der Einreichung im Apple Developer Program anmelden – die Bankverifizierung für ägyptische Unternehmen dauert ihre Zeit
• Einen funktionierenden Demo-Account für Reviewer bereithalten – Apple loggt sich ein und testet
• Die Datenschutzerklärung muss unter einer echten URL erreichbar sein, kein Google Doc
• Bei Zahlungen innerhalb der App behält Apple 15–30% der In-App-Käufe ein – das Preismodell vor der Einreichung planen, nicht erst nach der Ablehnung
• Häufige Ablehnungsgründe: fehlerhafte Registrierungsabläufe, fehlende App-Funktionalität, irreführende Screenshots

Google Play Store

• Prüfzeiten sind kürzer (1–3 Tage gegenüber Apples 1–7 Tagen), aber der Play Store führt inzwischen automatisierte Richtlinien-Scans durch, die Apps noch Wochen nach dem Launch markieren können
• Das Ziel-API-Level muss aktuell sein – Google setzt das durch, und es erfordert Backend-Kompatibilitätsprüfungen
• Das Data-Safety-Formular ist Pflicht und muss genau widerspiegeln, was die App erfasst

Wann Zahlungen, Push-Benachrichtigungen und Offline-Modus hinzugefügt werden sollten

Diese drei Features werden häufig im Umfang unterschätzt. Wann sie den Aufwand wert sind:

In-App-Zahlungen

Von Anfang an einbauen, wenn Zahlungen zum Kerngeschäftsmodell gehören. Einen Zahlungsablauf nachträglich in eine bestehende Architektur zu integrieren, ist aufwendig. In Ägypten dominieren Paymob und Fawry. Für Gulf-Märkte decken Tap Payments und Moyasar die meisten Fälle ab. Pro Zahlungsanbieter sollten 3–4 zusätzliche Entwicklungs- und Compliance-Wochen eingeplant werden.

Push-Benachrichtigungen

Früh einzubauen ist günstig – nachträglich teuer. Sie berühren Backend-Architektur, User-Modell und Analytics. Bereits im initialen Build integrieren, auch wenn Kampagnen nicht sofort gestartet werden. Firebase Cloud Messaging funktioniert für beide Plattformen und ist für die meisten Anwendungsfälle zuverlässig genug.

Offline-Modus

Nur bauen, wenn Nutzer tatsächlich in Umgebungen mit schlechter Verbindung arbeiten – Außendiensttechniker, Lieferfahrer, Klinikpersonal in ländlichen Gebieten. Für eine Consumer-App in Kairo oder Dubai bedeutet der Offline-Modus 4–6 Wochen Mehraufwand für eine Funktion, die die meisten Nutzer nie auslösen werden. Ehrlich beurteilen, ob Nutzer ihn wirklich brauchen.

Wie man eine Entwicklungsagentur auswählt (und was man fragen sollte)

Drei Fragen schaffen schneller Klarheit als jede Ausschreibung:

1. Können Sie mir eine App zeigen, die Sie in den letzten 12 Monaten in beiden Stores veröffentlicht haben? Kein Mockup. Eine Live-App mit Store-Eintrag.
2. Wem gehören Code und Zugangsdaten am Ende? Apple-Developer-Account, Play Console und Source-Code-Repository sollten dem Kunden gehören. Manche Agenturen behalten diese als Druckmittel.
3. Wie sieht Ihr QA-Prozess auf echten Geräten aus? Nur Emulator-Tests sind ein Warnsignal.

Agenturen, die branchenübergreifend geliefert haben, erkennen Probleme früher. Das Team von ProgMine hat Apps in den Bereichen Logistik, Gesundheitswesen und Einzelhandel entwickelt – sektorübergreifende Erfahrung deckt Grenzfälle auf, die ein spezialisiertes Team leicht übersieht.

Es lohnt sich auch zu prüfen, wie die Agentur mit angrenzenden Aufgaben umgeht. Wenn die App später ein Web-Portal oder internes Tooling benötigt, spart eine Agentur, die Web-Design und UX neben der Mobile-Entwicklung abdeckt, erheblichen Koordinationsaufwand.

Fehler nach dem Launch, die Apps still zum Scheitern bringen

Der Launch-Tag ist der Anfang, nicht die Ziellinie. Diese Muster bringen Apps in den Monaten nach dem Go-live zu Fall:

• Kein Crash-Monitoring von Anfang an. Firebase Crashlytics ist kostenlos. Es gibt keine Entschuldigung dafür, es nicht aktiv zu haben, bevor der erste User sich anmeldet.
• Einster-Bewertungen ignorieren. Auf negative Reviews zu reagieren – selbst nur um das Problem anzuerkennen – verbessert nachweislich die Conversion im Store-Eintrag.
• OS-Update-Tests überspringen. Jede größere iOS- und Android-Version bricht irgendetwas. Eine Testwoche sollte jedes Jahr im September (iOS) und bei jedem großen Android-Release eingeplant werden.
• Keine Analytics zu tatsächlichen Nutzerflüssen. Wer nicht weiß, wo Nutzer abspringen, trifft jede Produktentscheidung auf Basis von Vermutungen.
• Den MVP-Scope als Endprodukt behandeln. Ein MVP dient dazu, Annahmen zu validieren. Einen zweiten Release-Zyklus planen, bevor der erste gelauncht wird.

Ein Hinweis zu Arabisch RTL und Lokalisierung

Wer ägyptische oder Gulf-Nutzer anspricht, die Arabisch bevorzugen: RTL-Layout (Rechts-nach-links) ist kein Abhak-Punkt – es betrifft jeden Screen, jede Komponente und jede Animationsrichtung. Flutter handhabt RTL grundsätzlich gut, aber es muss von Anfang an designed und getestet werden. Eine nachträgliche Arabisch-Lokalisierung einer LTR-only-App kostet typischerweise 4–6 Wochen Bereinigungsarbeit. Von Beginn an einplanen.

Bereit für ein Gespräch?

Wer sich in der Planungsphase befindet – ob erste App oder Neuaufbau einer bestehenden – wird feststellen, dass die Entscheidungen der nächsten Wochen die nächsten zwei Jahre des Produkts prägen. Wir schauen uns gerne das Briefing an, stellen frühzeitig die unbequemen Fragen und sagen ehrlich, was in dem gegebenen Zeit- und Budgetrahmen machbar ist. Melden Sie sich über progmine.com und wir besprechen alles im Detail.