Mobile-App-Checkliste für Startups: 34 Punkte vom MVP bis zur App-Store-Freigabe (2026)

Mobile-App-Checkliste für Startups: 34 Punkte vom MVP bis zur App-Store-Freigabe (2026)

Apples App Store Review Guideline 5.1.1(v) hat mehr Launch-Termine von Startups zerstört als jeder Bug, den wir je ausgeliefert haben. Ein fehlender Button zum Löschen des Kontos, am Abend vor dem Demo Day eingereicht, und der gesamte Zeitplan rutscht um eine Woche. Diese Mobile-App-Checkliste für Startups existiert, weil dieser Fehler vollständig vermeidbar ist und sich fast niemand die Nummer der Richtlinie notiert, die ihn auslöst.

Die wichtigsten Punkte:

• Apple lehnt Apps wegen fehlender Kontolöschung und fehlender Datenschutz-Links ab: Die Richtlinien 5.1.1 und 1.5 benennen das explizit.
• Google Play verlangt sowohl einen In-App- als auch einen öffentlichen Web-Pfad zur Kontolöschung; die Durchsetzung folgt auf die Verlängerungsfrist vom 31. Mai 2024.
• Die Einreichungs-Checklisten für iOS und Android unterscheiden sich; sie als eine gemeinsame Liste zu behandeln, ist die häufigste Ursache für Last-Minute-Launch-Verzögerungen.

Bevor Sie Code schreiben

Bevor auch nur ein einziger Screen entworfen wird, müssen drei Dinge feststehen: was Ihr MVP tatsächlich ist, ob Sie eine Datenschutzerklärung brauchen (ja, brauchen Sie) und ob die DSGVO oder das türkische KVKK für Ihre Nutzer gilt. Diese Phase zu überspringen ist der Grund, warum Gründer am Ende in der Woche Rechtstexte hastig zusammenklopfen, in der sie eigentlich einreichen wollten.

Ein MVP ist, in einem Satz, die kleinste Version Ihres Produkts, die Ihre Kernannahme mit echten Nutzern testet. Keine abgespeckte Version Ihrer großen Vision. Wenn der Umfang noch unscharf ist, spart Ihnen die saubere Definition des Projektumfangs, bevor Sie eine Zeile Code schreiben, das Streichen von Features mitten im Build statt vorher.

Apples eigene Richtlinien sind bei der Pflicht zur Datenschutzerklärung unmissverständlich: Richtlinie 5.1.1(i) verlangt, dass Apps „einen Link zu ihrer Datenschutzerklärung enthalten" müssen, und zwar in den App-Store-Connect-Metadaten und in vielen Fällen auch in der App selbst. Das ist keine Empfehlung. Fehlt der Link, ist die Einreichung blockiert.

• MVP-Umfang in einem Satz definieren
• Bestätigen, dass Sie eine Datenschutzerklärung brauchen (fast immer ja)
• Support-URL entwerfen (Apple-Richtlinie 1.5 verlangt sie)
• DSGVO-/KVKK-Anwendbarkeit prüfen, falls Sie EU- oder türkische Nutzer haben
• Nativ oder Cross-Platform: Stack festlegen

Die MVP-Build-Woche

In der MVP-Build-Woche entscheiden Sie, was tatsächlich ausgeliefert wird und was gestrichen wird, und die ehrliche Antwort lautet: mehr, als Gründer erwarten. Analytics und Crash-Reporting kommen während des Builds hinein, nicht danach. Beides nach dem Launch nachzurüsten heißt, dass Ihnen genau die Daten fehlen, mit denen Sie Ihre erste Annahme validieren wollten.

Was wir bei einem v1-Umfang in den meisten Fällen tatsächlich streichen, ist alles, was nicht die eine zu testende Sache ist. Push-Benachrichtigungen, Social Login, ein Einstellungsbildschirm mit sechs Schaltern, all das kann warten. Gründer wehren sich verständlicherweise dagegen; es fühlt sich an, als liefere man etwas Unfertiges aus. Es ist unfertig. Genau das ist der Punkt.

