Zum Hauptinhalt springen

App Review Guidelines 2026: Checkliste für die erste Einreichung bei Apple und Google Play

App-Review-Guidelines für die erste Einreichung 2026. Apple App Store und Google Play Review-Zeiten, Richtlinien, Demo-Accounts, Datenschutz und häufige Ablehnungsgründe.

App-Review-Guidelines 2026: Checkliste für die erste Einreichung bei Apple App Store und Google Play Capgo Blog-Illustration

Kurzantwort: App-Review-Guidelines sind die Regeln, die Apple und Google vor dem Livegang deiner App prüfen. Apples App Store Review Guidelines sind unterteilt in Sicherheit, Performance, Business, Design und Rechtliches. Google prüft dein Release gegen die Richtlinien für Entwicklerprogramme sowie Play Console Anforderungen wie Content Rating und Datensicherheit. Review-Zeiten: Apple gibt an, dass der App Review rund um die Uhr läuft und typischerweise mindestens 50 % der Einreichungen innerhalb von 24 Stunden und 90 % innerhalb von 48 Stunden abschließt (App-Review). Google gibt an, dass einige Konten warten müssen bis zu sieben Tage oder länger in Ausnahmefällen (Veröffentliche deine App). Neue persönliche Play Console-Konten benötigen zudem mindestens 12 Tester, die 14 Tage lang durchgehend angemeldet bleiben im geschlossenen Testlauf, wobei zum Zeitpunkt der Beantragung für die Produktion. Ablehnungen beim ersten Mal liegen oft an 2.1 App-Vollständigkeit (Abstürze, defekte Links, schlechte Demo-Accounts), 2.3 Korrekte Metadaten, und 5.1 Datenschutz auf iOS, sowie unvollständige Play-Richtlinien oder Testschritte auf Android. Für Richtlinie 4.2 und 4.3 Strategie, lies So bestehst du 2026 das App Store Review. Zu Bewertungen und Kindersicherung siehe den App Store Age Ratings Guide. Zu Anmeldegebühren siehe Kosten für die App-Veröffentlichung im App Store.

Die erste App im App Store oder Play Store einzureichen, kann überwältigend wirken. Bei sich ständig weiterentwickelnden Richtlinien und strengerer Durchsetzung im Jahr 2026 erfordert die Zulassung deiner App große Sorgfalt. Diese Checkliste zeigt dir, worauf Reviewer bei einer ersten Einreichung für iOS und Android achten – tiefergehende Playbooks zu Apple-Ablehnungen findest du in unserem So bestehst du 2026 das App Store Review Leitfaden, wenn du über diese Übersicht hinaus Details auf Richtlinienebene brauchst.

Den Review-Prozess 2026 verstehen

Sowohl Apple als auch Google haben ihre Review-Prozesse in den letzten Jahren deutlich verschärft, mit besonderem Fokus auf Datenschutz, Sicherheit und User Experience. Diese Änderungen zu verstehen ist für Erstentwickler entscheidend.

iOS App Store Review-Zeitrahmen

Apple veröffentlicht Zeitangaben auf seiner App-Review Seite:

  • Typische Bearbeitungszeit: Mindestens 50 % der Einreichungen werden in weniger als 24 Stunden geprüft, 90 % in weniger als 48 Stunden.
  • Unvollständige Einreichungen: Die Prüfung kann sich verzögern oder fehlschlagen, wenn Metadaten, Demo-Zugriff oder Compliance-Antworten fehlen
  • Komplexe Apps: Apple weist darauf hin, dass Apps, die eine genauere Prüfung erfordern, länger dauern können (Nach dem Absenden)
  • Beschleunigter Review: Available for critical bug fixes or time-bound events after you submit through App Store Connect and send the request through Apples Formular für beschleunigte Prüfungen

Plane mit den durchschnittlichen Zeiten, nicht mit kurzzeitigen Warteschlangen-Spitzen, und betrachte jede fehlende Review-Info als Verzögerungsrisiko.

App Store Connect Statusmeldungen

  • Vorbereitung der Einreichung: Dein Build oder deine Metadaten werden noch vorbereitet
  • Warten auf Review: Apple hat deine Einreichung in der Warteschlange
  • In Prüfung: Das Review-Team prüft die App gerade aktiv
  • Wartet auf Release durch Entwickler: Genehmigt, wartet aber auf deine manuelle Freigabe
  • Abgelehnt / Offene Probleme: Apple benötigt Änderungen vor der Genehmigung

Google Play Store Review-Zeitplan (Update 2026)

Google gibt folgende Review-Zeiten an: App veröffentlichen:

  • Standard-Veröffentlichung: Updates werden so schnell wie möglich nach der Review verarbeitet und veröffentlicht
  • Verlängerte Review-Dauer: Bei einigen Developer-Accounts kann Google bis zu sieben Tage oder in Ausnahmefällen länger benötigen
  • Closed Testing Phase: Private Accounts, die nach dem 13. November 2023 erstellt wurden, benötigen mindestens 12 Tester, die mindestens 14 aufeinanderfolgende Tage lang durchgehend teilnehmen am Closed Testing, und mindestens 12 Tester müssen noch aktiv sein, wenn du den Antrag auf Production-Zugriff stellst
  • Nach dem Testing: Die Production-Review erfolgt gemäß den Play-Richtlinien, bevor die App live geht

Wichtiges Update: Google verlangt nun wesentlich strengere Tests für einige neue Play Console Accounts, worauf wir unten im Detail eingehen.

Apple-Developer-Account einrichten

Bevor du dein erstes iOS-Release veröffentlichst, stelle sicher, dass die Apple-Seite korrekt eingerichtet ist:

  • Registriere dich im Apple Developer Program
  • Aktiviere die Zwei-Faktor-Authentifizierung für den Apple Account, den du für die Registrierung nutzt
  • Wähle den richtigen Mitgliedschaftstyp:
    • Einzelperson / Einzelunternehmer: dein gesetzlicher Name wird als Verkäufername im App Store angezeigt
    • Organisation: erfordert eine juristische Person, eine D-U-N-S-Nummer, eine öffentliche Website und eine Person, die das Unternehmen an Apples Vereinbarungen binden darf
  • Verwenden Sie bei der Anmeldung echte Namen. Pseudonyme oder Firmennamen in den Vor- und Nachname-Feldern können die Genehmigung verzögern
  • Nach der Genehmigung der Anmeldung melden Sie sich bei App Store Connect an und erstellen den App-Eintrag mit der finalen Bundle ID, dem App-Namen, der SKU und der Primärsprache

