Eine App zu programmieren heißt nicht, Bildschirme zu bauen. Es heißt, in einer bestimmten Reihenfolge Entscheidungen zu treffen — und die Reihenfolge ist der Teil, den fast alle Anleitungen auslassen. Hier steht sie.
Die Reihenfolge, die funktioniert
- Umfang klären — was macht die App, was ausdrücklich nicht?
- Datenmodell entwerfen — welche Objekte, welche Beziehungen?
- Backend stabilisieren — falls nötig, zuerst und versioniert
- Oberfläche bauen — gegen ein fertiges, nicht gegen ein gedachtes API
- Testen — auf echten Geräten, ab dem ersten Bildschirm
- Einreichen — Store-Prüfung als eigener Arbeitsschritt
Wer bei Schritt 4 beginnt — der verbreitetste Fehler — baut die Oberfläche gegen Annahmen und schreibt sie neu, sobald das Datenmodell steht.
Schritt 1: Umfang — die Nein-Liste ist wichtiger
Schreiben Sie zwei Listen: was die erste Version kann, und was sie ausdrücklich nicht kann. Die zweite Liste ist die nützlichere. Ohne sie wächst der Umfang während der Entwicklung, und zwar immer.
Eine brauchbare erste Version hat einen Zweck, nicht fünf. „Eine App für Fitness-Tracking, Ernährung, Community und Shop" ist keine erste Version, sondern vier Projekte.
Schritt 2: Das Datenmodell
Bevor Sie eine Zeile Oberflächencode schreiben, beantworten Sie: Welche Objekte gibt es, wie hängen sie zusammen, wem gehören sie, wer darf sie ändern?
Das klingt trocken und ist der Hebel mit der größten Wirkung. Ein falsch geschnittenes Datenmodell zwingt Sie später zu Umwegen an jeder Stelle, die darauf zugreift — und das sind alle.
Schritt 3: Backend — und wann Sie keins brauchen
Ohne Backend kommen Sie aus bei: Rechnern, Timern, Offline-Referenzen, Werkzeugen, die nur lokale Daten verarbeiten.
Ein Backend brauchen Sie, sobald: Nutzer sich anmelden, Daten zwischen Geräten synchronisieren, Inhalte ohne App-Update änderbar sein sollen, gezahlt wird oder Nutzer untereinander interagieren.
Für den zweiten Fall gilt die wichtigste Regel dieses Textes: Das API muss stehen und versioniert sein, bevor die App dagegen gebaut wird. Ein sich änderndes API macht die mobile Entwicklung zu einer Dauerbaustelle, weil jede Anpassung eine Kaskade auslöst. Wie so etwas sauber aufgesetzt wird, steht auf unserer Seite zur API-Integration.
Schritt 4: Sprache und Framework
| Ziel | Wahl | Warum |
|---|---|---|
| Nur iOS | Swift + SwiftUI | direkter Zugriff, beste Werkzeuge |
| Nur Android | Kotlin + Compose | dasselbe auf der anderen Seite |
| Beide, ein Team | Flutter (Dart) | eine Codebasis, sehr konsistente Oberfläche |
| Beide, Web-Team vorhanden | React Native (TypeScript) | vorhandenes React-Wissen zählt |
Die ehrliche Version: Für die meisten ersten Apps ist die Wahl zwischen Flutter und React Native weniger wichtig als die Frage, welchen Stack Sie oder Ihr Team in einem Jahr noch warten können. Die ausführliche Abwägung steht auf unserer Seite zur Cross-Platform-Entwicklung, plattformspezifische Details unter iOS.
Schritt 5: Testen — nicht am Ende
Ein Simulator ist kein Gerät. Ihr Mindesttest umfasst:
- ein älteres Android-Gerät mit wenig Arbeitsspeicher
- ein iPhone zwei OS-Versionen zurück
- schlechtes Netz und Netzwechsel mitten in einer Aktion
- niedriger Akkustand, Energiesparmodus
- Systemschrift auf größter Stufe
Der letzte Punkt findet mehr Layout-Fehler als jeder andere Einzeltest.
Ergänzen Sie Absturzberichte und einfache Nutzungsanalyse ab der ersten Testversion. Die ersten zwanzig echten Nutzer liefern mehr verwertbare Fehler als zwei Wochen eigenes Klicken.
Schritt 6: Die Store-Freigabe
Kein Formular, sondern eine Prüfung. Die vier Punkte, an denen Einreichungen am häufigsten scheitern:
- Privacy Manifest (Apple) — muss zu dem passen, was App und SDKs tatsächlich erfassen
- Data Safety Form (Google) — dasselbe, eigenes Formular
- App Tracking Transparency — Dialog erforderlich, sobald Werbe-IDs im Spiel sind
- Kontolöschung in der App — Pflicht, wenn Registrierung in der App möglich ist
Jede Ablehnungsrunde kostet Tage. Diese vier Punkte lassen sich vorher prüfen.
Die Werkzeuge, die Sie von Anfang an brauchen
Nicht später einführen — von Tag eins, sonst holen Sie es unter Zeitdruck nach:
- Versionsverwaltung mit echten Branches, auch als Einzelperson. Der Nutzen ist nicht Zusammenarbeit, sondern die Möglichkeit, einen Stand zurückzunehmen.
- Ein automatisierter Build, der aus einem Commit eine installierbare Testversion macht. Ohne das wird jede Testrunde zur Handarbeit und entsprechend selten durchgeführt.
- Absturzberichte ab der ersten Testversion. Ein Absturz, den ein Tester nicht meldet, existiert sonst nicht.
- Ein Fehler- und Aufgabenverzeichnis, auch wenn es eine einfache Liste ist. Was nicht notiert ist, wird nicht behoben.
- Ein zweites echtes Testgerät — idealerweise die schwächere Plattform, auf der Sie selbst nicht unterwegs sind.
Diese fünf Punkte kosten am Anfang etwa einen Tag Einrichtung und sparen über ein Projekt hinweg Wochen.
Kann man das selbst?
Ehrliche Einschätzung, wenn Sie bereits programmieren können:
- Ein-Zweck-App ohne Backend: ja, 150–300 Stunden bis zur Einreichung
- App mit Konten und einer Integration: möglich, aber 500+ Stunden, und der Backend-Teil ist der schwierige
- App mit Zahlungen, Rollen und Synchronisation: hier endet der Alleingang in der Regel — nicht wegen der Oberfläche, sondern wegen Datensicherheit, Konfliktauflösung und Abo-Logik
Wenn Sie noch gar nicht programmieren: Rechnen Sie zusätzlich mit sechs bis zwölf Monaten Lernzeit. Für eine Geschäftsidee mit Zeitdruck ist das selten der richtige Weg — dann ist die Frage eher, was ein Team kostet. Die Zahlen dazu stehen in Was kostet App-Entwicklung 2026?.
Was Sie dabei aufgeben
Selbst zu bauen kostet nicht nur Zeit, sondern Optionen: Sie lernen an Ihrem eigenen Produkt, das heißt die ersten Entscheidungen sind die schlechtesten und stehen am tiefsten in der Architektur. Das ist ein akzeptabler Preis für ein Lernprojekt und ein hoher für ein Produkt mit Markteintrittsdatum.
Wie wir vorgehen
Wir setzen dieselbe Reihenfolge um, mit einer einwöchigen Klärungsphase am Anfang: Umfang, Datenmodell, technische Risiken, Backlog mit Abnahmekriterien. Erst danach wird gebaut. Das Vorgehen im Detail steht auf unserer Seite zur Mobile-App-Entwicklung; Teams in Berlin finden lokale Details unter Standort Berlin.
Wenn Sie unsicher sind, ob Ihre Idee ein Backend braucht: Beschreiben Sie sie kurz — Sie bekommen innerhalb von 48 Stunden eine Einschätzung, auch wenn die Antwort „das können Sie selbst bauen" lautet.