Wie es ein Gründer, der bereits mehrere Apps veröffentlicht hat, in einem Checkliste-Beitrag auf dev.to formulierte: Einen Feedback-Mechanismus früh auszulassen ist ein Fehler, den er „jedes Mal bereut" hat. Bauen Sie ihn jetzt ein, nicht erst, wenn die erste Rezension eintrifft. Wenn Sie die Scoping-Diskussion selbst beschleunigen möchten, lohnt vor Build-Beginn ein Blick auf Scoping mit KI beschleunigen.

• Analytics vor dem ersten TestFlight-/internen Build instrumentieren
• Crash-Reporting anbinden (Sentry oder Firebase Crashlytics)
• Feedback-Mechanismus in die App einbauen
• Jedes Feature streichen, das nicht Kern der einen getesteten Sache ist
• Ersten Versionsstring festlegen (siehe Versionierung unten)

Die Woche vor der Einreichung

Das ist die Phase, die jede Wettbewerber-Checkliste komplett auslässt, und genau hier passieren die meisten vermeidbaren Verzögerungen. Semantische Versionierung folgt bei Apps dem Muster MAJOR.MINOR.BUILD (1.0.0, dann 1.0.1 für einen Patch, 1.1.0 für ein Feature-Update). Legen Sie jetzt ein Schema fest, denn inkonsistente Versionsnummern verwirren sowohl die App Stores als auch Ihr eigenes Team.

Ein gestaffelter Rollout veröffentlicht Ihr Update zuerst an einen kleinen Prozentsatz der Nutzer (oft 1 %, dann 10 %, dann 50 %), bevor alle beliefert werden. Nur eine der drei Wettbewerber-Checklisten, die wir geprüft haben, erwähnt ihn, und auch das nur am Rande. Wenn ein Crash durchrutscht, begrenzt ein gestaffelter Rollout den Schaden, statt 100 % der Nutzer gleichzeitig zu treffen.

Die Fragen, die wir stellen, bevor wir eine Kunden-Einreichung freigeben, sind simpel: Funktioniert der kritische Pfad gerade jetzt, Ende zu Ende, auf einem echten Gerät? Nicht im Simulator. Ist die Crash-frei-Rate akzeptabel? Sind die Store-Listing-Assets wirklich final und keine Platzhalter?

• Bestätigen, dass die Versionsnummer einem konsistenten Schema folgt
• Kritischen Pfad ein letztes Mal Ende zu Ende testen
• Prozentsatz für den gestaffelten Rollout vorbereiten, falls der Store ihn unterstützt
• Crash-frei-Rate vor der Einreichung auf Akzeptanz prüfen
• Alle Store-Listing-Assets als Screenshots vorbereiten

Einreichungstag: iOS vs. Android

iOS- und Android-Einreichungen scheitern aus unterschiedlichen Gründen, und sie als eine gemeinsame Checkliste zu behandeln, ist die größte Einzelursache für Last-Minute-Launch-Verzögerungen, die wir sehen. Apples App Store Review Guidelines und Google Plays Entwickler-Richtlinien nennen jeweils spezifische, prüfbare Anforderungen, und die meisten Gründer erfahren davon erst nach einer Ablehnungs-E-Mail.

Bei unseren eigenen App-Einreichungen sind die zwei Dinge, über die Erst-Gründer am häufigsten stolpern, die Pflicht zur Kontolöschung und eine nicht erreichbare Support-URL. Beides sind Ein-Zeilen-Fixes, wenn man sie vor der Einreichung erwischt. Beides führt zu einer automatischen Ablehnung, wenn man es nicht tut.

