# iOS-Update veröffentlichen: phasenweise Veröffentlichung > iOS-Update veröffentlichen: neue Version, neuer Build, „Neuerungen“-Text, dann manuelle, automatische oder phasenweise Veröffentlichung über 7 Tage. Originalseite: [iOS-Update veröffentlichen: phasenweise Veröffentlichung](https://devoria.fr/de/blog/ios-update-veroeffentlichen-phasenweise-veroeffentlichung) Autor: [Mehdi Azizi](https://devoria.fr/de/mehdi-azizi) Veröffentlicht: 2026-11-04 Letzte inhaltliche Überarbeitung: 2026-11-04 Um ein iOS-Update zu veröffentlichen, legst du in App Store Connect eine neue Version mit einer höheren Nummer an. Du hängst einen neuen Build an, schreibst den Text „What's New“ und schickst die Version an App Review. **Jede neue Version geht wieder durch Apples Prüfung, auch ein einfacher Bugfix.** Vor dem Einreichen legst du fest, wie sie nach der Freigabe erscheint: von Hand, sofort, nicht vor einem bestimmten Datum oder als phasenweise Veröffentlichung über 7 Tage. Die phasenweise Veröffentlichung betrifft nur automatische Updates: 1 % dieser Nutzer am ersten Tag, alle am siebten. Du kannst sie insgesamt bis zu 30 Tage pausieren oder auf einen Schlag abschließen. Dieser Guide folgt Apples Hilfeseiten, zuletzt geprüft am 3. November 2026. Ich veröffentliche die Updates meiner iOS-Apps mit Expo und EAS, darunter Solys, TradaZen und Nolera. Die Fälle weiter unten stammen aus diesen Releases. ## iOS-Update veröffentlichen: die Schritte der Reihe nach [Die App-Store-Connect-Hilfe zu neuen Versionen](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version) beschreibt diesen Ablauf: 1. Wähl unter Apps deine App aus und klick dann auf den +-Button neben der Plattform. 2. Gib eine Versionsnummer ein, die höher ist als die vorherige, und klick auf Create. 3. Prüf die Metadaten: Die der aktuellen Live-Version werden automatisch übernommen. 4. Lade einen neuen Build mit erhöhter Build-Nummer hoch. 5. Teste diesen Build in [TestFlight](https://devoria.fr/de/blog/testflight-iphone-app-testen), füg ihn der Version hinzu und reich sie bei App Review ein. Zwei Voraussetzungen, bevor du loslegst. Die Live-Version muss den Status Ready for Distribution haben. Und du brauchst eine dieser Rollen: Account Holder, Admin, App Manager oder Marketing. **Es gibt kein Zurück.** Apple schreibt es auf derselben Seite: Wenn eine Version Probleme macht, kannst du nicht zur vorherigen zurückkehren. Du musst eine neue Version erstellen und einreichen. ## Versionsnummer und Build-Nummer Die Version ist die Nummer, die deine Kunden auf deiner Produktseite sehen. Der Build kennzeichnet jeden Upload. **Die Kombination aus Version und Build muss eindeutig sein**: Die Regeln und die zugehörigen Fehler findest du unter Version und Build-Nummer. Meine Konvention, keine Regel von Apple: Die letzte Ziffer steigt bei einem Bugfix, von 1.4.0 auf 1.4.1. Die mittlere steigt bei einer neuen Funktion, von 1.4.1 auf 1.5.0. Die Build-Nummer steigt immer nur, von Version zu Version. Bei Expo steht die Version in `app.json`, und EAS kann den Build bei jedem Production-Build hochzählen. Wie du das einrichtest, steht in [eine Expo-App mit EAS veröffentlichen](https://devoria.fr/de/blog/eas-submit-ios-expo-app-app-store-veroeffentlichen). ## Der Text „What's New“: was Apple verlangt [Die Seite zu den Versionsinformationen](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information) beschreibt das Feld What's New in This Version: - **Höchstens 4.000 Zeichen.** - **Gibt es bei der ersten Version nicht, ist bei allen folgenden Pflicht.** - **In jede Sprache deiner Produktseite übersetzbar.** Regel 2.3.12 der [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#2.3.12) stellt eine weitere Anforderung: neue Funktionen und Produktänderungen klar beschreiben. Für einfache Bug-, Sicherheits- oder Performance-Fixes reicht eine allgemeine Formulierung. **Eine wichtige Änderung muss aufgeführt werden.** „Fehlerbehebungen und Verbesserungen“ reicht also nicht für eine Version, die dein Abo oder deinen Hauptbildschirm verändert. Apple empfiehlt außerdem auf [seiner Seite zu Bewertungen](https://developer.apple.com/app-store/ratings-and-reviews/), in den Notes behobene Probleme zu erwähnen, die Kunden in ihren Rezensionen beschrieben hatten. Hier drei Vorlagen zum Anpassen, eine pro Versionstyp. Für einen Bugfix: ```text Fehlerbehebungen und Stabilität. - [Funktion]: [was nicht funktionierte] ist behoben. - [Bildschirm] lädt schneller. Danke an alle, die es gemeldet haben. ``` Für eine neue Funktion: ```text Neu: [die Funktion, in fünf Wörtern]. [Was du jetzt tun kannst, in einem Satz.] So findest du sie: [Tab] > [Button]. Außerdem in dieser Version: - [Sichtbare Verbesserung]. - Fehlerbehebungen. ``` Für einen geänderten Ablauf: ```text [Bildschirm oder Ablauf] ändert sich. - Was sich für dich ändert: [konkrete Auswirkung]. - Was du behältst: [Daten, Einstellungen, Kauf]. Fragen? [Einstellungen] > [Hilfe]. ``` Die letzte Zeile der Bugfix-Vorlage gilt nur, wenn jemand das Problem wirklich gemeldet hat. Schreib nie eine Neuerung, die nicht im Build steckt: Regel 2.3 verlangt Metadaten, die der App entsprechen. ## Manuelle, automatische oder terminierte Veröffentlichung [Die Hilfe zu den Veröffentlichungsoptionen](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) bietet drei an: | Option | Nach Apples Freigabe | | ----------------------------- | -------------------------------------------------------------------- | | Manuell | Status Pending Developer Release, du veröffentlichst, wann du willst | | Automatisch | Die Version erscheint sofort nach der Freigabe | | Automatisch, nicht vor dem... | Sie wartet bis zum gewählten Datum und erscheint dann von selbst | Bei manueller Veröffentlichung öffnest du die Version mit dem Status Pending Developer Release, klickst auf Release This Version und bestätigst. Apple weist darauf hin, dass es bis zu 24 Stunden dauern kann, bis sie im App Store erscheint. Eine Meldung auf der Versionsseite bietet Cancel This Release zum Abbrechen an. Bleibt die Version länger als 30 Tage in der Warteschleife, schickt dir Apple eine Erinnerung per E-Mail. **Die manuelle Veröffentlichung dient dazu, den Zeitpunkt selbst zu wählen**, zum Beispiel, um am Tag einer Ankündigung zu veröffentlichen. Solys 2.0.0, mit einer neuen Version des Jahresabos, ging Ende September 2026 mit manueller Veröffentlichung in die Prüfung. Für eine Routine-Version lasse ich die automatische Veröffentlichung eingestellt. Nolera 1.0.2, freigegeben am 12. Oktober 2026, war laut der öffentlichen iTunes-Such-API weniger als eine Minute nach Apples E-Mail im App Store. Das ist eine einzelne Beobachtung: Plan lieber großzügig. ## Die phasenweise Veröffentlichung über 7 Tage [Apples Hilfe zur phasenweisen Veröffentlichung](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases) nennt den genauen Zeitplan: | Tag | Anteil der Nutzer | | --- | ----------------- | | 1 | 1 % | | 2 | 2 % | | 3 | 5 % | | 4 | 10 % | | 5 | 20 % | | 6 | 50 % | | 7 | 100 % | Das Update geht an eine zufällige Stichprobe der Nutzer, die automatische Updates aktiviert haben, auf kompatiblen Geräten. Sie erfahren nicht, dass sie dazugehören. **Die phasenweise Veröffentlichung bremst nur automatische Updates.** Apple stellt klar, dass jeder die neue Version jederzeit aus dem App Store laden kann. Wer deine App installiert oder auf deiner Produktseite auf „Aktualisieren“ tippt, kann sie also schon am ersten Tag haben. Das ist kein Test mit 1 % deiner Nutzer: Es ist eine Bremse für alle anderen. Zum Aktivieren öffnest du die Version, scrollst zum Abschnitt Phased Release for Automatic Updates, setzt den Haken bei „Release update over a 7-day period using phased release“ und speicherst. Du brauchst die Rolle Account Holder, Admin oder App Manager. Die Option bleibt bis zum Status Pending Developer Release verfügbar: **Du kannst sie auch nach Apples Freigabe noch aktivieren, solange die Version auf deine manuelle Veröffentlichung wartet.** Sobald die Version freigegeben ist, trägt ihr Status Ready for Distribution den Zusatz „Phased Release“. Nach den 7 Tagen bekommen die Admins und App Manager der App eine Benachrichtigung. ### Pausieren, fortsetzen und für alle veröffentlichen - **Pause**: insgesamt bis zu 30 Tage, so oft du willst. Eine Pause von 10 Tagen lässt 20 Tage für die folgenden. - **Fortsetzen**: Die Veröffentlichung geht an dem Tag weiter, an dem du sie angehalten hast. - **Für alle veröffentlichen**: Der Button Release to All Users oben rechts in der Version schickt das Update an alle Geräte mit automatischen Updates. - **Aus dem Verkauf nehmen**: Das stoppt die Veröffentlichung endgültig, auch wenn deine Mitgliedschaft im Developer Program abläuft. Kommt die App wieder in den Verkauf, ist die Version sofort für alle verfügbar. Nach der Veröffentlichung für alle lässt sich nichts mehr einstellen, so [die Tabelle der bearbeitbaren Eigenschaften](https://developer.apple.com/help/app-store-connect/reference/app-information/required-localizable-and-editable-properties). Nolera 1.0.2 ist ohne phasenweise Veröffentlichung erschienen. So würde ich sie während der Woche nutzen: | Was du siehst | Was du tust | Was passiert | | -------------------------------------- | ------------------------ | ------------------------------------------------- | | Abstürze oder besorgte Bewertungen | Pause | Die automatischen Updates stoppen | | Der Fix ist fertig | Neue Version | Sie geht erneut in die Prüfung, mit eigener Phase | | Nach 3 oder 4 Tagen nichts Auffälliges | Release to All Users | Alle bekommen sie | | Du wartest auf eine Antwort von Apple | Pause, insgesamt 30 Tage | Fortsetzung an dem Tag, an dem du angehalten hast | Während einer Pause laufen manuelle Downloads weiter. **Aktiviere die phasenweise Veröffentlichung für jede Version, die die Bezahlung oder den ersten Start betrifft**: Dort kostet ein Fehler am meisten, und du kannst nicht zurück. ## Wenn der Fix dringend ist: die beschleunigte Prüfung Apple erlaubt es, eine [beschleunigte Prüfung](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review) zu beantragen. Sie ist echten Notfällen vorbehalten: einem kritischen Bug, der behoben werden muss, oder einem Release, das an ein Event gebunden ist. 1. Reich zuerst deine Version ein. Beschreib den Bug im Feld Notes für den Reviewer. 2. Füll das Formular für die beschleunigte Prüfung aus und wähl deine App und ihre Plattform. 3. Apple beschleunigt die Prüfung je nach Kapazität. Garantiert ist nichts. Gib bei einem Event in den Notes das Datum und deine Verbindung dazu an. Die üblichen Wartezeiten stehen in [die Prüfdauer im App Store](https://devoria.fr/de/blog/app-store-review-dauer). ## Was erneut geprüft wird und was nicht | Änderung | Was nötig ist | | ----------------------------------------------- | -------------------------------------------------- | | Nativer Code, Berechtigungen, SDK-Version | Neuer Build, neue Version, vollständige Prüfung | | Screenshots, Beschreibung, Keywords, Neuerungen | Eine neue Version, mit ihr geprüft | | Werbetext | Nichts: Er ändert sich ohne neue Einreichung | | Pause, Fortsetzen, für alle veröffentlichen | Nichts: Das sind Veröffentlichungseinstellungen | | Header der Produktseite unter iOS 27 | Allein in der Asset Library oder mit einer Version | | JavaScript-Fix, mit Expo | Ein Remote-Update ist möglich | Der Werbetext ändert sich laut der Seite zu den Versionsinformationen ohne neue Einreichung. Mit Expo ändert ein Remote-Update JavaScript, Texte und Bilder, ohne über den App Store zu gehen. [Die Expo-Dokumentation](https://docs.expo.dev/eas-update/introduction/) setzt zwei Grenzen: Nativer Code, Berechtigungen und die SDK-Version erfordern ein neues Binary, und die Updates müssen die Regeln des App Store einhalten. ### Mein Fall: ein Remote-Fix, den der Reviewer nie gesehen hat Im September 2026 wartete ein Build von Nolera auf die Prüfung. Ich hatte einen Fehler im Scan-Bildschirm behoben und diesen Fix während der Wartezeit als Remote-Update veröffentlicht. Der Build wurde trotzdem abgelehnt, wegen genau diesem bereits behobenen Fehler. Die Erklärung steht in [der Dokumentation von expo-updates](https://docs.expo.dev/versions/latest/sdk/updates/): Standardmäßig lädt die App das Update beim Start herunter und wendet es beim nächsten Start an. Der Reviewer installiert die App, startet sie einmal und testet den Code, der im Build steckt. **Dieselbe Regel gilt für deine neuen Nutzer: Ihre erste Sitzung läuft mit dem Code des Builds.** Seitdem geht jede Änderung am Startbildschirm, an der Paywall oder an der Hauptfunktion in einen neuen Build. Das Remote-Update dient nur Leuten, die die App schon haben. ## Die Bewertung mit einer Version zurücksetzen Jede neue Version bietet die Option Reset rating when this version is released. Laut [Apples Hilfe zum Zurücksetzen](https://developer.apple.com/help/app-store-connect/monitor-ratings-and-reviews/reset-an-app-overview-rating) gilt sie für alle Länder, behält die geschriebenen Rezensionen und lässt sich nach der Veröffentlichung nicht rückgängig machen. Apple rät, sie sparsam einzusetzen, weil eine Produktseite mit wenigen Bewertungen abschrecken kann. ## Die Checkliste vor dem Einreichen deines Updates - Die Versionsnummer ist höher, der Build ist hochgezählt. - Der Build ist in TestFlight getestet, auf einem kleinen iPhone und auf dem iPad, falls deine App dort läuft. - Die Neuerungen sind in jeder Sprache geschrieben, und wichtige Änderungen sind aufgeführt. - Die Screenshots zeigen die aktuelle Oberfläche, falls sie sich geändert hat. - Die Notes für den Reviewer sagen, was sich geändert hat und wo man es findet. - Die Veröffentlichungsoption ist gewählt: manuell, wenn du ein Datum einhalten musst. - Die phasenweise Veröffentlichung ist aktiviert, wenn die Version die Bezahlung oder den ersten Start betrifft. - Du weißt, ob ein eventueller Fix per Remote-Update rausgehen kann oder einen Build braucht. ## Die Prüfung bei jedem Update bestehen Jedes Update geht wieder durch App Review, und eine Ablehnung blockiert deinen Fix. Das [Review Kit](https://devoria.fr/de/kits/app-review) bündelt meine Checkliste vor dem Einreichen, meine behobenen Ablehnungen und zwei Claude-Code-Skills, die dein Projekt und deine Produktseite prüfen und deine Antwort vorbereiten, falls Apple ablehnt. Den kompletten Ablauf findest du auf der Seite [eine App im App Store veröffentlichen](https://devoria.fr/de/expertise/app-im-app-store-veroeffentlichen). Wenn du deinen ersten Release vorbereitest, [mach deine kostenlose Diagnose](https://devoria.fr/de/diagnostic): Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Anti-Ablehnungs-Checkliste für Apple. ## Häufige Fragen ### Wie lange dauert die phasenweise Veröffentlichung im App Store? Sieben Tage: 1 % der Nutzer mit automatischen Updates am ersten Tag, dann 2, 5, 10, 20 und 50 %, und 100 % am siebten. Du kannst sie insgesamt bis zu 30 Tage pausieren oder jederzeit mit Release to All Users abschließen. ### Geht ein iOS-App-Update erneut durch Apples Prüfung? Ja. Jede neue Version mit ihrem Build und ihren Metadaten geht durch App Review. Den Werbetext und die Veröffentlichungseinstellungen kannst du dagegen ohne neue Einreichung ändern. ### Kann man im App Store zur alten Version einer App zurückkehren? Nein. Du musst eine neue Version mit dem Fix erstellen und zur Prüfung einreichen. Genau deshalb sind die phasenweise Veröffentlichung und ihre Pause nützlich. ### Bekommen neue Nutzer das Update während der phasenweisen Veröffentlichung? Ja, wenn sie die App aus dem App Store laden. Die phasenweise Veröffentlichung steuert nur automatische Updates: Jeder kann die neue Version jederzeit herunterladen. ### Kann man die phasenweise Veröffentlichung nach Apples Freigabe aktivieren? Ja, solange die Version den Status Pending Developer Release hat, also bei manueller Veröffentlichung und noch nicht veröffentlicht. Ist die Version erst draußen, ist es für diese Version zu spät. ### Was gehört in die Release Notes eines Updates? Neue Funktionen und wichtige Änderungen, klar aufgeführt: Das ist Regel 2.3.12. Für einen einfachen Bug-, Sicherheits- oder Performance-Fix reicht eine allgemeine Formulierung. Das Feld fasst 4.000 Zeichen und lässt sich in jede Sprache übersetzen. ## Dein Projekt [Review Kit](https://devoria.fr/de/kits/app-review): Meine Checkliste für die App Store Review, meine von Apple abgelehnten und korrigierten Fälle, die für Google Play und drei Claude Code Skills. 49 €. [iOS & Android Kit](https://devoria.fr/de/kits/ios): Bau deine iPhone- und Android-App mit Claude Code: der Startcode meiner Apps, der Weg bis in die Stores und alle Kits. 99 €. [Diagnose: Was dich von deiner iPhone-App trennt](https://devoria.fr/de/diagnostic): 7 Fragen, 60 Sekunden: Du erfährst, was dich wirklich davon abhält, deine iPhone-App zu veröffentlichen, bekommst deinen Weg in 4 Schritten und das passende Kit.