Apple Developer Program Anmeldeseite

Apple-Anmeldung im Web fortsetzen

Wählen Sie den richtigen Apple Developer Entity-Typ

Wichtig: Apple passt die SDK Mindestanforderungen regelmäßig an. Stand 28. April 2026 müssen im App Store Connect hochgeladene Apps die iOS & iPadOS 26 SDK oder neuer verwenden.

Die kritische Android-Testvorgabe

Dies ist die Änderung, die die meisten Android-Publisher beim ersten Mal überrascht:

12-Tester-Vorgabe für neue persönliche Android-Accounts

Wenn Ihr Google Play-Entwicklerkonto ein Persönliches Konto, erstellt nach dem 13. November 2023, musst du eine geschlossene Testphase durchlaufen, bevor die App in Produktion gehen kann:

Anforderungen:

  • Mindestens 12 Tester: Sie müssen mindestens 12 Tester haben, die durchgehend angemeldet bleiben
  • 14-tägige TestphaseDiese Tester müssen während des geschlossenen Tests für mindestens 14 aufeinanderfolgende Tage angemeldet bleiben.
  • Antrag auf Produktionszugriff: Bei der Beantragung müssen nach dem geschlossenen Testzeitraum noch mindestens 12 Tester angemeldet sein
  • Feedback sammeln: Du solltest gefundene Probleme, vorgenommene Fixes und die Nutzung der App durch die Tester dokumentieren

So richtest du deinen Testing Track ein

  1. Geschlossenen Test-Track erstellen

    • Google Play Console öffnen
    • Navigiere zu Testen und Veröffentlichen > Testen > Geschlossener Test
    • Neues Release im geschlossenen Test-Track erstellen
    • Android App Bundle hochladen (.aab)
  2. Tester rekrutieren

    So findest du Tester:

    • Freunde und Familie (einfachster Einstieg)
    • Developer-Communities (Reddit: /r/androiddev, /r/betatests)
    • Social-Media-Follower
    • Beta-Testing-Plattformen (BetaList, BetaTesting.com)
    • Studenten (falls du Kontakte hast)

    Wichtig: Stelle sicher, dass Tester:

    • Gültige Gmail-Konten haben
    • Tatsächlich Android-Geräte nutzen
    • Während des gesamten 14-Tage-Zeitraums opt-in bleiben
  3. Tester einladen

    • Testerliste in der Play Console erstellen
    • Tester-E-Mail-Adressen hinzufügen
    • Die Opt-in-URL mit deinen Testern teilen
    • Erinnerungen senden, damit sie die App installieren und nutzen
  4. Testaktivität überwachen

    • Installationszahlen in der Play Console prüfen
    • Crash-Reports und ANRs (Application Not Responding) tracken
    • Feedback von Testern sammeln
    • Kritische Fehler vor dem Rollout beheben
  5. Produktionsfreigabe beantragen

    • Bei der Beantragung müssen mindestens 12 Tester durchgehend für die letzten 14 Tage aktiv geblieben sein
    • Produktionszugriff über das Play Console Dashboard beantragen
    • Alle Crash-Reports und das Feedback prüfen
    • Production Release erstellen und zur finalen Prüfung einreichen

Warum Google das eingeführt hat

Google hat diese Anforderung eingeführt, um:

  • App-Spam geringer Qualität reduzieren
  • Sicherstellen, dass Apps vor dem Release getestet wurden
  • Schädliche Apps durch Nutzungsmuster erkennen
  • Die Play Store Qualität insgesamt verbessern

Realitätscheck: Dies verlängert deinen Launch-Zeitplan um 2–3 Wochen. Plane das ein und suche frühzeitig Tester.

Anforderungen an Authentifizierung und Login

Einer der häufigsten Ablehnungsgründe ist eine fehlerhafte Implementierung von Authentifizierungssystemen, insbesondere bei Social Login.

Die Apple-Sign-in-Pflicht (kritisch für iOS)

Apples Regel: Wenn deine App Social Login von Drittanbietern (Google, Facebook, Twitter etc.) anbietet, musst du musst biete auch Sign in with Apple als Option an.

Dies gilt für:

  • Google Sign-In
  • Facebook Login
  • Twitter/X Login
  • LinkedIn Login
  • Alle anderen Third-Party-Authentifizierungsdienste

Dies gilt NICHT für:

  • Authentifizierung nur per E-Mail/Passwort
  • Staatliche ID-Systeme
  • Enterprise SSO-Systeme (wenn die App nur für dieses Unternehmen ist)
  • Authentifizierungssysteme von Bildungsanbietern

Sign in with Apple implementieren

Wenn du Social Login nutzt, musst du Folgendes implementieren:

import { SignInWithApple } from '@capacitor-community/apple-sign-in';

async function signInWithApple() {
  try {
    const result = await SignInWithApple.authorize({
      clientId: 'com.yourapp.service',
      redirectURI: 'https://yourapp.com/auth/callback',
      scopes: 'email name',
      state: '12345',
      nonce: 'nonce',
    });

    // result contains:
    // - identityToken
    // - authorizationCode
    // - email (may be null if user previously authorized)
    // - givenName
    // - familyName

    // Send to your backend for verification
    await verifyAppleToken(result.identityToken);

  } catch (error) {
    console.error('Apple Sign In failed:', error);
  }
}

Wichtige Hinweise:

  1. E-Mail-Datenschutz: Nutzer können ihre E-Mail verbergen. Apple stellt eine private Relay-E-Mail bereit (z. B. abc123@privaterelay.appleid.com). Deine App muss damit umgehen können.

  2. Erstnutzer vs. wiederkehrende Nutzer: Apple liefert Nutzerdetails (Name, E-Mail) nur bei der ersten Autorisierung. Speichere diese Infos, da sie bei späteren Logins nicht mehr enthalten sind.

  3. Button-Design: Apple gibt strikte Design-Richtlinien für den Sign in with Apple-Button vor. Nutze die offiziellen Assets.

  4. Backend-Verifizierung: Verifiziere den Identity-Token immer auf deinem Backend-Server; vertraue niemals allein auf clientseitige Tokens.