Apples App Store Review Guidelines sind konkret: Richtlinie 5.1.1(v) verlangt, dass Apps, die Kontoerstellung unterstützen, auch eine In-App-Kontolöschung anbieten, Richtlinie 1.6 regelt die Data-Security-Angaben, und Richtlinie 1.5 verlangt eine funktionierende Support-URL. Auf Android-Seite verlangt die Entwickler-Richtlinie von Google Play sowohl einen In-App-Löschpfad ALS AUCH eine öffentliche Web-URL für Kontolöschungs-Anfragen. Google kündigte die Anforderung im April 2023 an, setzte den Stichtag 7. Dezember 2023 für die Datenlöschungs-Fragen des Datensicherheits-Formulars und gewährte Verlängerungen bis zum 31. Mai 2024, nach denen nicht konforme Apps mit Durchsetzungsmaßnahmen rechnen müssen. Das ist keine Altregel, die für kleine Apps stillschweigend auslief; sie gilt weiterhin.

Die beiden Einreichungsabläufe unterscheiden sich auch mechanisch, nicht nur auf dem Papier. Bei iOS laden Sie einen Build über Xcode oder Transporter hoch, App Store Connect verarbeitet ihn (das dauert von wenigen Minuten bis über eine Stunde), und von dort leiten Sie ihn entweder an TestFlight für interne und externe Tester weiter oder reichen ihn direkt beim App Review ein. TestFlight ist keine optionale Fleißarbeit: So erwartet Apple, dass Sie die Bugs abfangen, wegen derer ein Prüfer Sie sonst ablehnen würde. Bei Android arbeitet die Google Play Console in Tracks statt mit einer einzelnen Einreichung und durchläuft internes Testen, dann geschlossenes oder offenes Testen, dann Produktion, jeder mit eigenem Publikum und eigenem Beförderungsschritt. Ein gestaffelter Rollout erscheint erst, wenn Sie eine bestehende Produktionsversion aktualisieren. Wie Googles eigene Release-Dokumentation es ausdrückt: „Wenn Sie Ihre erste Version veröffentlichen, sehen Sie die Option zur Auswahl eines Rollout-Prozentsatzes nicht." Planen Sie also Ihren allerersten Launch nicht um eine prozentuale Rampe herum, die kommt später.

Nicht Code, sondern Papierkram blockiert tatsächlich die meisten Erst-Einreichungen. Apple verlangt ein Privacy Manifest für eine definierte Liste häufig genutzter Drittanbieter-SDKs (Werbenetzwerke, Analytics, Crash-Reporter), und die eigene Aussage dazu ist unmissverständlich, wer in der Pflicht steht: „Wenn Sie ein Drittanbieter-SDK mit Ihrer App verwenden, sind Sie für den gesamten Code verantwortlich, den das SDK in Ihre App einbringt, und müssen dessen Datenerfassungs- und Nutzungspraktiken kennen", so Apples Seite zu Drittanbieter-SDK-Anforderungen. Übersehen Sie das Manifest für ein gelistetes SDK, passiert Ihr Build App Store Connect nicht. Googles Pendant als Papierkram-Hürde ist das Datensicherheits-Formular, und es ist für jede App auf jedem Track Pflicht, außer Builds, die nur im internen Test laufen: „Alle Entwickler, die eine App auf Google Play veröffentlicht haben, müssen das Datensicherheits-Formular ausfüllen, einschließlich Apps auf geschlossenen, offenen oder Produktions-Test-Tracks", so die Datensicherheits-Dokumentation von Google Play. Machen Sie es falsch, sagt Google offen, dass es „angemessene Maßnahmen ergreifen kann, einschließlich Durchsetzungsmaßnahmen", sobald eine Diskrepanz zwischen deklariertem und tatsächlichem App-Verhalten auftaucht.

Es gibt einen dritten Fehlermodus, der nichts mit Richtlinientext zu tun hat: Der Prüfer kann Ihre App buchstäblich nicht testen. Apples Richtlinie 2.1 sagt das direkt: „Geben Sie Demo-Kontoinformationen an (und schalten Sie Ihren Backend-Dienst ein!), wenn Ihre App einen Login enthält." Keine funktionierenden Demo-Zugangsdaten, kein laufendes Backend während des Prüfzeitraums, keine erreichbare Support-URL, und Sie werden zurückgewiesen, egal wie konform Ihre Kontolöschung ist. Liegt irgendein Teil Ihrer App hinter einer Paywall oder einem Login, schreiben Sie Prüfer-Hinweise, die genau erklären, wie man dorthin gelangt. Ein Zwei-Minuten-Schritt, den Erst-Gründer ständig überspringen.

