Im App Store und bei Google Play veröffentlichen: die komplette Checkliste 2026

Die App zu bauen plant jeder ein. Sie zu veröffentlichen ist der Teil, der überrascht, denn es ist überwiegend Verwaltungsarbeit mit strengen Regeln und asynchronen Rückmeldeschleifen. Eine Ablehnung, die Sie in zehn Minuten hätten verhindern können, kostet Sie eine Kalenderwoche. Dieser Leitfaden geht beide Stores in der Reihenfolge durch, in der Sie sie tatsächlich brauchen: Konten, Assets, Erklärungen, Einreichung, Prüfung – und was am Tag nach dem Launch zu tun ist.

Zuallererst: die beiden Konten

Beide Stores verlangen ein kostenpflichtiges Entwicklerkonto, und beide brauchen Zeit zur Freischaltung. Beginnen Sie damit, bevor die App fertig ist, nicht danach.

Eine früh zu treffende Entscheidung: Registrieren Sie sich auf Ihre Firma, nicht auf Ihren Privatnamen. Eine App später zwischen Konten umzuziehen ist möglich, aber mühsam – und ein Privatname als öffentlich sichtbarer Anbieter wirkt bei Geschäftskunden unprofessionell.

Die Assets, nach denen gefragt wird

Beide Stores verlangen weitgehend dasselbe Material, in unterschiedlichen Größen und mit unterschiedlicher Toleranz für Nachlässigkeit. Bereiten Sie alles in einem Durchgang vor, statt jede Anforderung mitten in der Einreichung zu entdecken.

• Das App-Icon. Ein hochauflösendes Quadrat ohne Transparenz und ohne eigene abgerundete Ecken – die Maske legen die Stores an. Vermeiden Sie kleine Schrift; in Originalgröße wird sie zum Fleck.
• Screenshots. Mehrere Gerätegrößen, darunter mindestens ein großes Telefon. Sie sind der stärkste Hebel für die Installationsrate: Beschriften Sie sie mit einem kurzen Nutzenversprechen, statt rohe Aufnahmen hochzuladen.
• Titel und Untertitel. Kurz und von der Store-Suche indexiert. Nehmen Sie das echte Suchwort in den Titel, keine clevere Markenformel.
• Beschreibung. Gelesen werden vor allem die ersten zwei Zeilen. Beginnen Sie mit dem Nutzen für den Anwender, nicht mit Ihrer Firmengeschichte.
• Feature-Grafik (Google Play). Ein breites Banner, das an mehreren Stellen erscheint. Halten Sie wichtigen Text von den Rändern fern, die beschnitten werden.
• Fragebogen zur Altersfreigabe. Antworten Sie ehrlich. Eine Diskrepanz zwischen Ihren Angaben und dem tatsächlichen Inhalt ist der sicherste Weg, nach dem Launch entfernt zu werden.

Datenschutz: woran Apps scheitern

Beide Stores verlangen inzwischen eine explizite, strukturierte Aufstellung darüber, welche Daten Sie erheben und wozu. Apple nennt es Datenschutzangaben, Google den Bereich Datensicherheit. Das sind zwei getrennte Formulare mit unterschiedlicher Terminologie, und beide müssen dem entsprechen, was Ihre App wirklich tut.

• Eine erreichbare Datenschutzerklärung. Bei beiden Pflicht, vor der Einreichung online, und tatsächlich auf Ihre App bezogen statt eine generische Vorlage.
• Eine korrekte Datenübersicht. Listen Sie jede erhobene Kategorie auf, auch die durch Analyse- oder Absturzberichts-SDKs. Was Drittbibliotheken in Ihrem Auftrag erheben, zählt als Ihre Erhebung.
• Kontolöschung. Wenn Nutzer in Ihrer App ein Konto anlegen können, müssen Sie eine aus der App erreichbare Möglichkeit zum Löschen anbieten. Das ist eine der häufigsten späten Ablehnungen.
• Tracking-Erlaubnis unter iOS. Wenn Sie Nutzer über Apps oder Websites anderer Unternehmen hinweg verfolgen, müssen Sie die Erlaubnis über den Systemdialog einholen. Ohne diesen Dialog wird die App entfernt.

Test-Tracks: nie direkt in die Produktion einreichen

Beide Stores bieten einen Vorstufenweg, in beiden Fällen kostenlos. Nutzen Sie ihn: Ein von zehn Testern gefundener Fehler kostet nichts, derselbe Fehler beim Prüfer kostet Sie einen Prüfzyklus.

• TestFlight (Apple). Nahezu sofortige Verteilung an interne Tester, an externe Tester nach einer leichteren Prüfung. Builds laufen nach 90 Tagen ab.
• Interne, geschlossene und offene Tests (Google). Der interne Test ist fast sofort verfügbar. Ein geschlossener Test mit einer kleinen Gruppe lohnt mindestens eine Woche vor der Produktion, und neue persönliche Entwicklerkonten müssen unter Umständen einen durchführen.

Welchen Track Sie auch wählen: Testen Sie mindestens auf einem kleinen, älteren Android-Gerät und einem aktuellen iPhone. Diese beiden decken die meisten Layout- und Performance-Überraschungen ab.

Die Einreichung, Schritt für Schritt