Social-Login-Anforderungen für Android

Android erfordert zwar keinen spezifischen Provider wie iOS, aber Google hat Richtlinien:

Google-Sign-In-Anforderungen:

  • Offizielles Google Sign-In SDK ist Pflicht
  • Google-Branding-Guidelines müssen eingehalten werden
  • Sollte die primäre Option sein, falls angeboten

Best Practice für Cross-Platform: Bieten Sie für die Konsistenz auf beiden Plattformen die gleichen Login-Optionen an:

  • E-Mail/Passwort
  • Sign in with Apple (nur iOS, oder auf Android bei web-basiertem Apple-Login)
  • Mit Google anmelden
  • Andere Social-Optionen (Facebook, Twitter, etc.)

Anforderungen für Demo-Accounts

Entscheidend für den Review: Wenn deine App einen Login erfordert, musst du musst funktionierende Demo-Zugangsdaten in den App Review Notes angeben.

Demo Account Information:

Username: reviewer@demo.com
Password: ReviewTest123!

OR

Test Phone: +1 555-0123
Test OTP: 123456 (static for review)

Notes:
- This account has full premium features enabled
- All payment flows work in sandbox mode
- Account will reset daily

Häufige Fehler:

  • Abgelaufene Zugangsdaten bereitstellen
  • Demo-Account hat keinen Zugriff auf alle Features
  • Keine Info zum Umgehen der Telefonverifizierung
  • Sandbox-Zahlungsdetails vergessen zu erwähnen

Beide App Stores verlangen nun zugängliche Datenschutzrichtlinien und AGB bevor deine erste Einreichung wurde genehmigt.

Anforderungen an die Datenschutzerklärung

Deine Datenschutzerklärung muss:

  1. Öffentlich zugänglich sein

    • Gehostet unter einer öffentlichen URL (ohne Login)
    • In Standard-Webbrowsern aufrufbar sein
    • In denselben Sprachen wie deine App verfügbar sein
  2. Diese Pflichtthemen abdecken:

    • Welche Daten du sammelst (sei konkret)
    • Wie du die gesammelten Daten nutzt
    • Ob Daten an Dritte weitergegeben werden
    • Speicherdauer der Daten
    • Nutzerrechte (Zugriff, Löschung, Portabilität)
    • Kontakt für Datenschutzanfragen
    • Kinderschutz (bei Nutzern unter 13/16 Jahren)
  3. In-App-Verknüpfung

    • Über Einstellungen oder Account erreichbar
    • Mit nur einem Tap erreichbar (nicht in Menüs versteckt)
    • Sollte im Standard- oder In-App-Browser öffnen

Wo du deine Datenschutzerklärung hostest

Option 1: Deine Website (Empfohlen)

https://yourapp.com/privacy-policy
https://yourapp.com/terms-of-service

Option 2: GitHub Pages (Kostenlos)

https://yourusername.github.io/app-privacy-policy

Option 3: Privacy-Policy-Generatoren (Schnellstart)

Wichtig: Generatoren sind für den Start okay, aber achte darauf, dass die Policy deine tatsächliche Datenverarbeitung korrekt widerspiegelt. Generische Templates, die nicht zu deiner App passen, werden beanstandet.

Anforderungen an die Nutzungsbedingungen

AGB sind nicht immer zwingend erforderlich, werden aber dringend empfohlen und sind notwendig, wenn:

  • Du In-App-Käufe oder Abos anbietest
  • Du User-Generated Content hast
  • Du bietest Dienste an, die über die Grundfunktionen der App hinausgehen
  • Du möchtest rechtlich abgesichert sein

Muss enthalten sein:

  • Nutzungsbedingungen (AUP)
  • Bedingungen zur Kontokündigung
  • Haftungsbeschränkung
  • Intellectual property rights
  • Verfahren zur Streitbeilegung
  • Rückerstattungsrichtlinien (besonders für IAP)

Implementierung in der App

// Settings or Account Screen
function LegalLinks() {
  return (
    <div className="legal-section">
      <h3>Legal</h3>
      <a
        href="https://yourapp.com/privacy-policy"
        target="_blank"
        rel="noopener noreferrer"
      >
        Privacy Policy
      </a>
      <a
        href="https://yourapp.com/terms-of-service"
        target="_blank"
        rel="noopener noreferrer"
      >
        Terms of Service
      </a>
      <a
        href="https://yourapp.com/contact"
        target="_blank"
        rel="noopener noreferrer"
      >
        Contact Us
      </a>
    </div>
  );
}

Anforderungen an App-Store-Metadaten

Beide Stores verlangen die URL der Datenschutzerklärung bei der App-Einreichung:

iOS – App Store Connect:

  • App-Informationen &gt; Allgemeine Informationen &gt; Datenschutzrichtlinien-URL
  • Muss HTTPS sein (HTTP wird abgelehnt)
  • Wird auf deiner App-Store-Seite angezeigt
  • Füge eine Support-URL mit echten Kontaktdaten für Nutzer hinzu
  • Fülle den Fragebogen zur Altersfreigabe vor der Einreichung aus

Android - Google Play Console:

  • Store-Präsenz &gt; Store-Einstellungen &gt; Datenschutzrichtlinie
  • Erforderlich für alle Apps, die sich an Kinder richten
  • Dringend empfohlen für alle Apps

Datenschutz-Labels (iOS)

iOS erfordert detaillierte Datenschutzangaben im „Nutrition Label“-Format:

Pflichtangaben zu Kategorien:

  • Kontaktinfos: E-Mail, Name, Telefonnummer
  • Finanzdaten: Zahlungsinfos, Kreditkarte, Bankkonto
  • Ort: Genaue oder ungefähre Position
  • Nutzerinhalte: Fotos, Videos, Audio, Nachrichten
  • Identifikatoren: User ID, Device ID, Advertising ID
  • Nutzungsdaten: Produktinteraktion, Werbedaten, Crash-Logs
  • Diagnose: Crash-Daten, Performance-Daten

Geben Sie für jeden Datentyp an::

  • Ob sie gesammelt werden
  • Ob sie mit der Nutzeridentität verknüpft sind
  • Ob sie zum Tracking genutzt werden
  • Zweck der Datenerhebung