Eine weitere, Android-exklusive Hürde gehört in dasselbe Gespräch: die Ziel-API-Ebene. Die eigene Entwicklerdokumentation von Android sagt, dass „neue Apps und App-Updates" die aktuell erforderliche Android-API-Ebene „anvisieren müssen, um bei Google Play eingereicht zu werden", und dass „veraltete Apps für neue Nutzer von Geräten mit neueren Android-Versionen nicht verfügbar sind". Das hat nichts mit Kontolöschung oder Datensicherheit zu tun, blockiert eine Einreichung aber genauso glatt, und es ist die Art von Anforderung, die sich jedes Jahr verschiebt. Prüfen Sie also die aktuelle Nummer, bevor Sie Ihr Release bauen.

Keine der top-platzierten Checklisten für genau diese Suche zitiert auch nur eine einzige App-Store-Richtliniennummer. Wir tun es, weil Raten bei Compliance der Weg ist, auf dem Launches um jeweils eine Woche rutschen. Wenn Sie Ihre breitere Datenhaltungs-Strategie ausbauen, deckt Ihre Datenhaltungs-Checkliste vor dem Launch die Sicherheitsseite ab, die wir hier nicht duplizieren.

iOS-Einreichungs-Checkliste:

• Datenschutz-URL live und erreichbar
• In-App-Pfad zur Kontolöschung ausgeliefert (Richtlinie 5.1.1(v))
• Support-URL live (Richtlinie 1.5)
• Data-Security-Angaben vollständig ausgefüllt (Richtlinie 1.6)
• TestFlight-Build vor der öffentlichen Einreichung freigegeben

Android-Einreichungs-Checkliste:

• Datensicherheits-Formular in der Play Console ausgefüllt
• In-App-Pfad zur Kontolöschung ausgeliefert
• Öffentliche Web-URL für Kontolöschungs-Anfragen live (Google-Play-Anforderung)
• Prozentsatz für gestaffelten Rollout gesetzt
• Ziel-API-Ebene erfüllt die aktuelle Play-Anforderung

Launch-Tag

Der Launch-Tag ist der Tag, an dem Ihre App tatsächlich für echte Nutzer live geht, getrennt von der Einreichung, die Tage oder Wochen vorher passieren kann, und getrennt von Woche eins, die das Nachspiel ist. Überwachung des gestaffelten Rollouts an Tag eins sagt Ihnen, ob Sie weiter ausrollen oder auf Pause drücken.

Beobachten Sie Ihr App-Store-Connect- oder Play-Console-Dashboard in den ersten 24 Stunden stündlich, nicht täglich. Wenn Ihre Crash-frei-Rate fällt, wollen Sie es innerhalb der Stunde wissen, nicht am nächsten Morgen, wenn hundert weitere Nutzer denselben Bug getroffen haben. Halten Sie einen Rollback-Build bereit. Dieselbe Härten-Stabilisieren-Ausliefern-Disziplin, die wir für KI-Features anwenden, gilt hier genauso direkt.

• Crash-frei-Rate in den ersten 24 Stunden stündlich überwachen
• Support-Kanal besetzt und bereit halten
• Bestätigen, dass der gestaffelte Rollout wie geplant expandiert
• Rollback-Build für den Fall eines kritischen Bugs bereithalten

Ihre erste Woche live

In der ersten Woche live passiert der Großteil der eigentlichen Arbeit, auch wenn fast niemand dafür plant. Tägliche Crash-Report-Prüfung und auf die ersten Store-Rezensionen antworten sind wichtiger als alles, was Sie am Launch-Tag selbst getan haben.

