Checkliste für die App-Store-Einreichung (2026): vom Xcode-26-Build bis „Submit for Review“

Eine Checkliste für die App-Store-Einreichung listet alles auf, was gleichzeitig fertig sein muss, bevor du einreichst: ein funktionierender Build, ein korrekter Store-Eintrag, wahrheitsgemäße Datenschutzangaben und genug Kontext, damit ein Reviewer deine App nutzen kann. Ein grüner Build allein reicht nicht. Die sechs Abschnitte unten folgen der Reihenfolge, in der App Store Connect danach fragt, und jeder beginnt mit einer kurzen Antwort, nach der du direkt handeln kannst.

Was braucht eine App-Store-Einreichung, bevor du auf Submit klickst?

Eine App-Store-Einreichung braucht einen verarbeiteten Build, der der Version zugeordnet ist, die Pflicht-Metadaten der Version, Screenshots, eine Datenschutzerklärung, Kontaktdaten für App Review und, falls die App einen Login hat, funktionierende Demo-Zugangsdaten. Apples eigene Liste „Before You Submit“ in den App Review Guidelines ergänzt zwei weitere Punkte: „Aktiviere Backend-Dienste, damit sie während des Reviews live und erreichbar sind“, und erkläre nicht offensichtliche Funktionen in den Review-Notizen.

Welche Account- und App-Eintrag-Einstellungen müssen bereit sein?

Du brauchst eine aktive Mitgliedschaft im Apple Developer Program, einen App-Eintrag, dessen Bundle-ID zu deinem signierten Build passt, und jemanden im Team mit der Rolle Account Holder, Admin oder App Manager. Genau diese Rollen verlangt Apples Seite Submit an app für das Einreichen.

Beim Anlegen des Eintrags wählst du Name, Hauptsprache und SKU. Die SKU ist intern, Kunden sehen sie nie. Wenn du eine kostenpflichtige App oder In-App-Käufe verkaufst, schließe zuerst die Vereinbarungen für kostenpflichtige Apps sowie die Steuer- und Bankangaben ab. Eine nicht unterschriebene Vereinbarung kann einen kommerziellen Launch aufhalten, selbst wenn der Build in Ordnung ist.

Welche Build-Anforderungen gelten 2026 für App-Store-Uploads?

Stand Oktober 2026 heißt es auf Apples Seite Upcoming requirements: „In App Store Connect hochgeladene Apps müssen mit Xcode 26 oder neuer und einem SDK für iOS 26, iPadOS 26, tvOS 26, visionOS 26 oder watchOS 26 erstellt werden“ (seit dem 28. April 2026). Außerdem heißt es dort, dass iOS- und iPadOS-Apps „iOS 13 oder neuer als Ziel haben müssen“ (seit dem 9. September 2026).

• Erhöhe bei jedem Upload die Build-Nummer und achte darauf, dass die Versionsnummer zu dem Release passt, das du ausliefern willst.
• Aktualisiere das Xcode-Image in der CI (Codemagic, Expo EAS, GitHub Actions usw.) ebenso wie auf deinem eigenen Rechner.
• Beantworte nach der Verarbeitung eventuelle Fragen zur Exportkonformität und ordne den verarbeiteten Build der Version zu.
• Installiere den TestFlight-Build auf einem echten Gerät. Teste Onboarding, Anmeldung, Offline-Zustände, Käufe und das Wiederherstellen von Käufen. Ein erfolgreicher Lauf im Simulator beweist nicht, dass der verteilte Build funktioniert.
• Lies die E-Mail, die App Store Connect nach dem Upload schickt. ITMS-Warnungen zu Privacy Manifests oder SDK-Versionen werden zu Blockern, wenn du sie ignorierst.

Richtlinie 2.1(a) sagt unmissverständlich, was sonst passiert: „Wir lehnen unvollständige App-Bundles und Binaries ab, die abstürzen oder offensichtliche technische Probleme aufweisen.“ Entferne Platzhalter-Bildschirme, Debug-Menüs und tote Links, bevor du archivierst. Unser Testplan für Release-Builds nach 2.1 geht diese Prüfungen im Detail durch.