Häufiger Fehler: Zu behaupten, keine Daten zu sammeln, obwohl Ihr SDK dies tut. Prüfen Sie alle Third-Party-SDKs auf ihre Datenerhebung.

Google Play Data-Safety-Bereich

Ähnlich wie bei iOS erfordert Android eine Datensicherheitserklärung:

Schritte:

  1. Play Console > App-Inhalte > Datensicherheit
  2. Fragen zur Datenerfassung beantworten
  3. Gesammelte Datentypen angeben
  4. Sicherheitspraktiken erläutern (Verschlüsselung etc.)
  5. Link zur Datenschutzerklärung angeben

Kritisch: Diese Angaben sind rechtlich bindend. Falschangaben können zur Entfernung der App und zur Sperrung des Kontos führen.

Häufige Ablehnungsgründe bei der ersten Einreichung

Zu verstehen, warum Apps abgelehnt werden, hilft dabei, diese Fehler zu vermeiden:

1. App stürzt ab oder startet nicht

Warum das passiert:

  • Nur auf dem Emulator getestet, nicht auf echten Geräten
  • Fehlende Error-Handling bei Netzwerkfehlern
  • Hardcodierte API Endpoints, die nicht erreichbar sind
  • Annahme spezifischer Gerätefunktionen (Kamera, GPS)

So verhinderst du es:

// Always implement proper error handling
async function loadData() {
  try {
    const response = await fetch('https://api.yourapp.com/data');

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    const data = await response.json();
    return data;

  } catch (error) {
    // Show user-friendly error
    showError('Unable to load data. Please check your connection.');

    // Log for debugging
    console.error('Data load failed:', error);

    // Graceful degradation
    return getCachedData();
  }
}

Testing-Checkliste:

  • Auf echten Geräten testen (mind. 2-3 verschiedene Modelle)
  • Bei schlechter Verbindung testen (Network Link Conditioner nutzen)
  • Im Flugmodus testen
  • Bei verweigerten Berechtigungen testen
  • Mit Neuinstallation testen (keine Cache-Daten)

2. Fehlende oder defekte Kernfunktionen

Warum das passiert:

  • In Screenshots gezeigte Features existieren noch nicht
  • Demo-Account hat keinen Zugriff auf beworbene Features
  • Premium-Features werden gezeigt, sind aber nicht implementiert
  • „Coming Soon“-Platzhalter in der App

So verhinderst du es:

  • Erst einreichen, wenn alle beworbenen Features fertig sind
  • Sicherstellen, dass der Demo-Account vollen Zugriff hat
  • Unfertige Features vor dem Submit entfernen oder deaktivieren
  • Screenshots exakt an den aktuellen Build anpassen

3. Unpassende Inhalte für die Altersfreigabe

Warum das passiert:

  • Altersfreigabe auf 4+ gesetzt, aber App enthält Social-Features
  • Age rating doesn’t match actual content
  • User-generated Content ohne Moderation
  • Links zu unmoderierten externen Inhalten

So setzt man die korrekte Altersfreigabe:

iOS Altersfreigaben:

  • 4+ (keine anstößigen Inhalte)
  • 9+ (gelegentliche leichte Inhalte)
  • 12+ (moderate Inhalte)
  • 17+ (häufige/intensive Inhalte)

Android-Inhaltsbewertungen:

  • Jeder
  • Für alle ab 10 Jahren
  • Jugendliche
  • Erwachsene 17+
  • Nur Erwachsene 18+

Wichtig: Wenn Nutzer Inhalte miteinander teilen können, brauchst du:

  • Content-Moderationssystem
  • Melde-/Blockierfunktion
  • Klare Community-Richtlinien
  • Altersprüfung, falls nötig

4. Irreführende Metadaten

Warum das passiert:

  • App-Name verspricht Funktionen, die es nicht gibt
  • Screenshots von Konkurrenten oder Mockups
  • Gefälschte Reviews oder Manipulation von Ratings
  • Beschreibung nutzt Superlative ohne Belege

Beispiele für problematische Metadaten:

❌ SCHLECHT:

  • App-Name: „Bester Fitness Tracker - #1 App“
  • Beschreibung: „Die unglaublichste, revolutionärste App aller Zeiten!“
  • Screenshots: Generische Stockfotos

✅ GUT:

  • App-Name: „FitTrack - Workout Logger“
  • Beschreibung: „Tracke deine Workouts mit anpassbaren Routinen und Fortschrittscharts.“
  • Screenshots: Echte App-Screens aus dem aktuellen Build

5. Unzureichendes Testing (besonders Android Closed Testing)

Warum das passiert:

  • Die vorgeschriebene 14-tägige Testphase überspringen
  • Zu wenige Tester rekrutieren
  • Tester nutzen die App nicht wirklich
  • Kein Crash-Monitoring während des Tests

So verhinderst du es:

  • Tester 3–4 Wochen vor dem geplanten Launch rekrutieren
  • Firebase Crashlytics oder Ähnliches beim Testen nutzen
  • Aktiv mit Testern interagieren (Umfragen, Feedback-Formulare)
  • Kritische Issues vor dem Production-Release fixen

6. Berechtigungen ohne Begründung

Warum das passiert:

  • Standort anfragen, aber nicht nutzen
  • Kamera-Berechtigung ohne Erklärung
  • Kontaktzugriff ohne klaren Zweck
  • Hintergrundstandort für Nicht-Navigations-Apps

So behebst du das:

iOS - Info.plist:

<key>NSCameraUsageDescription</key>
<string>Camera access is required to scan QR codes for quick login.</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>Location helps us show nearby fitness centers and outdoor running routes.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Photo library access lets you upload a profile picture and share workout photos.</string>

Android - Permissions-Strategie:

<!-- Only request what you actually need -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Use when-in-use rather than always for location -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<!-- Avoid if possible -->
<!-- <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> -->

Runtime-Berechtigungsanfrage:

import { Camera } from '@capacitor/camera';

async function takePicture() {
  // Request with context
  const permissionStatus = await Camera.requestPermissions();

  if (permissionStatus.camera === 'granted') {
    const photo = await Camera.getPhoto({
      quality: 90,
      allowEditing: true,
      resultType: 'uri'
    });

    return photo;
  } else {
    // Explain why permission is needed
    showDialog(
      'Camera access required',
      'To upload a profile picture, please enable camera access in Settings.'
    );
  }
}