„Der Launch selbst ist weniger wichtig, als man denkt. Was zählt, ist, was man in den Wochen danach tut", schrieb ein Gründer in seiner eigenen Post-Launch-Checkliste. Das ist die ehrliche Version von Woche eins: schnell patchen, persönlich antworten und tatsächlich prüfen, dass Ihr Datenlöschungs-Ablauf funktioniert, bevor ein echter Nutzer ihn für Sie testet. Wenn Sie sich nun fragen, was das alles an Aufbau und Unterhalt kostet: Budgetplanung für Wartung und Updates nach dem Launch ist das Begleitstück. Dieser Beitrag deckt die Bereitschaft ab; jener deckt die Rechnung ab.

• Crash-Reports in der ersten Woche täglich prüfen
• Auf die ersten 10 Store-Rezensionen persönlich antworten
• Kritischen Bug innerhalb von 48 Stunden triagieren und patchen
• Bestätigen, dass Ihr Datenlöschungs-Anfragen-Prozess Ende zu Ende funktioniert
• Rhythmus festlegen, um Analytics gegen Ihre ursprüngliche MVP-Hypothese zu prüfen

Wie Techsy das angeht

Wir behandeln die Vor-Einreichungs-Prüfung bei jedem Kunden-Build gleich: Bevor wir eine Einreichung freigeben, fragen wir, ob der kritische Pfad auf einem echten Gerät funktioniert, ob die Crash-frei-Rate hält und ob jeder von den Richtlinien verlangte Ablauf (Kontolöschung, Datenschutzerklärung, Support-URL) tatsächlich funktioniert, nicht nur in einem Mockup existiert. Es ist eine kurze Liste, aber es ist die Liste, die bestimmt, ob eine App die Prüfung beim ersten Versuch besteht.

Wenn Sie lieber jemanden Ihre Einreichung abwickeln lassen, der diese Richtlinien schon durchlaufen hat: Unser Mobil-App-Entwicklungsprozess ist genau um diesen Vor-Einreichungs-Prüfschritt herum gebaut. Er ersetzt nicht Ihre eigenen Hausaufgaben, er ist das, was wir tun, nachdem Sie sie gemacht haben.

Häufig gestellte Fragen

Was ist ein MVP und warum ist er für eine Launch-Checkliste wichtig?

Ein MVP ist die kleinste Version Ihres Produkts, die eine Kernannahme mit echten Nutzern testet. Hier ist er wichtig, weil jeder Punkt dieser Checkliste mit dem Umfang skaliert: ein engerer MVP heißt weniger Dinge, die bei der Einreichung schiefgehen können, und weniger Features, die in Woche eins instrumentiert, überwacht und gepatcht werden müssen.

Warum werden Apps vom App Store abgelehnt?

Die häufigsten vermeidbaren Gründe sind fehlende Datenschutz-Links (Richtlinie 5.1.1(i)), keine In-App-Kontolöschung (Richtlinie 5.1.1(v)) und eine nicht erreichbare Support-URL (Richtlinie 1.5). Nichts davon erfordert Engineering-Aufwand zur Behebung; es sind Checklisten-Punkte, keine Bugs.

Was passiert, wenn ich meiner App keine Kontolöschung gebe?

Bei iOS macht Richtlinie 5.1.1(v) daraus einen automatischen Ablehnungsgrund, wenn Ihre App Kontoerstellung unterstützt. Bei Android verlangt Google Play sowohl einen In-App- als auch einen öffentlichen Web-Löschpfad, und nicht konforme Apps müssen nach der Verlängerungsfrist vom 31. Mai 2024 mit Durchsetzung rechnen; das Weglassen blockiert die Einreichung auf beiden Plattformen.

Brauchen Startups eine Datenschutzerklärung für eine Mobil-App?

Ja, fast immer. Apple verlangt eine verlinkte Datenschutzerklärung nach Richtlinie 5.1.1(i), und Google Play verlangt eine im Datensicherheits-Formular. Wenn Sie irgendwelche Nutzerdaten erheben, sei es nur eine E-Mail für die Registrierung, brauchen Sie sie vor der Einreichung.