Welche Screenshots und Metadaten verlangt App Store Connect?

Stand Oktober 2026 verlangen Apples Screenshot-Spezifikationen mindestens einen Screenshot für „iPhone with Dynamic Island (medium display)“, zum Beispiel 1206 × 2622 oder 1179 × 2556 im Hochformat. Apps, die auf dem iPad laufen, brauchen außerdem mindestens einen Screenshot für das 13-Zoll-iPad, etwa 2064 × 2752 oder 2048 × 2732.

Du „kannst bis zu 10 Screenshots pro Gerätegröße in den Formaten .jpeg, .jpg oder .png hochladen“, und „Bilder dürfen keine Alphakanäle oder Transparenzen enthalten.“ Wenn deine Oberfläche auf allen Größen gleich ist, lade nur die höchste geforderte Auflösung hoch, und App Store Connect skaliert sie herunter. Richtlinie 2.3.3 besagt, dass Screenshots „die App in Benutzung zeigen sollen und nicht bloß die Titelgrafik, die Login-Seite oder den Splash-Screen.“

• Schreibe eine Beschreibung, die sagt, für wen die App ist und was man in der ersten Sitzung damit tun kann.
• Halte Name, Untertitel und Keywords relevant. Wiederhole keine Keywords und verwende keine Namen von Wettbewerbern.
• Stelle sicher, dass Support-URL und URL der Datenschutzerklärung ohne Login laden.
• Beantworte den Fragebogen zur Altersfreigabe danach, was die App tatsächlich enthält und kann.
• Zeige in den Screenshots den aktuellen Build, einschließlich einer Paywall, auf die Nutzer stoßen.

Wie bringst du die Datenschutzangaben mit der App in Einklang?

Damit die Datenschutzangaben zur App passen, liste jedes SDK auf, das du mitlieferst, und welche Daten es erhebt. Nutze diese Liste dann, um App Privacy auszufüllen, die Datenschutzerklärung zu schreiben und das Verhalten in der App einzurichten. Richtlinie 2.3 besagt, dass deine Metadaten, „einschließlich der Datenschutzinformationen“, die App korrekt widerspiegeln müssen.

Richtlinie 5.1.1(i) lautet: „Alle Apps müssen einen Link zu ihrer Datenschutzerklärung im Metadatenfeld von App Store Connect und leicht zugänglich in der App enthalten.“ Richtlinie 5.1.1(v) ergänzt: „Wenn deine App das Anlegen eines Kontos unterstützt, musst du auch die Kontolöschung in der App anbieten.“ Analytics-, Crash-Reporting-, Werbe- und Login-SDKs ändern deine Angaben meistens, also prüfe sie mit unserem Privacy-Labels-SDK-Audit. Prüfe außerdem, dass deine App und jedes eingebundene SDK ein PrivacyInfo.xcprivacy Privacy Manifest mitliefern, das alle verwendeten Required-Reason-APIs abdeckt.

Was gehört in die App Review Information?

Die App Review Information sollte einen Kontakt enthalten, der auch antwortet, Demo-Zugangsdaten, die funktionieren und nicht ablaufen, und Notizen, die den Reviewer direkt zu deinen Kernfunktionen führen. Richtlinie 2.1(a) verlangt, „Demo-Account-Informationen anzugeben (und deinen Backend-Dienst einzuschalten!), wenn deine App einen Login hat“; ein eingebauter Demo-Modus anstelle eines Accounts braucht Apples vorherige Genehmigung.

