App-Store-Anforderungen: Was Sie vor dem Einreichen Prüfen Müssen

Ihr Launch-Datum liegt in den Händen eines Prüfers, der Ihr Produkt noch nie gesehen hat. Er kann den gesamten Build wegen eines abgelaufenen Demo-Passworts oder eines unbeantworteten Altersfreigabe-Formulars zurückschicken. App-Store-Anforderungen sind größtenteils administrativ, und diese Arbeit ist das Erste, was verrutscht, wenn ein Release eng wird. Einfache Probleme sind die, die niemand prüft. Sie vor dem Einreichen zu erkennen, ist der Zweck von App-Store-Konformitätsprüfungen.

Apples eigene App-Review-Seite sagt, dass über 40 % der ungelösten Probleme auf Richtlinie 2.1, App Completeness, zurückgehen. Die Kategorie umfasst Abstürze, Platzhalterinhalte, und alles, was leer gelassen wurde. Ihre App kann also perfekt funktionieren und trotzdem die Prüfung nicht bestehen. Die Genehmigung beginnt mit einer kurzen Liste, die nichts damit zu tun hat, wie gut Ihre App ist.

Sie benötigen eine aktive Apple-Developer-Program-Mitgliedschaft und einen vollständigen App-Store-Connect-Eintrag. Der Build selbst muss mit Xcode 26 und dem iOS-26-SDK kompiliert sein. Apple verlangt außerdem ein funktionierendes Demokonto, aktuelle Altersfreigabe-Antworten, und eine Datenschutzrichtlinie, die dem entspricht, was Ihre App sammelt.

Jeder Punkt dieser Liste ist leicht zu bestätigen, aber jeder Einzelne kann ein Release aufhalten. Dieser Artikel behandelt, was Sie vor dem Einreichen prüfen sollten, was eine Ablehnung in Kalenderzeit kostet, und wer jede Entscheidung verantworten sollte.

App-Store-Anforderungen, die Sie vor dem Einreichen Erfüllen Müssen

Zwei Apple-App-Store-Einreichungsanforderungen änderten sich 2026, und keine hat etwas mit Testen zu tun. Dennoch erwischen sie weiterhin Teams, die ihr erstes Update des Jahres einreichen. Eine machte Antworten auf Apples überarbeitete Altersfreigabe-Fragen am 31. Januar verpflichtend. Die andere verlangt, dass Sie jede Binärdatei mit Xcode 26 und dem iOS-26-SDK bauen. Sie wurde am 28. April aktiv und gilt jetzt für alle Apps.

Beide Fristen stehen auf der Seite kommender Anforderungen, und eine davon zu verpassen, stoppt Sie bereits beim Hochladen, bevor die Prüfung beginnt. Jede zu bestätigen dauert Minuten, aber niemand plant Zeit für etwas ein, das kein Feature ist.

Der dritte Punkt ist die Exportkonformität, und die hat auch nichts mit Testen zu tun. Amerikanisches Handelsrecht deckt Software ab, die Verschlüsselung verwendet, also muss Apple fragen, ob Ihre das tut. Die Wahrheit ist, dass fast jede App das tut, denn jede Verbindung über HTTPS zählt. Sie können diese Frage bei jeder Einreichung von Hand beantworten. Die Alternative ist, es einmal in der Info.plist-Konfigurationsdatei der App zu klären, wonach Apple aufhört zu fragen.

Diese drei sind Teil einer längeren Liste. Die Tabelle unten zeigt die App-Store-Anforderungen, die den Upload sperren, zusammen mit dem, wer in Ihrem Unternehmen jede tatsächlich verantwortet.

Anforderung
Wo Sie es einstellen
Wer es verantwortet
Wie erledigt aussieht
Anforderung

Developer-Program-Mitgliedschaft

Wo Sie es einstellen

developer.apple.com

Wer es verantwortet

Finanzen oder Betrieb

Wie erledigt aussieht

Aktive Mitgliedschaft, über Ihr Launch-Datum hinaus verlängert

Anforderung

App-Eintrag

Wo Sie es einstellen

App Store Connect

Wer es verantwortet

Produkt

Wie erledigt aussieht