iOS-spezifische Anforderungen

App Store Screenshots und Previews

Erforderliche Größen:

  • 6,7” iPhone: 1290 x 2796
  • 13” iPad: 2064 x 2752
  • 12,9” iPad: 2048 x 2732

Wichtig: Wenn deine App iPad unterstützt, musst du iPad-Screenshots hochladen. Ziehe iPhone-Screenshots nicht in die Länge, damit sie in die iPad-Slots passen.

Best Practices für Screenshots:

  • Echten App-Content zeigen (keine Mockups)
  • Statusleiste entfernen oder realistischen Content zeigen
  • Für alle unterstützten Sprachen lokalisieren
  • Zu viel Text-Overlay vermeiden
  • Key Features in den ersten 2-3 Screenshots zeigen

Metadaten-Setup in App Store Connect

Vor dem Submit: Diese App Store Connect Felder ausfüllen:

  • URL der Datenschutzrichtlinie: Pflichtangabe für iOS-Apps
  • Support-URL: Pflichtangabe; sollte zu echten Kontaktinfos führen
  • Altersfreigabe: Fragebogen ausfüllen, damit die App veröffentlicht werden kann
  • App Review Informationen: füge einen Kontakt für Rückfragen, funktionierende Demo-Zugangsdaten (falls ein Login nötig ist) und klare Anweisungen für das Review-Team hinzu
  • Exportkontrolle: Fragen zur Verschlüsselung beantworten oder festlegen ITSAppUsesNonExemptEncryption in Info.plist wenn sinnvoll, damit du bei jedem Upload nicht dieselben Antworten wiederholen musst

TestFlight vor dem App Review

Führe vor dem Production-Review einen echten TestFlight-Durchlauf durch:

  • Installiere genau den Build aus TestFlight
  • Melde dich mit demselben Review-Account an, den du auch angeben willst
  • Geh die Abläufe für Kauf, Wiederherstellung und Kündigung durch
  • Stelle sicher, dass der Reviewer die Kernfunktionen ohne versteckte Einrichtung erreichen kann
  • Teste auf iPhone und iPad, falls beide unterstützt werden

Anforderungen:

  • Dauer: 15–30 Sekunden
  • Echte App-Aufnahmen zeigen
  • Kurze Texteinblendungen erlaubt
  • Keine urheberrechtlich geschützte Musik
  • Gleiche Auflösung wie Screenshots

Sign in with Apple implementieren

Bereits erwähnt, aber bei Social Login kritisch für den iOS-Review.

Anforderungen für In-App-Käufe

Falls digitale Güter oder Services angeboten werden:

Erforderliche Angaben:

  • Klare Preise vor dem Kauf
  • Abo-Bedingungen deutlich angeben
  • Kündigungshinweise gut sichtbar
  • Button „Käufe wiederherstellen“

Beispiel: konformer Subscription-Screen:

function SubscriptionOffer() {
  return (
    <div className="subscription-screen">
      <h2>Choose Your Plan</h2>

      <PlanCard>
        <h3>Monthly</h3>
        <p className="price">$9.99/month</p>
        <ul>
          <li>Unlimited workouts</li>
          <li>Personalized plans</li>
          <li>Progress tracking</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <PlanCard>
        <h3>Annual</h3>
        <p className="price">$79.99/year</p>
        <p className="savings">Save 33%</p>
        <ul>
          <li>Everything in Monthly</li>
          <li>Priority support</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <div className="subscription-terms">
        <p>
          Subscription automatically renews unless cancelled at least
          24 hours before the end of the current period. Manage your
          subscription in Settings.
        </p>
        <button onClick={restorePurchases}>Restore Purchases</button>
      </div>

      <div className="legal-links">
        <a href="/privacy/">Privacy Policy</a> |
        <a href="/terms">Terms of Service</a>
      </div>
    </div>
  );
}

Android-spezifische Anforderungen

Account-Setup in der Google Play Console

Vor deinem ersten Android-Release: Stelle sicher, dass das Play-Console-Konto und die App-Shell vorhanden sind:

  • Erstelle dein Developer-Konto unter Play-Console-Registrierung
  • Gehe in der Play Console zu Startseite &gt; App erstellen
  • Wähle die Standardsprache, den App-/Spieltyp und die Support-E-Mail
  • Akzeptiere die erforderlichen Erklärungen zu Play-Richtlinie, Export und Play App Signing
  • Entscheide, ob die App kostenlos oder paid

Wichtig: Google erlaubt es, eine kostenpflichtige App später kostenlos zu machen; sobald eine App jedoch einmal kostenlos war, kann sie nicht mehr kostenpflichtig werden.

App-Bundle-Anforderung

Wichtig: Google Play erfordert das Android App Bundle (.aab) Format, kein APK:

# Sync the native Android project first
bunx cap sync android

# Then build the release app bundle
cd android
./gradlew bundleRelease

Anforderung an das Target-API-Level

Aktuelle Anforderungen: Neue Apps und Updates müssen Android 15 (API Level 35) oder höher unterstützen.

Update in android/app/build.gradle:

android {
    compileSdkVersion 35

    defaultConfig {
        targetSdkVersion 35
        minSdkVersion 23  // Minimum supported version
    }
}

Google Play Datensicherheit

Wurde oben bereits erwähnt, ist aber absolut entscheidend für die Android-Zulassung.

Geschlossener Testtrack (aktuelle Anforderung)

Das ist die größte Hürde für neu erstellte persönliche Entwicklerkonten: die zuvor beschriebene Anforderung, 12 Tester für 14 Tage kontinuierlich über ein Opt-in zu halten.

Zeitplan:

  1. Woche 1: Tester rekrutieren, geschlossenen Test einrichten
  2. Woche 2-3: Aktive Testphase (mind. 14 Tage)
  3. Woche 4: Bugs fixen, Production-Release vorbereiten
  4. Woche 5: Zur Production-Review einreichen

Zielgruppe und Inhaltsbewertung

Fragebogen zur Inhaltsbewertung:

  • Für alle Apps erforderlich
  • Dauert etwa 10–15 Minuten
  • Bestimmt die Altersfreigabe (Everyone, Teen, Mature usw.)
  • Aktualisiere es immer, wenn sich deine Inhalte so ändern, dass sie die Antworten beeinflussen