Hier ein ausgearbeitetes Beispiel für Review-Notizen: „Melden Sie sich mit dem bereitgestellten Review-Account an. Öffnen Sie Library, wählen Sie das Beispielprojekt und tippen Sie auf Export. Für den Account sind alle Premium-Funktionen freigeschaltet. Standortfunktionen nutzen eine simulierte Stadt, Sie müssen also nicht reisen.“ Schicke Reviewer nicht in einen leeren Account, zu einem ablaufenden Einmalcode oder in einen Ablauf, der nur funktioniert, solange du online bist und ihn freigibst. Unsere Anleitung zum Einrichten eines Demo-Accounts zeigt, wie du einen belastbaren Reviewer-Login baust.

Wie reichst du eine App in App Store Connect zur Prüfung ein?

Um eine App zur Prüfung einzureichen, ordnest du den Build der Version zu, klickst auf „Add for Review“ und dann auf „Submit for Review“. „Add for Review“ allein schickt nichts an Apple. Die folgende Abfolge entspricht Apples Seite „Submit an app“ mit Stand Oktober 2026.

1. Wähle unter Apps die App aus und klicke dann in der Seitenleiste auf die App-Version.
2. Scrolle zum Abschnitt Build und prüfe, ob der richtige Build zugeordnet ist.
3. Wähle im Abschnitt App Store Version Release die manuelle Veröffentlichung, wenn du den Launch-Tag selbst bestimmen willst, und klicke dann auf Save.
4. Klicke auf „Add for Review“ und wähle einen bestehenden Entwurf einer Einreichung oder lege einen neuen an. Der Status wechselt zu „Ready for Review“.
5. Klicke auf „Submit for Review“. Sobald das Review beginnt, wechselt der Status zu „In Review“.
6. Speichere eine Kopie der eingereichten Metadaten und Notizen und behalte die E-Mail-Adresse des Review-Kontakts im Blick, falls Rückfragen kommen.

Wenn die Einreichung abgelehnt zurückkommt, lies die Nummer der Richtlinie und die Erklärung des Reviewers, bevor du irgendetwas änderst. Manche Korrekturen betreffen nur die Metadaten. Andere brauchen einen neuen Build. Unser Leitfaden zu App-Store-Ablehnungen zeigt, wie du erkennst, welcher Fall bei dir vorliegt.

Was ist bei anderen Entwicklern bei der Einreichung schiefgelaufen?

In beiden öffentlichen Fällen unten funktionierte die App für ihren Entwickler, und das Problem zeigte sich erst im hochgeladenen Build oder in der ersten Sitzung des Reviewers.

Ein Entwickler im Adalo-Forum erhielt eine Ablehnung nach Richtlinie 2.1: „Wir konnten uns mit den von Ihnen angegebenen Demo-Account-Zugangsdaten nicht anmelden.“ Die Zugangsdaten waren gültig, aber das erste Tippen auf Login bewirkte nichts, erst ein zweites Tippen funktionierte, weil am Login-Button eine bedingte Navigation lief, bevor die Nutzersitzung registriert war. Die Lösung: Der Login-Button führte zu einem leeren Übergangsbildschirm, der die bedingten Aktionen enthielt. Danach wurde die App erneut eingereicht.

Ein Entwickler im JUCE-Forum erhielt nach einem Upload „ITMS-91053: Missing API declaration“ mit dem Hinweis, dass neue Uploads „ein NSPrivacyAccessedAPITypes-Array im Privacy Manifest der App enthalten müssen.“ Beanstandet wurden die Kategorien SystemBootTime und FileTimestamp, ein anderer Nutzer meldete UserDefaults. Die Lösung war eine PrivacyInfo.xcprivacy-Datei mit zulässigen Reason-Codes, die als Xcode-Ressource hinzugefügt wurde. In der ersten Version eines Nutzers fehlte ein Type-Key, was ITMS-91056 für ein ungültiges Manifest auslöste, bis er es korrigierte.

Beide Entwickler hatten nur in ihrer eigenen Umgebung getestet. Teste den Build, den Apple tatsächlich erhält, mit einem frischen Login und lies jede E-Mail nach dem Upload, bevor du auf „Submit for Review“ klickst. Wenn du möchtest, dass jemand Zweites über dein Paket schaut, sieh dir unsere Einreichungs-Services an.