Name, Kategorie, Support-URL, und Datenschutz-URL alle ausgefüllt

Anforderung

Build-Toolchain

Wo Sie es einstellen

Xcode

Wer es verantwortet

Engineering

Wie erledigt aussieht

Kompiliert mit Xcode 26 und dem iOS-26-SDK

Anforderung

Altersfreigabe-Antworten

Wo Sie es einstellen

App Store Connect

Wer es verantwortet

Produkt mit Recht

Wie erledigt aussieht

Aktueller Fragebogen ausgefüllt

Anforderung

Datenschutzerklärungen

Wo Sie es einstellen

App Store Connect

Wer es verantwortet

Produkt mit Recht

Wie erledigt aussieht

Jeder gesammelte Datentyp deklariert, Drittanbieter-SDKs eingeschlossen

Anforderung

Exportkonformität

Wo Sie es einstellen

Info.plist oder App Store Connect

Wer es verantwortet

Engineering

Wie erledigt aussieht

Verschlüsselungsfrage beantwortet, oder einmal im Build geklärt

Anforderung

Screenshots und Eintrag

Wo Sie es einstellen

App Store Connect

Wer es verantwortet

Marketing

Wie erledigt aussieht

Größte iPhone- und iPad-Formate geliefert, existierende Funktionen zeigend

Anforderung

EU-Händlerstatus

Wo Sie es einstellen

App Store Connect

Wer es verantwortet

Recht oder Finanzen

Wie erledigt aussieht

Verifiziert, sonst kann die App nicht in der EU vertrieben werden

Diese letzte Zeile ist ein harter Stopp, wenn Sie in der Europäischen Union verkaufen. Das Digital Services Act zwingt Apple, für jeden Entwickler, der dort eine App listet, einen verifizierten Handelsnamen und eine Adresse zu veröffentlichen. Daher wird Ihre App vollständig aus dem EU-App-Store entfernt, bis Sie Ihren liefern und Apple ihn verifiziert. Recht und Finanzen verantworten dies, nicht Engineering, also fangen Sie früh an. Eine solche Lücke gehört zu Software-Konformitätsprüfungen statt zum mobilen QA-Zyklus.

Apples App-Store-Anforderungen gehen über diese Tabelle hinaus, obwohl nur die obigen Zeilen den Upload tatsächlich blockieren. Wenn Sie den Android-Build im selben Zeitfenster ausliefern, behandelt unser Leitfaden zum Bestehen der Google-Play-Prüfung den entsprechenden Bereich.

Die Sechs Fragen, die vor dem Einreichen Zu Beantworten Sind

Diese Anforderungen zu erfüllen bringt Sie nur in die Warteschlange. Danach hängt alles davon ab, was ein Prüfer tatsächlich mit Ihrem Build anfangen kann. Suchen Sie nach einer App-Store-Einreichungs-Checkliste, und Sie finden eine, die für Ingenieure geschrieben ist. Sie listet alles auf, worauf ein Entwickler klickt, und sagt einem Geschäftsinhaber nichts darüber, ob der Launch sicher ist. Stattdessen ist die untenstehende Version um das organisiert, was Sie laut in einem Release-Meeting bestätigen können sollten.

Kann ein Fremder Ohne Ihre Hilfe in Ihre App Gelangen?

Ein Prüfer muss jede Funktion erreichen, die Sie ausliefern, und beginnt mit nichts außer Ihrem Build. Deshalb verlangt Apples Richtlinie 2.1 Demokonto-Details und ein laufendes Backend, wann immer Ihre App ein Login enthält. Die meisten Teams liefern beides, doch nur wenige bestätigen, dass die Zugangsdaten am Morgen, an dem ein Prüfer sie öffnet, noch funktionieren.

Bestätigen Sie drei Dinge:

  • Das Demokonto läuft nicht ab oder sperrt sich nach fehlgeschlagenen Versuchen.
  • Das Backend, auf das es zeigt, läuft, nicht nur bereitgestellt.
  • Notizen zur Prüfung beschreiben jede neue Funktion spezifisch, da Apple generische Formulierungen ablehnt.