Themenübersicht:

  • Gewalt
  • Sexuelle Inhalte
  • Schimpfwörter
  • Kontrollierte Substanzen
  • Glücksspiel
  • Funktionen zur Nutzerinteraktion

Wichtig: Wenn du User-Generated Content oder Social-Features hast, musst du das angeben und Moderation implementieren.

Anforderungen für den Store-Eintrag

Erforderliche Assets:

  • App-Icon (512 x 512 PNG)
  • Feature-Grafik (1024 x 500 JPG oder PNG)
  • Smartphone-Screenshots (min. 2, max. 8)
  • 7-Zoll-Tablet-Screenshots (optional, aber empfohlen)
  • 10-Zoll-Tablet-Screenshots (optional, aber empfohlen)

Anforderungen an die Beschreibung:

  • Kurzbeschreibung (max. 80 Zeichen)
  • Vollständige Beschreibung (max. 4000 Zeichen)
  • Muss die App-Funktionen korrekt beschreiben
  • Darf keine Kontaktdaten oder Preisangaben enthalten

Checkliste vor dem Einreichen

Bevor du auf Absenden klickst, geh diese umfassende Checkliste durch:

Technische Anforderungen

  • App startet erfolgreich auf echten Geräten
  • Alle in den Screenshots gezeigten Features funktionieren
  • Keine Platzhalter oder „Coming Soon“-Inhalte
  • Alle API Keys von Drittanbietern sind Production-Keys
  • Netzwerkfehlerbehandlung implementiert
  • Berechtigungsanfragen enthalten klare Erklärungen
  • App stürzt bei schlechter Verbindung nicht ab
  • Test mit abgelehnten Berechtigungen durchgeführt
  • Auf minimal unterstützter OS-Version getestet
  • Memory Leaks geprüft und behoben

Authentifizierung & Login

  • Bei Social Login ist Sign in with Apple enthalten (iOS)
  • Demo-Account-Zugangsdaten in den Review-Notizen angegeben
  • Demo-Account hat Zugriff auf alle Features
  • Passwort-Reset-Flow funktioniert
  • Logout-Funktion funktioniert korrekt
  • Option zur Kontolöschung verfügbar (von DSGVO/CCPA gefordert)
  • Datenschutzerklärung öffentlich zugänglich
  • URL der Datenschutzerklärung im App-Store-Eintrag hinterlegt
  • AGB öffentlich zugänglich (falls zutreffend)
  • Datenschutzrichtlinie in der App verlinkt (Einstellungen)
  • Datenschutz-Labels korrekt hinterlegt (iOS)
  • Datensicherheitsbereich ausgefüllt (Android)
  • Alle Zwecke der Datenerhebung erklärt
  • Datenerhebung durch Drittanbieter SDK offengelegt

Inhalt &amp; Metadaten

  • App-Name entspricht Richtlinien (kein Keyword-Stuffing)
  • Beschreibung gibt Funktionen korrekt wieder
  • Screenshots zeigen aktuelle App-Ansichten
  • Screenshots für alle unterstützten Sprachen lokalisiert
  • Keine Erwähnung von Wettbewerbern in der Beschreibung
  • Keine Superlative ohne Belege
  • Altersfreigabe passt zum tatsächlichen Inhalt
  • Kontakt-E-Mail wird geprüft

iOS-spezifisch

  • Sign in with Apple implementiert (falls Social Login genutzt wird)
  • Alle erforderlichen Screenshot-Größen bereitgestellt
  • Echte iPad-Screenshots hochgeladen (falls iPad-Support aktiviert)
  • Info.plist-Berechtigungsbeschreibungen sind klar formuliert
  • Support-URL mit echten Kontaktdaten hinzugefügt
  • URL der Datenschutzrichtlinie in App Store Connect hinterlegt
  • Altersfreigabe-Fragebogen ausgefüllt
  • Export-Compliance korrekt beantwortet
  • App-Review-Kontakt und zeitlich unbegrenzter Demo-Account bereitgestellt
  • Ziel-iOS: 15.0 oder höher
  • Bei IAP: Preise klar, Button „Käufe wiederherstellen“ vorhanden
  • Keine Verweise auf Android oder andere Plattformen

Android-spezifisch

  • App Bundle (.aab) als Format verwendet
  • Target API 35 oder höher
  • Altersfreigabe-Fragebogen ausgefüllt
  • Feature Graphic hochgeladen
  • Geschlossener Test abgeschlossen, falls Play Console dies erfordert (12 Tester über 14 Tage hinweg, davon zum Zeitpunkt der Einreichung noch mindestens 12)
  • Crash-Reports aus dem Testing geprüft und behoben
  • Keine Verweise auf iOS oder andere Plattformen

Testing (aktuelle Android-Anforderung)

  • 12+ Tester rekrutiert (falls Play-Account geschlossene Tests erfordert)
  • Track für geschlossenen Test erstellt
  • Über 12 Tester blieben 14 Tage lang durchgehend angemeldet, und mindestens 12 waren zum Zeitpunkt der Beantragung noch angemeldet
  • Tester haben die App tatsächlich genutzt (nicht nur installiert)
  • Crash-Monitoring während des Testens aktiviert
  • Kritische Bugs aus dem Testlauf behoben
  • Tester-Feedback dokumentiert

Review-Notizen: Das gehört rein

Gute Review-Notizen entscheiden oft über sofortige Approval oder Ablehnung. Das sollte enthalten sein:

Vorlage für Review-Notizen

APP REVIEW INFORMATION

=== Test Account ===
Email: reviewer@testapp.com
Password: TestReview123!
(This account has all premium features enabled)
(This account stays active during review)

=== Review Contact ===
Name: Jane Developer
Email: review@yourapp.com
Phone: +1 555-0100

=== Testing Instructions ===
1. Launch app and tap "Sign In"
2. Enter test credentials above
3. Navigate to "Dashboard" to see main features
4. Tap "Upgrade" to test subscription flow (sandbox mode)
5. Go to Settings > Account to see privacy policy and terms

=== Key Features to Test ===
- Workout tracking (tap "New Workout" on Dashboard)
- Progress charts (Analytics tab)
- Social sharing (Share button on workout details)
- Camera upload for profile picture (Settings > Profile)