• 1. App-Eintrag anlegen. Sichern Sie den Namen und die Bundle- bzw. Package-ID. Diese Kennung ist endgültig – nach der Veröffentlichung nicht mehr änderbar, Sie können nur eine neue App veröffentlichen.
• 2. Signierten Build hochladen. Apple verlangt ein signiertes Archiv, hochgeladen von macOS. Google verlangt ein Android App Bundle und einen Signaturschlüssel, den Sie niemals verlieren dürfen: Aktivieren Sie Play App Signing, damit Google eine Kopie verwahrt.
• 3. Store-Eintrag ausfüllen. Titel, Beschreibung, Screenshots, Kategorie, Kontaktdaten und Support-URL.
• 4. Erklärungen vervollständigen. Datenschutz, Datensicherheit, Altersfreigabe, Werbung, Exportkonformität und der Berechtigungsfragebogen, falls Sie sensible Berechtigungen nutzen.
• 5. Prüfern ein funktionierendes Konto geben. Hat Ihre App einen Login, stellen Sie Testzugangsdaten bereit und bei Bedarf eine kurze Notiz, wie man zur Hauptfunktion gelangt. Das wegzulassen ist die häufigste Ursache unnötiger Ablehnungen.
• 6. Einreichen und Release-Strategie festlegen. Wählen Sie manuelle Veröffentlichung, wenn Sie ein Launchdatum koordinieren wollen, und nutzen Sie bei Google Play einen gestaffelten Rollout, damit ein fehlerhafter Build 5 % der Nutzer erreicht statt alle.

Die Ablehnungsgründe, die Sie wirklich treffen

Ablehnungen sind normal, auch bei erfahrenen Teams. Fast alle fallen in eine Handvoll Kategorien.

• Der Prüfer konnte sich nicht anmelden. Fehlende oder abgelaufene Demo-Zugangsdaten, oder ein Login, das einen Code an Ihr Telefon verlangt.
• Tote Links oder Abstürze. Eine nicht erreichbare Support-URL oder ein Absturz auf der Geräteversion des Prüfers. Testen Sie vor dem Einreichen jeden Link Ihres Eintrags.
• „Zu wenig Funktionalität". Apple lehnt Apps ab, die im Kern eine verpackte Website ohne nativen Mehrwert sind. Wenn Sie eine WebView ausliefern, ergänzen Sie echte Gerätefunktionen und Offline-Verhalten.
• Zahlungen außerhalb des Stores. Digitale Inhalte, die in der App konsumiert werden, verlangen in der Regel In-App-Käufe. Physische Waren und Dienstleistungen in der realen Welt nicht.
• Widersprüchliche Datenschutzangaben. Sie erklären, nichts zu erheben, aber ein Analyse-SDK erfasst eine Gerätekennung.
• Metadaten-Probleme. Screenshots, die nicht mehr zur App passen, Wettbewerbernamen in der Beschreibung oder ein stehen gebliebener Platzhaltertext.

Bei einer Ablehnung lesen Sie die exakt zitierte Richtliniennummer, beheben nur diesen Punkt und antworten im Resolution Center mit einer kurzen, sachlichen Erklärung. Diskutieren hilft selten, eine präzise Antwort fast immer.

Nach dem Launch: die ersten dreißig Tage

Live zu sein ist der Anfang der Arbeit, nicht das Ende. Der erste Monat entscheidet, wie die Stores Sie ranken und ob die ersten Nutzer bleiben.

• Beobachten Sie die Absturzrate je Gerät. Beide Konsolen melden sie. Oberhalb von rund 1 % der Sitzungen leiden Ranking und Bewertungen.
• Beantworten Sie jede Bewertung, schnell. Öffentliche Antworten verändern sichtbar, wie ein Eintrag wirkt, und eine gelöste Beschwerde wird oft zu einer besseren Note.
• Iterieren Sie am Eintrag, nicht nur an der App. Den ersten Screenshot oder den Untertitel zu ändern bewegt die Installationsrate oft stärker als eine neue Funktion.
• Veröffentlichen Sie alle paar Wochen ein kleines Update. Aktualität ist ein Ranking-Signal, und ein stetiger Rhythmus macht Prüfzeiten planbar.
• Bringen Sie eigenen Traffic mit. Die Store-Suche entdeckt Sie nicht von allein. Ihre Website, Ihr E-Mail-Verteiler und Ihre bestehenden Kunden sind der Launchkanal.

Wo Cadrant hilft

Cadrant setzt vor der Einreichung an: eine echte, funktionierende App schnell genug vor Nutzer zu bringen, damit Sie wissen, was eine Veröffentlichung verdient. Sie beschreiben Ihre Screens, Ihre Daten und Ihre Nutzerrollen in einfacher Sprache, iterieren an einer laufenden App in Stunden statt Monaten und behalten die Datenbank in Ihrem eigenen Supabase-Projekt. Wenn sich das Produkt bei echten Nutzern bewährt hat, gehen Sie mit stabilem Umfang in den Store-Prozess, statt zu raten.

Diese Reihenfolge zählt. Die meisten Erstveröffentlicher reichen einen Umfang ein, den niemand getestet hat, und verbrauchen dann Prüfzyklen für Produktprobleme statt für Store-Probleme.

Kurzfassung

Veröffentlichen ist ein Verwaltungsprojekt mit einer Code-Abhängigkeit. Eröffnen Sie beide Entwicklerkonten früh, bereiten Sie Icon, Screenshots, Beschreibung, Datenschutzerklärung und Datenangaben in einem Durchgang vor, nutzen Sie vor der Produktion einen echten Test-Track und geben Sie den Prüfern ein funktionierendes Konto mit klaren Hinweisen. Dann ist die Prüfung meist der einfache Teil.