Wenn rechtliche oder Sicherheitsregeln Sie daran hindern, ein Live-Konto zu übergeben, akzeptiert Apple stattdessen einen eingebauten Demomodus, mit vorheriger Genehmigung. Diese Freigabe zu bekommen braucht Zeit, die Sie einplanen müssen.

Ist der Build, den Sie Einreichen, der Build, den Sie Getestet Haben?

In vielen Fällen weichen Release-Builds von dem ab, was Sie getestet haben, auf kleine, teure Weisen:

  • Ein Feature-Flag, das eingeschaltet blieb
  • Ein Staging-Endpunkt, hart in einer Konfigurationsdatei kodiert
  • Ein In-App-Kauf, der noch auf die Sandbox zeigt

Nichts davon zeigt sich im täglichen Gebrauch, weil Ihr Team einen anderen Build betreibt. Die Bestätigung ist ein Satz: jemand installierte die exakte Binärdatei auf einem sauberen Gerät und ging den Hauptpfad Ende zu Ende durch. Das zu erreichen ist, warum mobile Anwendungstests gegen den Release-Kandidaten laufen sollten statt gegen einen früheren Branch. Das ist auch der günstigste Ort, um Stabilitätsprobleme zu finden.

Verspricht Ihr Eintrag Etwas, das der Build Nicht Tut?

Marketing schreibt den Store-Eintrag Wochen bevor Engineering den Build fertigstellt, zieht Screenshots aus Entwürfen und Beschreibungen aus der Roadmap. Dann rutscht eine Funktion, und niemand aktualisiert den Text.

Apples Richtlinie 2.3 behandelt diese Diskrepanz als ungenaue Metadaten, also lesen Sie Ihren eigenen Eintrag gegen den Build, den Sie gleich senden. Jede Behauptung braucht eine passende Funktion, die ein Prüfer ohne Anleitung erreichen kann.

Haben Sie Jede Frage Beantwortet, die Apple Jetzt Stellt?

Die Formulare in App Store Connect sind keine Formalität, und sie ändern sich häufiger, als Teams erwarten. Datenschutzerklärungen müssen insbesondere dem entsprechen, was Ihre App tatsächlich sammelt, einschließlich Daten, die von Drittanbieter-SDKs eingezogen werden, die Sie nicht geschrieben haben. Niemand in Ihrem Team weiß vielleicht, was diese Bibliotheken übertragen, weshalb dies Prüfung statt Erinnerung braucht.

Künstliche Intelligenz (KI) ist der neueste Bereich, den Apple verschärft hat. Richtlinie 5.1.2(i) verlangt, jegliche persönlichen Daten offenzulegen, die Sie an eine Dritt-KI senden. Sie brauchen auch ausdrückliche Erlaubnis, bevor sie sich bewegen, was wir in den Apple-Richtlinien zum KI-Datenaustausch behandelt haben.

Können Nutzer in Ihrer App Löschen, Wiederherstellen, und Melden?

Manche Anforderungen betreffen, was Ihre App tut, nicht was Sie darüber sagen. Jedes Produkt, das eine Anmeldung unterstützt, muss auch Kontolöschung in der App anbieten. Käufe müssen wiederherstellbar sein, und jeder davon muss für den Prüfer sichtbar sein. Apps, die Nutzern das Veröffentlichen von Inhalten erlauben, müssen allen die Möglichkeit geben, einen Beitrag zu melden und dessen Autor zu blockieren.

Ein Prüfer wird jedes davon ausprobieren, testen Sie sie also genauso auf dem ausgelieferten Build. Löschung birgt die meisten Randfälle, also planen Sie Zeit dafür ein.

Wer Verantwortet die Antwort, Wenn Sie Zurückkommt?

Dies ist die Frage, die Geschäftsinhaber überspringen, und sie kostet die meiste Kalenderzeit. Eine Ablehnung kommt im Resolution Center von Apple an, dem Ihrer Einreichung angehängten Nachrichtenthread, mit einer Richtliniennummer und einer kurzen Erklärung. Dann muss jemand sie lesen, entscheiden, ob eine Metadaten-Änderung oder ein neuer Build nötig ist, und antworten.