=== Third-Party Services ===
- Firebase Authentication (for login)
- Stripe (for payments - sandbox mode)
- AWS S3 (for image uploads)
- Google Maps SDK (for location features)

=== Notes ===
- Location permission is optional, app works without it
- Camera permission only requested when uploading profile picture
- All subscription flows use Apple/Google sandbox environments
- Background location is not used
- Support URL and privacy policy are available from Settings > Account

=== Contact ===
For questions: developer@yourapp.com
Response time: Within 24 hours

iOS-spezifische Review-Notizen

Für iOS zusätzlich angeben:

=== Device Coverage ===
Tested on: iPhone 15 Pro Max, iPad Pro 13-inch

=== App Store Connect Metadata ===
Support URL: https://yourapp.com/support
Privacy Policy: https://yourapp.com/privacy-policy

=== Submission Notes ===
- iPad screenshots match the current iPad UI
- Export compliance answered for this build
- Sign in with Apple is available on the login screen

Android-spezifische Review-Notizen

Für Android auch Folgendes beachten:

=== Testing Track Information ===
Closed testing period: [Start Date] to [End Date]
Number of active testers: 23
Critical issues found during testing: 2 (both fixed)
Test distribution method: Email invite list

=== Crash Data ===
Testing period crashes: 3 total
Crash rate: 0.8%
All crashes fixed in this build

=== API Levels ===
Target SDK: 35 (Android 15)
Min SDK: 23 (Android 6.0)
Tested on: Android 11, 12, 13, 14, 15

Was tun bei einer Ablehnung?

Keine Panik – Ablehnungen sind normal, besonders beim ersten Mal. So gehst du damit um:

Schritte nach einer Ablehnung

  1. Ablehnung genau lesen

    • Die verletzte Richtlinie notieren (z. B. 4.3, 5.1.1)
    • Die Kommentare des Reviewers gründlich lesen
    • Nach bereitgestellten Screenshots suchen
  2. Das Problem verstehen

    • Die Richtlinie in der offiziellen Dokumentation nachschlagen
    • Online nach ähnlichen Fällen suchen
    • Prüfen, ob es ein Missverständnis oder ein echtes Problem ist
  3. Die Ursache beheben

    • Nicht nur patchen – richtig fixen
    • Den Fix umfassend testen
    • Dokumentieren, was geändert wurde
  4. Richtig reagieren

    Wenn die Ablehnung berechtigt ist:

    Thank you for the feedback. I have addressed the issue:
    
    Issue: Missing Sign in with Apple option
    
    Resolution: Added Sign in with Apple as a login option
    alongside Google Sign-In. The button appears on the login
    screen and follows Apple's design guidelines. You can test
    with the provided demo account or by creating a new account
    with Apple Sign-In.
    
    Changes made in: v1.0.1 (build 2)

    Wenn du es für ein Missverständnis hältst:

    Thank you for reviewing my app. I believe there may be a
    misunderstanding regarding [specific issue]:
    
    [Explain clearly with screenshots if needed]
    
    The functionality exists at: Settings > [specific location]
    
    I've added additional detail to the review notes to help
    locate this feature.
  5. Schnell neu einreichen

    • Erneute Einreichungen werden meist schneller geprüft (24–48 Std.)
    • Aktualisierte Review-Notizen zur Fehlerbehebung beifügen
    • Bei Bedarf auf die vorherige Einreichung verweisen

Häufige Antworten auf Ablehnungen

Ablehnung: „Deine App stürzt beim Start ab“

Antwort:

I sincerely apologize for the crash. I have identified and fixed
the issue:

Root cause: The app attempted to fetch data before network
initialization completed, causing a null reference exception.

Fix: Implemented proper async initialization with error handling
and offline mode. The app now gracefully handles network issues.

Testing: Verified on iPhone 12 (iOS 17), iPhone 14 Pro (iOS 17.1),
tested with WiFi, cellular, and airplane mode.

Build version: 1.0.2 (build 3)

Ablehnung: „Datenschutzerklärung fehlt“

Antwort:

Thank you for the feedback. I have added the privacy policy:

URL: https://myapp.com/privacy-policy
Location in app: Settings > Privacy Policy (tappable link)
Also added to: App Store Connect > App Information > Privacy Policy URL

The privacy policy covers all data collection as disclosed in the
Privacy Nutrition Labels.

Ablehnung: „Entspricht nicht 4.2 – Minimum Functionality“

Das ist kniffliger. Das heißt, deine App bietet zu wenig, um als App zu gelten. Lies So bestehst du 2026 das App Store Review unser komplettes Antwort-Playbook zu 4.2 und 4.3. Beispiel-Einspruchstext:

Antwort:

Thank you for the feedback. I'd like to clarify the app's
functionality:

Core Features:
1. [Feature 1 with specific details]
2. [Feature 2 with specific details]
3. [Feature 3 with specific details]

The app provides significant utility beyond a simple website by:
- Offline functionality for [specific feature]
- Native camera integration for [specific feature]
- Push notifications for [specific feature]
- Device hardware access for [specific feature]

Test account credentials have been provided to demonstrate all
features. Please let me know if you need additional clarification.

Best Practices nach der Freigabe

Glückwunsch! Deine App wurde genehmigt. So behältst du diesen Status:

Monitoring nach dem Launch

Wichtige Kennzahlen im Blick behalten:

  • Crash-Rate (unter 1 % halten)
  • ANR-Rate (Android – unter 0,5 % halten)
  • App Store/Play Store-Bewertungen
  • Review-Inhalte (auf alle Reviews antworten)
  • Von Nutzern gemeldete Bugs

Empfohlene Tools:

  • Firebase Crashlytics
  • App Store Connect Analytics
  • Google Play Console Vitals
  • Sentry oder ähnliches Error Tracking

Update-Richtlinien

Beim Einreichen von Updates:

  • So gründlich testen wie beim ersten Release
  • Screenshots aktualisieren, falls sich das UI stark verändert hat
  • Datenschutz-Labels anpassen, falls sich die Datenerfassung ändert
  • Klare „Was ist neu“-Beschreibungen bereitstellen
  • Staged Rollouts bei großen Änderungen in Betracht ziehen

Compliance sicherstellen

Jährliche Anforderungen:

  • Android Content Rating erneuern (jährlich erforderlich)
  • Update privacy policy if practices change
  • Altersfreigaben bei Inhaltsänderungen prüfen und aktualisieren
  • Drittanbieter-SDKs auf Compliance prüfen

Kontinuierliches Monitoring:

  • Über Richtlinienänderungen informiert bleiben
  • Apple/Google Developer-Newsletter abonnieren
  • An Developer-Communities teilnehmen
  • App Store/Play Store Policy-Blogs verfolgen

Ressourcen und weiterführende Links

Offizielle Dokumentation

Apple:

Google:

Community-Ressourcen

Tools für Datenschutzerklärungen

Häufig gestellte Fragen

Was sind App-Review-Guidelines?
Sie sind Apples App Store Review Guidelines und Googles Richtlinien für Entwicklerprogramme. Reviewer prüfen vor dem Release deine Binary, Metadaten, Datenschutzerklärungen und das Account-Setup.

Wie lange dauert ein App-Review im Jahr 2026?
Apple strebt an, 50 % der Einreichungen innerhalb von 24 Stunden und 90 % innerhalb von 48 Stunden zu prüfen. Google kann bei einigen Accounts bis zu sieben Tage oder länger benötigen. Neue persönliche Play Console Accounts benötigen zudem mindestens 12 Tester, die für mindestens 14 aufeinanderfolgende Tage am geschlossenen Test teilnehmen, wobei zum Zeitpunkt der Beantragung (sofern die Regel greift) noch mindestens 12 Tester dabei sein müssen.

Was sind Apples fünf Richtlinien-Bereiche?
Sicherheit, Performance, Business, Design und Rechtliches. Performance umfasst Vollständigkeit und Metadaten (inkl. 2.3). Rechtliches umfasst den Datenschutz (inkl. 5.1).

Was sollte ich vor meiner ersten Einreichung fixen?
Funktionierende Demo-Logins, HTTPS-Datenschutz- und Support-Links, ehrliche Privacy Labels, Tests auf echten Geräten und Store-Assets, die zum Build passen. Fülle den Altersfreigabe-Fragebogen in beiden Stores aus, sofern dies für deine App relevant ist.

Wo ordnen sich die Richtlinien 4.2 und 4.3 ein?
Das sind Apple Design-Ablehnungen für zu simple oder doppelte Apps. Nutze So bestehst du 2026 das App Store Review für diesen Bereich, nicht für diese Checkliste.

Was kostet die Veröffentlichung bei Apple?
Siehe Kosten für die App-Veröffentlichung im App Store für aktuelle Anmelde- und Listing-Gebühren.

Brauchst du Hilfe bei deiner App-Review?

Falls du dich überfordert fühlst oder Expertenhilfe brauchst, damit deine App beim ersten Mal durch das Review kommt: Wir sind für dich da!

Beratungstermin mit unserem Team buchen für individuelle Unterstützung bei:

  • Vorbereitung auf das App-Store- und Play-Store-Review
  • Prüfung von Datenschutzerklärung und rechtlichen Unterlagen
  • Implementierung von Sign in with Apple
  • Teststrategie und Rekrutierung von Testern
  • Vorbereitung der Review-Notizen
  • Reaktion auf Ablehnungen und Einspruch
  • Kompletter App-Submission-Prozess

Unser Team hat bereits hunderten Entwicklern geholfen, den App-Review-Prozess erfolgreich zu meistern, und kann Ihnen Wochen an Trial-and-Error ersparen.

Fazit

Die erste App einzureichen kann einschüchternd sein, aber mit der richtigen Vorbereitung bestehen Sie den Review beim ersten Versuch. Beachten Sie diese Punkte:

  1. Frühzeitig starten: Besonders für Android – rekrutieren Sie die 12 Tester mindestens 3 Wochen vor dem geplanten Launch
  2. Datenschutz zuerst: Halten Sie Ihre Datenschutzerklärung bereit, die Ihre Datenverarbeitung korrekt widerspiegelt
  3. Apple Sign-In: Wenn du Social Logins nutzt, musst du auf iOS „Sign in with Apple“ anbieten
  4. Gründlich testen: Teste auf echten Geräten, bei schlechtem Netzwerk und mit verweigerten Berechtigungen
  5. Ehrlich sein: Korrekte Metadaten und Datenschutzangaben verhindern Ablehnungen und rechtliche Probleme
  6. Detaillierte Review-Notizen: Hilf den Reviewern, deine App schnell zu verstehen

Die aktuellen Android-Testanforderungen verlängern den Prozess, führen aber letztlich zu besseren Apps und weniger Problemen nach dem Launch. Plane etwa 3–4 Wochen extra für Android-Submissions ein, um optimal aufgestellt zu sein.

Viel Erfolg beim App-Launch! Denk daran: Selbst wenn die App abgelehnt wird, ist das eine Lernchance. Die meisten erfolgreichen Apps durchlaufen mehrere Review-Runden, bevor sie freigegeben werden.

Willst du es nicht alleine angehen? Beratungstermin vereinbaren und lassen Sie sich von unseren Experten durch den Prozess begleiten.


Brauchst du Hilfe bei der Implementierung von Live Updates nach der App-Freigabe? Schau dir die live update-Lösung von Capgo für nahtlose App-Updates ohne App Store Review an.

Weiterlesen in den App Review Guidelines 2026

Wenn Sie dies verwenden App Review Guidelines Checkliste nutzt, um Security und Compliance zu planen, verbinde sie mit Verschlüsselung für die Implementierungsdetails in Encryption, Compliance für das Implementierungsdetail in Compliance, Capgo Security-Scanner für den Produkt-Workflow im Capgo Security Scanner, Capgo Sicherheit für den Produkt-Workflow in Capgo Security und Capgo Trust Center für den Produkt-Workflow im Capgo Trust Center.

Live-Updates für Capacitor-Apps

Wenn ein Bug im Web-Layer live ist, liefere den Fix über Capgo aus, statt Tage auf die App-Store-Freigabe zu warten. Nutzer bekommen das Update im Hintergrund, während native Änderungen im normalen Review-Prozess bleiben.

Neues aus unserem Blog

Capgo gibt dir die besten Insights, um eine wirklich professionelle Mobile App zu erstellen.