Was ist der Unterschied zwischen einer Einreichung beim App Store und bei Google Play?

Apples Prüfung ist richtliniengetrieben mit benannten Klauseln (5.1.1, 1.5, 1.6) und einem menschlichen Prüfer; Google Play stützt sich auf das Datensicherheits-Formular und automatische Prüfungen. Die Pflicht zur Kontolöschung ist im Geist ähnlich, unterscheidet sich aber in der Mechanik; siehe die Vergleichstabelle oben.

Wie lange dauert die App-Store-Prüfung wirklich?

Keiner der Stores veröffentlicht eine garantierte Bearbeitungszeit, also behandeln Sie jede Zahl, die Sie lesen, als grobe Erwartung, nicht als Versprechen. Bei unseren eigenen Kunden-Einreichungen landeten Apple-Freigaben meist innerhalb von ein bis zwei Tagen, wobei alles rund um Kontolöschung oder Datenoffenlegung länger dauerte. Google Play war meist schneller. Planen Sie Ihren Launch-Termin so oder so mit Puffer.

Was ist ein gestaffelter Rollout und sollte ich einen nutzen?

Ein gestaffelter Rollout veröffentlicht ein Update zuerst an einen kleinen Prozentsatz der Nutzer und erweitert dann schrittweise, statt auf einmal an 100 % zu gehen. Verwenden Sie einen, wann immer der Store ihn unterstützt; er begrenzt, wie viele Nutzer einen Bug treffen, bevor Sie pausieren und beheben können.

Brauche ich eine Support-URL, um meine App einzureichen?

Ja. Apples Richtlinie 1.5 verlangt eine funktionierende Support-URL als Teil der Einreichung, und Google Play erwartet ebenfalls einen Support-Kontakt. Ein toter Link oder ein nicht überwachtes Postfach ist hier ein einfacher, vermeidbarer Ablehnungsgrund.

Was sollte ich in der ersten Live-Woche meiner App überwachen?

Crash-Reports täglich, Ihre ersten zehn Store-Rezensionen und ob Ihr Datenlöschungs-Anfragen-Prozess Ende zu Ende tatsächlich funktioniert. Das ist auch der Moment, ab dem Sie echte Nutzungsdaten gegen die Annahme prüfen, zu deren Test Ihr MVP gebaut wurde.

Sind DSGVO oder KVKK für die App eines kleinen Startups relevant?

Wenn Sie Nutzer in der EU haben, gilt die DSGVO unabhängig von der Größe Ihres Unternehmens. Wenn Sie Nutzer in der Türkei haben, gilt das KVKK auf dieselbe Weise. Keines der beiden Gesetze kennt eine Ausnahme für kleine Startups, also prüfen Sie die Anwendbarkeit während des Scopings, nicht erst, wenn Sie echte Nutzerdaten zu schützen haben.

Fazit

Eine Mobile-App-Checkliste für Startups verdient ihren Platz nur, wenn sie konkret genug ist, um heute danach zu handeln: Definieren Sie Ihr MVP in einem Satz, instrumentieren Sie Analytics vor dem Build, prüfen Sie Ihr Versionsschema in der Woche vor der Einreichung und trennen Sie Ihre iOS- und Android-Checklisten, statt sie als eine Liste zu behandeln. Allein die Punkte Kontolöschung und Datenschutzerklärung machen den Großteil der vermeidbaren Ablehnungen aus, die wir sehen.

Drucken Sie die Checkliste aus, arbeiten Sie sie Phase für Phase ab und überspringen Sie nicht die erste Woche live; das ist der Teil, den jede Wettbewerber-Checkliste auslässt, und der Teil, der tatsächlich bestimmt, ob Ihr Launch Bestand hat. Wenn Sie vor dem Absenden lieber einen zweiten Blick auf Ihre Einreichung werfen lassen möchten, holen Sie sich eine kostenlose Beratung →