Benennen Sie diese Person vor dem Einreichen, fügen Sie eine Vertretung hinzu, und prüfen Sie, dass keine der beiden während des Prüfungsfensters im Urlaub ist. Jede Stunde, in der diese Antwort ungelesen bleibt, schiebt Ihr Launch-Datum zurück.

Möchten Sie wissen, was ein Prüfer zurücksenden würde?

Zuerst prüfen

Was eine Fehlgeschlagene Einreichung Ihren Launch Kostet

Eine Ablehnung ist kein Engineering-Ticket, sondern eher ein Geschäftsereignis mit einer Rechnung dabei. Der Großteil der Kosten landet bei Leuten, die die Richtlinien nie lesen. Apple klärt 90 % der Einreichungen in weniger als 24 Stunden, ein sauberer Build bewegt sich also schnell. Die zweite Prüfung beginnt jedoch erst, sobald Ihre Korrektur bereit ist, und diese Wartezeit ist es, die Sie Tage kostet. Die Tabelle unten zeigt, was verrutscht und wer es abfängt.

Was verrutscht
Wer es abfängt
Was es kostet
Was verrutscht

Das Launch-Datum

Wer es abfängt

Produkt und Führung

Was es kostet

Neuplanung, plus alles, was drumherum gebucht war

Was verrutscht

Ein bezahlter Akquise-Flight

Wer es abfängt

Marketing

Was es kostet

Umbuchungsgebühren, oder Abschreibung der Ausgaben

Was verrutscht

Eine einem Kunden versprochene Funktion

Wer es abfängt

Vertrieb und Support

Was es kostet

Ein Gespräch, das niemand geplant hat

Was verrutscht

Das nächste Release in der Warteschlange

Wer es abfängt

Engineering

Was es kostet

Verzögerung, weil das Team stattdessen bei der Behebung ist

Was verrutscht

Eine weitere Runde durch die Prüfung

Wer es abfängt

Alle

Was es kostet

Bestenfalls 24 Stunden, sobald der neue Build bereit ist

Was verrutscht

Aufmerksamkeit der Führungsebene

Wer es abfängt

Führung

Was es kostet

Stunden, die von dem abgezogen werden, was der Launch ermöglichen sollte

Wie lange das dauert, hängt davon ab, was kaputt war. Eine Screenshot- oder Beschreibungskorrektur ist ein Nachmittag Arbeit, dann eine frische Prüfung. Code-Änderungen brauchen zuerst Regressionstests, wodurch aus einem kleinen Bug eine Woche Verzögerung wird.

Der günstigste Weg, diese Schleife zu verkürzen, ist zu wissen, was sie üblicherweise auslöst. Wir listen die häufigen Ursachen in Gründen für die Ablehnung im App Store auf, dem Artikel, den Sie öffnen sollten, wenn Ihre Einreichung bereits zurückgekommen ist.

Wo Vorab-Prüfungen Meist Scheitern

Teams machen das auf zwei entgegengesetzte Arten falsch:

  • Die erste ist, die iOS-App-Einreichungs-Checkliste als einmaliges Ereignis zu behandeln. Sie führen sie gründlich vor dem ursprünglichen Launch durch, überspringen sie dann bei Updates, genau dann, wenn sich die Plattform unter ihnen verschoben hat. Apples Regeln änderten sich allein in den ersten 4 Monaten von 2026 zweimal.
  • Die zweite ist, die falsche Ebene zu übertesten. Barrierefreiheit ist das klarste Beispiel, da sie selten eine App-Store-Prüfung blockiert. Teams ignorieren sie deshalb entweder oder behandeln sie als Einreichungssperre, und beide Lesarten verfehlen den Punkt. Der echte Druck kommt vom European Accessibility Act und den Nutzern, die Sie still verlieren. Das setzt mobile Barrierefreiheitstests auf den Release-Plan statt auf das Einreichungsformular.

App-Store-Anforderungen früh zu prüfen dauert eine Stunde, plus eine Kalendererinnerung für die langsameren. Dieselben Lücken während der Prüfung zu finden, kann Sie das Launch-Datum kosten.

Wie QAwerk einen iOS-Build vor der Einreichung Verifiziert

Wir testen Ihren tatsächlichen Release-Kandidaten, nicht eine Beschreibung davon. Das bedeutet, die App-Store-Review-Checkliste gegen die exakte Binärdatei auszuführen, installiert auf echten Geräten. Unsere Ingenieure absolvieren die Anmelde-, Kauf-, Wiederherstellungs-, und Löschflüsse, und vergleichen dann Ihren Eintrag mit dem, was der Build tatsächlich tut.

Sie erhalten einen schriftlichen Bericht darüber, was fehlschlagen könnte und warum, wobei jeder Punkt an die berührte Richtlinie geknüpft ist. Genau das taten wir für BeFamily, indem wir vor dem Launch mehr als 500 Testfälle über 9 Geräte hinweg ausführten. Die App hatte seitdem keine größeren Probleme in Produktion. Bringen Sie uns ein, während sich das Einreichungsdatum noch verschieben lässt, und es gibt Raum, das zu beheben, was wir finden, ohne einen Notfall-Sprint.

QAwerk testet seit 2015 mobile Releases, und wir steigen ein, in welcher Phase auch immer sich Ihr Projekt befindet. Ihr Launch-Datum ist das Einzige, das Sie nicht zurückbekommen, also sprechen Sie mit uns, und lassen Sie uns finden, was Apple beanstanden könnte.

FAQ

Wie lange dauert es, eine abgelehnte App-Store-Einreichung zu korrigieren?

Das hängt davon ab, welche App-Store-Anforderungen Sie verfehlt haben. Metadatenprobleme wie ein Screenshot oder eine Beschreibung nehmen ein paar Stunden in Anspruch, dann eine neue Prüfung, die Apple normalerweise innerhalb eines Tages zurückgibt. Code-Korrekturen dauern länger, weil die neu gebaute App zuerst Regressionstests braucht. Planen Sie für den langsameren Fall, da Sie erst nach der Rückmeldung wissen, welchen Sie vor sich haben.

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

Apple prüft 90 % dessen, was es erhält, in weniger als 24 Stunden. Erste Einreichungen von einem neuen Entwicklerkonto sitzen oft länger, ebenso Apps in sensiblen Kategorien. Planen Sie 1 bis 3 Tage ein statt einer Genehmigung am selben Tag, und planen Sie nie ein Launch-Event um eine 24-Stunden-Bearbeitungszeit herum.

Brauchen Sie ein Demokonto, wenn Ihre App kein Login hat?

Sie brauchen keines, denn Apple fragt nur nach Demo-Zugangsdaten, wenn Ihre App ein Login enthält. Das Feld Notizen zur Prüfung zählt trotzdem, indem es jede Funktion beschreibt, die aus der Oberfläche nicht offensichtlich ist, da generische Formulierungen abgelehnt werden. Ohne Zugangsdaten öffnet, wer auch immer Ihre Einreichung übernimmt, einfach das Produkt und arbeitet sich unbegleitet durch.

Können Sie Apple bitten, Ihre App schneller zu prüfen?

Sie können, obwohl nur zwei Situationen für eine beschleunigte Prüfungsanfrage qualifizieren. Die erste ist ein kritischer Fehler, der Nutzer in Produktion betrifft, und die zweite ist eine App, die an ein festes öffentliches Datum gebunden ist. Liefern Sie Reproduktionsschritte für den Fehler, oder Namen und Datum der Veranstaltung. Die Genehmigung wird individuell entschieden und ist nie garantiert, planen Sie also nicht darauf.

Sollten Sie eine Ablehnung anfechten oder korrigieren und erneut einreichen?

Korrigieren und erneut einreichen, wenn Apple recht hat, was meistens der Fall ist. Fechten Sie es beim App Review Board an, wenn Sie glauben, dass die Richtlinie falsch angewendet wurde. Apple erlaubt einen Einspruch pro nicht bestandener Einreichung und erwartet, dass Sie zuerst jede Anfrage nach weiteren Informationen beantworten. Einen echten Verstoß anzufechten kostet Sie nur Tage.

Sehen Sie, wie eine iOS-App kritische Bugs, Abstürze, und UX-Lücken vor der Einreichung behob, und ohne kostspielige Nacharbeit launchte

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail