App Review in 48 Stunden: Was stimmt, was übertrieben und was falsch ist

Unter iOS-Entwicklern erhitzen sich derzeit die Gemüter, auf X ebenso wie in WhatsApp-Communitys, darunter eine, die ich betreue. Dort ist von endlosen Reviews und gekündigten Konten die Rede, und es werden Rezepte ausgetauscht, um „in weniger als 48 Stunden freigegeben zu werden“: ausführliche Review Notes, ein Demovideo, ein Anruf bei Apple für eine separate Warteschlange, ein minimalistisches MVP, um den „14-Tage-Stapel“ zu vermeiden …

In diesen Ratschlägen stecken sehr gute Ansätze. Aber auch unbelegbare Behauptungen und ein oder zwei Ideen, die falsch angewandt weit mehr kosten können als eine Ablehnung.

Wartezeiten und Kontokündigungen verdienen jeweils ein eigenes Kapitel, weil sie alles Weitere in ein anderes Licht rücken.

Zur Einordnung (auch wenn Sie, nachdem Sie auf dieser Website gelandet sind, vermutlich „wissen“, wer ich bin): Ich veröffentliche seit 2008 im App Store, sowohl eigene Apps als auch Apps für Kunden. Ich habe mir jeden Ratschlag vorgenommen und mit dem verglichen, was Apple auf seiner App-Review-Seite, in den App Review Guidelines und in der App-Review-Hilfe schwarz auf weiß schreibt. Hier erfahren Sie, was einer Prüfung standhält und was nicht.

---

Zunächst: die 48 Stunden richtig einordnen

Die kursierenden Rezepte lassen 48 Stunden wie eine besondere Leistung erscheinen. Auf dem Papier ist das Apples erklärter Standard: Das App-Review-Team arbeitet rund um die Uhr und auf der ganzen Welt (Cupertino, Cork und anderswo). Sein Ziel ist, mindestens 50 % der Einreichungen in weniger als 24 Stunden und 90 % in weniger als 48 Stunden zu bearbeiten.

In der Praxis ist es differenzierter. Diese Zahlen sind Durchschnittswerte über alle Einreichungen, und ein großer Teil davon sind Updates bereits veröffentlichter Apps, die oft innerhalb weniger Stunden durchkommen. In den letzten Wochen wurden einige meiner Updates nach sieben, andere nach zwölf Stunden freigegeben. Eine neue App kann dagegen viel länger warten: Während ich diese Zeilen schreibe, befinden sich einige meiner neuen Apps seit mehr als zehn Tagen in der Review. Das ist lang, aber so läuft das Spiel.

Apple hat dazu kürzlich Zahlen veröffentlicht. Auf Anfrage von MobileGamer.biz erklärte das Unternehmen am 20. Oktober, in den vorangegangenen zwölf Wochen durchschnittlich 378.000 Einreichungen pro Woche bearbeitet zu haben, bei einer durchschnittlichen Dauer von 1,5 Tagen über alle Apps hinweg und 14 Stunden für kleinere Updates. Manche neuen Apps dauerten länger, wenn sie eine eingehendere Prüfung erforderten. Bei diesem Volumen ist der Durchschnitt bemerkenswert; die Abweichungen konzentrieren sich auf Ersteinreichungen.

Um diese Zeiten zu verfolgen, hatte die Community früher ein eigenes Werkzeug. Die Älteren erinnern sich an appreviewtimes.com, Anfang der 2010er-Jahre von meinem Freund Dave Verwer, dem Autor von iOS Dev Weekly, ins Leben gerufen. Das Prinzip war einfach: Entwickler twitterten die Dauer ihrer Reviews mit dem Hashtag #iosreviewtime (ja, damals hieß es noch Twitter), und die Website berechnete einen Durchschnitt. Als man noch in Wochen rechnen musste, war das ein unverzichtbares Werkzeug, um die Erwartungen der Kunden zu steuern.

2019 schloss Dave die Website aus dem besten aller Gründe: Die Reviews waren mit rund einem Tag so schnell geworden, dass ihre Messung kaum noch sinnvoll war. Er hat sie nie wieder eröffnet. Dave ist diesen Sommer übrigens zusammen mit dem Swift Package Index zu Apple gewechselt; Alex Ozun hat iOS Dev Weekly übernommen.

Das Ergebnis: 2026 gibt es kein maßgebliches Community-Barometer mehr, nur vereinzelte Erfahrungsberichte in Foren und sozialen Netzwerken. Ein Zeichen der Zeit: Das Werkzeug, das schloss, weil die Review so schnell geworden war, hätte heute wieder seinen Platz.

Eine kurze Geschichte der Zeit

Es ist nicht das erste Mal, dass sich die Wartezeiten verändern. In den Anfangstagen des App Store konnte eine Review mehrere Wochen dauern. Meine allererste App wartete 26 Tage auf die Freigabe und erschien am 14. Juli 2008, vier Tage nach der Eröffnung des App Store. Danach sank die Dauer auf eine Woche, was lange Zeit die Norm war. Dann beschleunigte Apple den Prozess erheblich, bis ein bis drei Tage üblich wurden. Seit Anfang 2026 steigen die Wartezeiten für neue Apps wieder, und der Grund verdient ein eigenes Kapitel (gleich darunter).

48 Stunden anzustreben heißt also nicht, eine Sonderbehandlung zu suchen, sondern im normalen Ablauf zu bleiben – im Wissen, dass dieser bei einer Markteinführung heute in Tagen gemessen wird. Planen Sie entsprechend.

Die eigentliche Frage lautet: Was bringt eine Einreichung aus diesem Ablauf? Apple gibt auf seiner App-Review-Seite einen wertvollen Hinweis: Mehr als 40 % der ungelösten Probleme fallen unter Guideline 2.1, App Completeness – Abstürze, Platzhalterinhalte, fehlende Informationen. Nicht die subjektive Einschätzung des Reviewers bremst die meisten Apps aus. Es ist eine unvollständige Einreichung.

---

Code-Agenten: mehr Apps, längere Wartezeiten

Warum steigen die Wartezeiten wieder? Die wahrscheinlichste Erklärung lässt sich in einem Wort zusammenfassen: Agenten.

Claude Code, Codex, Cursor, die in Xcode integrierten Agenten: Es war noch nie so leicht, eine iOS-App zu schreiben. Laut Sensor Tower, zitiert von The Information, gingen im App Store im ersten Quartal 2026 235.800 neue Apps ein, 84 % mehr als ein Jahr zuvor – das stärkste gemessene Wachstum seit vier Jahren. Für das gesamte erste Halbjahr schätzt Sensor Tower die Zahl der neuen Apps auf rund 560.000, doppelt so viele wie im Vorjahr, während die Downloads nur um 2 % stiegen. Apple selbst schrieb in seinem Antibetrugsbericht vom Mai, dass KI-Entwicklungswerkzeuge die Zahl der Einreichungen steigen lassen.

Apple hält an seinem Ziel von 90 % in 48 Stunden fest und hat seine Organisation angepasst: mehr Automatisierung und Vorrang für Updates. Die Beobachtungen der Entwickler passen dazu: Updates etablierter Apps kommen weiterhin schnell durch, neue Apps warten länger.

Die gute Seite: what a great time to be a developer

Das ist zunächst in vielerlei Hinsicht eine ausgezeichnete Nachricht. Die Hürde beim Programmieren war noch nie so niedrig. Designer, Fachexperten und unabhängige Entwickler, die nie Swift gelernt hätten, können heute eine nützliche App veröffentlichen. Erfahrene Entwickler liefern in einer Woche, wofür früher ein Quartal nötig war. Ich selbst arbeite täglich mit Agenten: Sie schreiben SwiftUI, Tests und sogar einen ersten Entwurf für Review Notes.

Aber Vorsicht: Zu behaupten, die Hürde sei verschwunden, wäre gelogen. Ein Agent schreibt Code; er weiß nicht an Ihrer Stelle, welches Framework Sie wählen sollten, welches Pattern trägt, wenn die App wächst, wie sich Swift Concurrency, StoreKit oder Berechtigungen verhalten oder warum eine Review stockt. Agenten verstärken das, was Sie bereits wissen. Je besser Sie die Plattform kennen, desto schneller machen sie Sie; je weniger Sie sie kennen, desto schneller sammeln Sie Probleme an, die Sie nicht zu deuten wissen.

Die Zutaten sind für alle gleich: Swift, SwiftUI, Xcode, die Human Interface Guidelines und jetzt ein Agent. Was eine großartige App ausmacht, ist die Art, wie man sie bewusst und sorgfältig zusammensetzt: ein Existenzgrund, der sich in einem Satz formulieren lässt, eine einzige verlässliche Datenquelle, ehrlich geprüfte Barrierefreiheit und Tests auf echten Geräten. Ein Agent kann den Bildschirm schreiben; er sagt Ihnen nicht, ob die App es verdient zu existieren. Oder schlimmer noch: Er spielt die stolze Mama: „Das ist eine fantastische Idee, mein Schatz!“ — und hilft Ihnen anschließend, eine Milliarde Tokens für eine App zu verbrennen, deren gesamte Zielgruppe aus Ihnen, Ihrer Mama, Ihrer Katze, Ihrem Kanarienvogel und vielleicht — nur vielleicht — Ihrem Partner oder Ihrer Partnerin besteht. Diesen gesamten Ansatz, von Apples acht Designprinzipien bis zur Veröffentlichung, habe ich in Das Rezept für eine großartige iOS-App ausführlich beschrieben.

Richtig eingesetzt helfen Agenten auch bei der Regelkonformität. Ein Agent kann Ihre Purpose Strings prüfen, kontrollieren, ob die Kontolöschung vorhanden ist, Ihren Ablauf mit den Guidelines abgleichen und nicht offensichtliche Funktionen auflisten, die dokumentiert werden müssen. Alles, was dieser Artikel beschreibt, kann ein Agent vor Ihnen überprüfen.

Um Ihnen die Arbeit zu erleichtern, stelle ich Ihnen übrigens einen Skill zur Verfügung, der Ihnen hilft, Fehler vor der Einreichung aufzuspüren: app-review-skill. Er garantiert keine Freigabe, ist aber immerhin eine zusätzliche Absicherung. 😉

Kurz: what a great time to be a developer.

Die Illusion vom Millionär mit drei Prompts

Die Kehrseite ist das Narrativ, das diese Welle begleitet. Überall begegnet einem dasselbe Versprechen: drei Prompts, ein Abo (oder überall Werbung), und schon sind Sie in drei Tagen Millionär.

Spoiler: Das stimmt nicht. Und die Zahlen sprechen eine klare Sprache. Der Bericht State of Subscription Apps 2026 von RevenueCat, der mehr als 115.000 Apps und 16 Milliarden Dollar Umsatz umfasst, zeigt:

• Ein Jahr nach dem Start erzielt die mediane App rund 72 $ im Monat;
• nur 17,3 % der Apps erreichen in ihren ersten zwei Jahren 1.000 $ monatlichen Umsatz, und 4,6 % überschreiten 10.000 $;
• selbst die erfolgreichsten 10 % kommen nach einem Jahr gerade einmal über 2.574 $ im Monat: weit, sehr weit entfernt von einer Million;
• Apps, die 2025 oder später gestartet wurden, machen nur 3 % der Abo-Umsätze aus, während diejenigen, die vor 2020 gestartet wurden, 69 % auf sich vereinen.

Und die Rede ist hier von Apps, die seriös genug sind, um ein Abosystem integriert zu haben.

Jeder glaubt, die next big idea zu haben. Tut mir leid, Sie auf den Boden der Tatsachen zurückholen zu müssen. Wenn Ihre Idee im App Store noch nicht existiert, gibt es nur zwei Möglichkeiten: Entweder wurde sie bereits ausprobiert und hat nicht funktioniert, oder etwa hundert andere Menschen bauen sie gerade in diesem Moment. Und mit Agenten werden aus hundert schnell tausend.

Das ist kein Pessimismus, sondern ein gut dokumentiertes Phänomen: gleichzeitige Entdeckungen. Alexander Graham Bell und Elisha Gray meldeten 1876 am selben Tag ein Patent für das Telefon an. Darwin und Wallace kamen unabhängig voneinander zur natürlichen Selektion und stellten ihre Arbeiten 1858 sogar gemeinsam vor. Newton und Leibniz erfanden die Infinitesimalrechnung parallel. Keine Magie: Zu einer bestimmten Zeit stehen allen dieselben Werkzeuge, dieselben Probleme und derselbe Zugang zu Informationen zur Verfügung. Zwei Köpfe, die mit denselben Werkzeugen vor demselben Problem stehen, gelangen ganz natürlich zur selben Lösung. Wie es in dem oft Victor Hugo zugeschriebenen Satz heißt: Nichts ist mächtiger als eine Idee, deren Zeit gekommen ist.

Der daraus folgende Rat: Halten Sie Ihre Idee nicht aus Angst geheim, jemand könnte sie stehlen. Andere arbeiten bereits daran. Die Menschen, mit denen Sie darüber sprechen, weisen Sie vielleicht sogar auf konkurrierende Apps hin, die Ihnen bisher entgangen sind. Den Unterschied machen nicht die Idee, sondern die Umsetzung, die Verbreitung, die Zeit und Ihre persönliche Note.

Ich kenne Entwickler, deren Apps zwischen 80.000 und mehr als einer Million Dollar im Monat einbringen. Es gibt sie, sie sind brillant, und sie haben oft jahrelange Iterationen hinter sich. Sie sind eindeutig nicht die Mehrheit.

Das ist kein Grund, es nicht zu versuchen. Es ist ein Grund, es aus den richtigen Gründen zu tun: ein echtes Problem lösen, lernen, langfristig etwas aufbauen. Und sich um das zu kümmern, was sich nicht automatisieren lässt: Qualität.

Die weniger gute Seite

Hastig zusammengeschusterte Apps landen in der Review, und alle teilen sich dieselbe Warteschlange. Eine App an einem Wochenende zu generieren heißt nicht, dass sie fertig ist: Viele Einreichungen kommen ungeprüft auf einem Gerät, mit Platzhalterinhalten, ohne Datenschutzerklärung und ohne Review Notes an. Andere sind für niemanden außer ihrem Entwickler interessant. Dabei sagt Apple es gleich in der Einleitung seiner Guidelines: Eine App, die man nur Familie und Freunden zeigen will, gehört nicht in den App Store; dafür gibt es Xcode und die Ad-Hoc-Verteilung. Jede dieser Einreichungen beschäftigt einen Reviewer, der sich in dieser Zeit nicht um Ihre kümmert. Indem Apple Updates bestehender Apps bevorzugt, schützt es bestehende Nutzer und etablierte Entwickler; die Kehrseite sind längere Wartezeiten für neue Apps.

Spam ist das erste Ziel. Guideline 4.3 verbietet die Einreichung mehrerer Varianten derselben App und Apps in gesättigten Kategorien ohne echte Unterscheidungsmerkmale. Mit einem Agenten lassen sich fünf Klone an einem Nachmittag erstellen; genau das filtert Apple heraus. Apple gibt an, Automatisierung und Missbrauchserkennung verstärkt und Schutzmaßnahmen gegen wiederholte Einreichungen mit denselben ungelösten Problemen eingeführt zu haben. In den Guidelines stand bereits: Wiederholte Ablehnungen aus demselben Grund verlängern die Review.

Apps, die Code generieren, stehen im Visier. Apple hat dieses Jahr Updates blockiert oder mehrere Vibe-Coding-Apps entfernt, darunter Replit, Vibecode und Anything. Der Grund ist nicht Vibe Coding an sich, sondern Guideline 2.5.2: Eine App darf keinen Code herunterladen oder ausführen, der ihre Funktionen nach der Review verändert.

Mehr Apps bedeuten nicht mehr Nutzer. Bei nahezu gleichbleibenden Downloadzahlen kämpft jede neue App um dieselbe Aufmerksamkeit. Die technische Hürde ist gesunken; die Qualitätshürde dagegen gestiegen.

Was das für Sie bedeutet

• Sie bleiben verantwortlich. Die Guidelines erinnern daran: Alles in Ihrer App, einschließlich SDKs von Drittanbietern, liegt in Ihrer Verantwortung. „Das hat der Agent geschrieben“ ist kein zulässiges Argument.
• Die Qualität der Einreichung wird zum Vorteil. In einer überfüllten Warteschlange sticht eine vollständige App mit klaren Notizen noch stärker hervor als zuvor.
• Eine App, nicht fünf Varianten. Nutzen Sie In-App-Käufe oder Einstellungen für Varianten, statt Bundle IDs zu vervielfachen.
• Reichen Sie nie erneut ein, ohne zu korrigieren. Ein unnötiger Durchlauf kostet Sie Tage und kann Sie unter die Verhaltensweisen einordnen, die Apple beobachtet.
• Planen Sie Puffer ein. Rechnen Sie für eine neue App mit einer Woche plus einem möglichen weiteren Durchlauf. Wenn es in 48 Stunden klappt, umso besser.

---

Die Ratschläge, die überzeugen

Qualität zählt, und sie steht in den Regeln

„Eine sorgfältig gestaltete App wird besser behandelt“: Das stimmt, aber nicht wegen der Laune des Reviewers. Abschnitt 4 der Guidelines sagt es deutlich: Apple erwartet einfache, durchdachte und leicht bedienbare Oberflächen. Guideline 4.2 (Minimum Functionality) lehnt Apps ab, die nur eine neu verpackte Website, eine Sammlung von Links oder Inhalte ohne dauerhaften Wert sind.

„Entwickeln Sie nativ mit SwiftUI“: ein guter Rat, keine Regel

Ich bin nativer iOS-Entwickler: Ich praktiziere, verteidige, fördere und lehre es. Für mich ist das der bevorzugte Weg, eine App zu bauen, die den Gepflogenheiten der Plattform entspricht und die Möglichkeiten von iPhone und iPad voll ausschöpft. Mit SwiftUI profitieren Sie von Dynamic Type, Safe Areas, Sheets, Systemnavigation und der Anpassung an iPhone und iPad, mit direktem Zugriff auf Widgets, Live Activities, App Intents und viele weitere Möglichkeiten der Apple-Frameworks. Diese Integration macht im Alltag einen echten Unterschied und verringert ganz automatisch die kleinen Mängel, die einem Reviewer auffallen.

Aber keine Guideline schreibt SwiftUI vor. Eine gut gemachte App mit Expo, Flutter oder UIKit kommt problemlos durch. Entscheidend ist das Ergebnis: eine getarnte Web View, eine Oberfläche, die auf dem iPad kaputtgeht (Guideline 2.4.1 empfiehlt iPad-Unterstützung, sobald sie möglich ist), oder eine Tastatur, die ein Feld verdeckt. Native Entwicklung erhöht Ihre Chancen auf ein hervorragendes Ergebnis; sie garantiert es nicht.

P.S.: Martin, nicht hauen, nicht hauen, nicht haaaa… klatsch

Datenschutzerklärung, Support und Berechtigungen

Hier unterschätzt man die Realität oft. Das sind keine guten Praktiken, sondern Pflichten:

• Eine Datenschutzerklärung, die in App Store Connect und in der App zugänglich ist (5.1.1(i)). Sie muss die erhobenen Daten und ihre Verwendung beschreiben, Dritte auf ein gleichwertiges Schutzniveau verpflichten und Aufbewahrung, Löschung und Widerruf der Einwilligung erklären.
• Ein Support-Link mit aktuellen Kontaktdaten; alle Links müssen funktionieren (2.1 und 5.1).
• Klare Purpose Strings für jede sensible Berechtigung, idealerweise mit einem konkreten Anwendungsbeispiel.
• Datenminimierung (5.1.1(iii)): Bevorzugen Sie System-Picker wie die Fotoauswahl gegenüber einem vollständigen Zugriff auf die Fotomediathek.
• Kontolöschung in der App, sobald dort ein Konto erstellt werden kann (5.1.1(v)).

Das oft empfohlene Format „statisches HTML“ ist keineswegs vorgeschrieben. Entscheidend ist, dass die Seite zugänglich und aktuell ist und mit dem übereinstimmt, was die App tut.

Soziale Apps: vier konkrete Anforderungen

Melden, Blockieren, Kontakt, Moderation: Das ist genau Guideline 1.2 (User-Generated Content), die Folgendes verlangt:

1. eine Möglichkeit, inakzeptable Inhalte vor der Veröffentlichung zu filtern;
2. einen Meldemechanismus und eine schnelle Reaktion auf Meldungen;
3. die Möglichkeit, missbräuchliche Nutzer zu blockieren;
4. veröffentlichte Kontaktdaten, unter denen Sie erreichbar sind.

Seit dem Update vom 16. Oktober 2026 nennt die Guideline ausdrücklich Apps zur Erstellung von Inhalten mit KI. Apple stellt klar, dass nicht einvernehmliche intime Bilder, einschließlich KI-generierter Bilder, aktiv verhindert und entfernt werden müssen. Ein Entwickler, der keine Schutzmaßnahmen einrichtet oder nach einer Benachrichtigung keine Korrektur vornimmt, kann als Verstoß gegen den Verhaltenskodex gewertet werden.

Die kostenlose Moderations-API von OpenAI wird in Diskussionen häufig erwähnt. Sie ist eine gültige technische Option, mit einer wichtigen Einschränkung: Guideline 5.1.2(i) verlangt eine klare Information darüber, wann personenbezogene Daten mit Dritten geteilt werden, einschließlich einer KI eines Drittanbieters, sowie eine ausdrückliche Erlaubnis. Fotos Ihrer Nutzer ohne deren Wissen an ein externes Modell zu senden heißt, eine Ablehnung durch eine andere zu ersetzen.

In-App-Käufe müssen funktionieren

Offensichtlich, aber oft übersehen: Guideline 2.1(b) verlangt vollständige, für den Reviewer sichtbare und funktionierende In-App-Käufe. Wenn ein konfiguriertes Produkt im eingereichten Build nicht zugänglich ist, erklären Sie in den Notizen, warum. Und sehen Sie eine Schaltfläche „Käufe wiederherstellen“ vor.

---

Review Notes: der am meisten unterschätzte Hebel

Das ist der nützlichste Ratschlag von allen, und Apple geht sogar noch weiter.

Was Apple in der Checkliste „Before You Submit“ verlangt:

• vollständigen Zugang zur App: ein aktives Demokonto oder einen vollständigen Demomodus sowie nötige Hardware oder Ressourcen (Zugangsdaten, Beispiel-QR-Code …);
• ein während der gesamten Review erreichbares Backend;
• eine ausführliche Erklärung nicht offensichtlicher Funktionen und In-App-Käufe in den Notizen, bei Bedarf mit Dokumentation.

Ja, ein Teil ist automatisiert, und bei diesem Volumen ist das normal. Aber Apple schreibt es in der Einleitung seiner Guidelines schwarz auf weiß: Jede App wird von Experten geprüft. In neun von zehn Fällen, wenn nicht häufiger, sitzt ein Mensch am Steuer und drückt den kleinen grünen (oder roten) Knopf.

Ihre Notizen richten sich also an einen Menschen, der Ihre App in wenigen Minuten kennenlernt. Schreiben Sie sie für ihn.

Und Guideline 2.3.1(a) ist eindeutig: Jede neue Funktion muss in den Notizen präzise beschrieben werden; allgemeine Beschreibungen werden abgelehnt.

Achten Sie auf ein Detail: Ein Demomodus anstelle eines Demokontos wird nur mit vorheriger Zustimmung von Apple akzeptiert und nur dann, wenn rechtliche oder Sicherheitsauflagen Sie daran hindern, ein Konto bereitzustellen.

Eine funktionierende Struktur

Sie müssen nicht den Roman eines anderen abschreiben. Hier ist das Grundgerüst, das ich verwende:

Guten Tag,

[Name der App] ist [ein Satz: was die App tut, für wen und welches Problem sie löst].
Geschäftsmodell: [kostenlos / Abonnement / Einmalkauf], über In-App Purchase.

Zugang:
- Demokonto: [Benutzername] / [Passwort]
  (oder: kein Konto erforderlich)

Hauptablauf:
1. …
2. …
3. …

In-App-Käufe:
- Wo der Paywall erscheint und wie man in der Sandbox testet.
- „Käufe wiederherstellen“: [Ort].

Nicht offensichtliche Funktionen:
- [Funktion]: wie man darauf zugreift und was sie tut.

Daten und Berechtigungen:
- Welche Berechtigungen, wann sie angefragt werden und warum.
- Mit Dritten geteilte Daten (einschließlich KI) und Einwilligung.

Externe Dienste:
- [Dienst]: wozu er dient (Daten, Authentifizierung, Zahlung, KI, Werbung …).

Regionale Unterschiede:
- [Keine / welche].

Regulierung und Inhalte Dritter:
- [Nicht zutreffend / beigefügte Unterlagen].

Konto und Sicherheit:
- Kontolöschung: [Pfad].
- Melden / blockieren: [Pfad] (bei Nutzerinhalten).

Für den Stil gilt die goldene Regel: kurze Sätze, verständlich für jemanden, der die App zum ersten Mal sieht. Nur das gelegentlich zu lesende „Verwenden Sie keine KI“ würde ich einschränken: Einen ersten Entwurf von einem Agenten schreiben zu lassen, der Ihren Code kennt, spart tatsächlich Zeit. Entscheidend ist, ihn vor der Einreichung durchzulesen und zu vereinfachen.

Ein reales Beispiel: offenlegen, was aus der Ferne gesteuert wird

Hier ist eine Notiz, die ich bei einer meiner Apps hinterlassen habe (anonymisiert). Der Fall ist typisch: Das Werbe-SDK ist integriert, aber Werbung kann vor der Veröffentlichung nicht aktiviert werden, weil AdMob eine in einem Store veröffentlichte App verlangt, um ihre „App Readiness“ zu prüfen. Die Werbung ist daher während der Review über ein Feature Flag abgeschaltet.

ADVERTISING DISCLOSURE - INITIAL 1.0 RELEASE
This app includes the Google Mobile Ads (AdMob) SDK and Google UMP consent integration. Production advertising is currently disabled through a remote feature flag. This is the general launch configuration, not a condition targeting App Review. We are disclosing the advertising integration explicitly; it is not disabled to hide it from reviewers.

The reason is that this initial release is not yet publicly available on the App Store. AdMob requires a published, downloadable app linked to a supported store for its app readiness review, and approval before full ad serving. We therefore cannot complete that activation process before publication. After release, we plan to link the App Store listing, complete AdMob's readiness process and enable production advertising through the feature flag.

The absence of ads during review should not be interpreted as an ad-free product. Ad presentation will remain subject to the applicable consent and tracking permissions.
Google's explanation: https://support.google.com/admob/answer/10564477?hl=en

Warum diese Notiz funktioniert:

• Sie benennt, was im Binary enthalten ist: das AdMob SDK und das UMP-Einwilligungsmodul.
• Sie legt das Feature Flag offen und stellt klar, dass es nicht auf die Review abzielt. Das ist genau das Gegenteil einer schlummernden Funktion im Sinne von Guideline 2.5.19.
• Sie erklärt den Grund anhand einer überprüfbaren externen Quelle.
• Sie kündigt an, was sich nach der Veröffentlichung ändern wird, damit die Aktivierung der Werbung keine Überraschung ist.
• Sie erinnert an die Einwilligung: Personalisierte Werbung bleibt von den Tracking-Berechtigungen abhängig.

Nichts ist verborgen, nichts muss interpretiert werden: Der Reviewer weiß genau, was er freigibt.

Das Demovideo: nicht vorgeschrieben, aber immer häufiger angefordert

Man liest gelegentlich, Ersteinreichungen ohne Notizen und Video würden automatisch abgelehnt. Nichts in Apples Dokumentation sagt das. Apple schreibt, dass man bereit sein muss, ein Demovideo oder die Hardware bereitzustellen, wenn bestimmte Funktionen von einer schwer nachzubildenden Umgebung oder spezieller Hardware abhängen.

In der Praxis hilft eine kurze kommentierte Bildschirmaufnahme, die in App Review Information als Anhang hinterlegt wird, erheblich, sobald die App vom Üblichen abweicht: ein vernetztes Gerät, Geolokalisierung, eine soziale Funktion, die mehrere Konten benötigt. Für eine Notiz-App ohne Konto ist sie überflüssig.

Das Ziel bleibt richtig: die Review so einfach wie möglich machen. Ein Reviewer, der Ihre App in drei Minuten versteht, hat keinen Grund, Ihnen Fragen zu stellen.

Wenn Apple Sie um „weitere Informationen“ bittet

Bei neuen Apps kommt eine Nachricht immer häufiger vor: eine standardisierte Informationsanfrage im Zusammenhang mit Guideline 2.1. Diese habe ich kürzlich für eine meiner Apps erhalten:

We need additional information to better understand the app and complete the review.

Reply in App Store Connect with all of the following information and also add this
information to the Notes field of the App Review Information section in App Store
Connect, for reference on future submissions:

1. A screen recording captured on a physical device, running the latest operating
   system, demonstrating the app's functionality. The recording must begin with
   launching the app and show the typical user flow. If the app has any of the
   following, include them in the recording:
   - Account registration, login, and account deletion flows.
   - Any user-generated content, including the required content reporting and
     blocking mechanisms.
   - Accessing paid content or features within the app.
2. A description of the app's purpose and target audience, including the problem
   it solves and the value it provides
3. Instructions for setting up and accessing the app's main features, including
   any required login credentials or sample files
4. A list of the external services, tools, or platforms the app uses to deliver
   its core functionality (for example, data providers, authentication services,
   payment processors, or AI services)
5. Describe any regional differences in the app's features or content, or confirm
   that the app functions consistently across all regions
6. If the app operates in a highly regulated industry or includes protected
   third-party material, provide any relevant documentation or credentials to
   demonstrate you are authorized to provide these services or protected material

Die Nachricht erinnert nebenbei an die klassischen Stolperfallen: Fehler auf physischen Geräten, Demokonto, Screenshots, die die App in Benutzung zeigen, mit der App konfigurierte In-App-Käufe und eine Unternehmen vorbehaltene Distribution.

Und hier ist meine Antwort, anonymisiert:

1. [Screen recording attached, captured on a physical device.]

2. [App] is a [category] app that [what the app does]. It's inspired by
   [well-known reference], but adds [its own distinctive features]. It's designed
   for [target audience], and [the problem it solves / the value it provides].

3. There's no account to create and no login required. Users can simply open the
   app and start using it. The main flow consists of [main interaction]. Users
   can also [secondary features] directly from the app. The app includes optional
   rewarded ads to unlock [optional extra].

4. The app runs primarily on the device. [Core processing] is handled locally,
   so there's no external API involved in the core functionality. Google's AdMob
   is used to display advertisements, including optional rewarded ads.

5. The app works the same way in every region where it's available. The main
   difference is the language: the app has a localized name and content adapted
   to each language. Features and core mechanics remain consistent across all
   supported regions.

6. Not applicable. [App] is an original app and doesn't operate in a regulated
   industry.

Drei Erkenntnisse:

• Das Video wird nicht grundsätzlich verlangt, hier aber ausdrücklich angefordert: auf einem physischen Gerät mit der neuesten iOS-Version aufgenommen, beginnend mit dem Start der App. Man kann es also gleich vor der ersten Einreichung vorbereiten.
• Apple verlangt, diese Antworten für spätere Einreichungen im Feld Notes zu ergänzen. Anders gesagt: Hätten sie von Anfang an dort gestanden, wäre der zusätzliche Durchlauf vermutlich vermieden worden.
• Die sechs Fragen sind eine hervorragende Checkliste. Zweck, Zielgruppe, Zugang, externe Dienste, regionale Unterschiede, Regulierung: Ich habe sie in die Vorlage für Notizen weiter oben aufgenommen.

---

Was Sie nicht tun sollten (und warum es manchmal schlimmer ist als eine Ablehnung)

„Demnächst verfügbar“-Bildschirme

Platzhalterinhalte, tote Schaltflächen, leere Links: Das ist der Kern von Guideline 2.1 und laut Apple die häufigste Problemursache. Entfernen Sie die Funktion lieber aus dem Build, statt sie halbfertig zu zeigen.

Den Paywall nach der Review ändern

Manchmal wird „einen aus der Ferne gesteuerten Paywall nach der Review regelwidrig machen“ zu den bloßen Dark Patterns gezählt. Das ist weit gravierender.

Guideline 2.5.19, die am 16. Oktober 2026 ausdrücklich gegen Bait-and-Switch eingeführt wurde, verbietet versteckte, schlummernde oder undokumentierte Funktionen und sieht die Entfernung der App und die Kündigung des Entwicklerkontos vor. Die Einleitung der Guidelines ist noch direkter: Der Versuch, den Review-Prozess zu täuschen, führt zur Entfernung der Apps und zum Ausschluss aus dem Apple Developer Program. Hier geht es nicht darum, auf die Nachsicht eines Reviewers zu setzen, sondern um ein Risiko für Ihre gesamte Geschäftstätigkeit.

Den Paywall aus der Ferne zu konfigurieren ist nicht verboten. Ihn auf etwas umzustellen, das der Reviewer nicht gesehen hat, schon.

Bewertungsanfragen

Guideline 5.6.1 schreibt für Bewertungsanfragen die von Apple bereitgestellte API vor und verbietet eigene Prompts. Guideline 3.2.2(x) verbietet es, den Zugang zu einer Funktion davon abhängig zu machen, dass die App bewertet wird.

Während des Onboardings um eine Bewertung zu bitten, ist nicht ausdrücklich verboten, aber absurd: Der Nutzer hat noch nichts gesehen, und das System begrenzt ohnehin, wie oft diese Anfrage angezeigt wird. Warten Sie auf einen echten Moment der Zufriedenheit.

Gefälschte soziale Belege und unbelegbare Versprechen

Eine erfundene „Million Nutzer“, gefälschte Bewertungen, „löst 100 % Ihrer Probleme“: Guideline 5.6.3 verbietet jede Manipulation von Bewertungen, Rankings oder Suchergebnissen, und 2.3.7 verbietet unbelegbare Behauptungen in den Metadaten. Für Gesundheits-Apps verlangt 1.4.1, die Methodik hinter jedem Genauigkeitsversprechen zu dokumentieren.

Eine App kopieren

Offensichtlich, und Apple geht noch weiter. Guideline 4.1 lehnt Kopien ab, und die Nachahmung einer anderen App ist ein Verstoß gegen den Verhaltenskodex. 4.3 verschließt gesättigten Kategorien die Tür (Taschenlampen, Hintergrundbilder, Dating-Apps, einfache Timer …), sofern sie kein wirklich anderes Erlebnis bieten. Es gibt bereits eine Million Furzmaschinen, Taschenlampen und Dating-Apps: Apple nennt Furz- und Rülps-Apps sogar ausdrücklich als Beispiele für Apps, die dem App Store nichts hinzufügen.

Angebote zur Kundenbindung: die offiziellen Werkzeuge nutzen

Viel ist von „transaction abandon“ und „exit offers“ die Rede (also jemandem, der zögert oder kündigen möchte, ein Angebot zu machen). Diese Praktiken sind an sich nicht verboten, und StoreKit bietet dafür offizielle Mechanismen: Aktionsangebote, Rückgewinnungsangebote (win-back offers) und den Systembildschirm zur Aboverwaltung.

Es ist vernünftig, sie für ein späteres Update aufzuheben: weniger Angriffsfläche, weniger Fragen. Aber die eigentliche Regel liegt woanders. Guideline 3.1.2(c) verlangt eine klare Beschreibung dessen, was der Nutzer für den Preis erhält, und 5.6 verbietet es, zu unerwünschten Käufen zu drängen. Ein klares, in den Notizen beschriebenes Angebot hat nichts zu befürchten. Eines, das den Preis verschleiert, schon.

---

Kontokündigungen: verstehen, um nicht betroffen zu sein

Eine Ablehnung kostet ein paar Tage. Eine Kündigung kostet Sie alle Ihre Apps. Das Thema beschäftigt die sozialen Netzwerke in den letzten Wochen stark und verdient eine ruhige Betrachtung.

Warum Apple die Zügel anzieht

Am 16. Oktober 2026 hat Apple seine Guidelines in zwei Punkten verschärft: bei nicht einvernehmlichen intimen Bildern, einschließlich KI-generierter Bilder, die Apps verhindern und entfernen müssen (1.2), und beim Bait-and-Switch, also Apps, die sich während der Review harmlos präsentieren und nach der Freigabe schädliche Funktionen aktivieren (2.5.19). In derselben Ankündigung erklärt Apple, im Vorjahr mehr als 150.000 Apps mit Sicherheitsproblemen daran gehindert zu haben, Nutzer zu erreichen, und wegen Betrugs und Missbrauchs mehr als 193.000 Entwicklerkonten gekündigt zu haben.

Diese Zahlen sagen das Wesentliche: Betrug im App Store ist massiv und organisiert. „Nudification“-Apps haben sich vervielfacht, Behörden wie die Stadt San Francisco haben ihre Entfernung verlangt, und der Zustrom KI-generierter Einreichungen erhöht den Druck zusätzlich. Dass das Vertrauen der Nutzer in den App Store trotzdem Bestand hat, ist zu einem großen Teil dieser Arbeit zu verdanken.

Bei diesem Umfang geraten gelegentlich auch redliche Entwickler ins Netz. Genau für solche Fälle gibt es den Einspruch beim App Review Board.

Was Entwickler berichten

Die geteilten Benachrichtigungen berufen sich auf Abschnitt 3.2(f) des Developer Program License Agreement und sprechen von einem „Muster manipulativen oder täuschenden Verhaltens“, gefolgt von einer Liste möglicher Verhaltensweisen: unzutreffende Metadaten, irreführende Inhalte, gefälschte Bewertungen, irreführende Antworten an den Support oder in App Store Connect, Bait-and-Switch-Käufe …

Phillip Shoemaker, der App Review geleitet hat, veröffentlichte Ende Oktober seine Analyse. Er meint, dass die Ablehnungshistorie inzwischen stark ins Gewicht fällt: Anzahl der Einreichungen, Namensänderungen, wiederholte Ablehnungen wegen inakzeptabler Inhalte, insbesondere bei generativen Foto-Apps. Er erkennt auch die Schwierigkeiten auf Apples Seite an: Generative Apps sind sehr schwer zu prüfen, eine serverseitige Korrektur kann jederzeit rückgängig gemacht werden, und Apple verknüpft Konten miteinander, was ihm eine Sicht verschafft, die der Entwickler nicht immer hat. Seine Vorschläge sind konstruktiv: Ablehnungen, die genauer benennen, was sich ändern muss, und konkrete Angaben in den Benachrichtigungen, damit ein Einspruch sinnvoll ist.

Wer zu clever sein will, fällt auf die Nase

Man muss keine Namen nennen: Die Geschichten, die kursieren, ähneln einander. Und wenn man sie genau liest, begegnen einem oft dieselben Verhaltensweisen. Sie entstehen selten aus böser Absicht, sehen aus Cupertino betrachtet aber verdächtig nach dem aus, was Apple aufzuspüren versucht:

• Immer wieder einreichen und jedes Mal eine Kleinigkeit ändern, „um zu sehen, ob es durchgeht“.
• Die App umbenennen, unterwegs das Konzept oder die Kategorie ändern, manchmal mehrfach.
• Oberflächlich korrigieren: eine Option aus einem Menü entfernen, während die Funktion anderswo zugänglich bleibt.
• Einen serverseitigen Schalter behalten, den der Reviewer nie gesehen hat.
• Keywords überladen oder sich etwas zu stark vom Namen einer konkurrierenden App inspirieren lassen.
• Konten vervielfachen oder das eigene verleihen, um eine Ablehnung zu umgehen.
• Die Wahrheit zurechtbiegen in Antworten an App Review.

Einzeln betrachtet kann jede dieser Handlungen harmlos erscheinen. Aneinandergereiht ergeben sie ein Muster. Und bei Hunderttausenden Einreichungen pro Woche liest Apple dieses Muster, nicht Ihre Absichten.

Die Moral ist einfach: Wer bei App Review besonders schlau spielen will, wettet gegen das Haus. Und das Haus kennt die gesamte Historie.

Das App Review Board ist weiterhin dafür da, einen Fehler zu korrigieren, und redliche Entwickler bekommen dort auch recht. Aber der beste Einspruch ist der, den man nie einlegen muss.

Was das für Sie bedeutet

Ich werde mich nicht als Jurist aufspielen: Bei einer Kündigung ist der einzige Weg der Einspruch beim App Review Board, und in den berichteten Fällen eröffnet die Benachrichtigung dafür eine Frist von 30 Tagen. Wenn Ihnen das passiert, lassen Sie sich begleiten. Einige Verhaltensweisen verringern das Risiko jedoch deutlich:

• Ihre Ablehnungshistorie zählt. Jede Einreichung hinterlässt eine Spur. Reichen Sie nie „zum Ausprobieren“ erneut ein: Stellen Sie vor der Korrektur eine konkrete Frage in App Store Connect.
• Ändern Sie unterwegs nicht die Identität der App. Name, Konzept, Kategorie: Wiederholte Änderungen ähneln dem, was Apple aufzuspüren versucht. Wenn App Review Sie dazu auffordert, lassen Sie es sich in App Store Connect schriftlich bestätigen, auch nach einem Anruf, und fassen Sie das Telefongespräch schriftlich zusammen.
• Wenn sich eine Ablehnung im Kreis dreht, hören Sie auf, erneut einzureichen. Bitten Sie schriftlich um die vollständige Liste der Hindernisse und legen Sie dann beim App Review Board Einspruch ein, statt Versuch an Versuch zu reihen.
• Dokumentieren Sie alles, was sich aus der Ferne konfigurieren lässt. Feature Flags, Paywall, KI-Modelle: Nennen Sie es in den Notizen und zeigen Sie, was sich ändern kann.
• Korrigieren Sie bei einer generativen App an der Quelle. Eine Option aus einem Menü zu entfernen reicht nicht, wenn das Modell den Inhalt auf einfachen Prompt hin weiterhin erzeugt. Die Filterung muss tatsächlich greifen, sowohl beim Modell als auch bei der Ausgabe.
• Antworten Sie in App Store Connect wahrheitsgetreu. „Irreführende Antworten“ stehen ausdrücklich auf der Liste der Gründe.
• Archivieren Sie jede Einreichung. Build, Notizen, Screenshots, Austausch mit App Review: Das ist Ihre einzige Dokumentation im Fall eines Einspruchs.
• Achten Sie auf Ihre Verbindungen. Geteilte Konten, verliehene Zertifikate, Partner mit fragwürdigen Praktiken: Apple verknüpft Konten miteinander.

Deshalb folge ich auch nicht der gelegentlich vorgebrachten Ansicht, „Apple wolle, dass wir die Grenze ausloten“. 2026 zählt jede Einreichung in Ihrer Historie. Streben Sie lieber nach Klarheit als nach der Grenze.

---

Eine Review beschleunigen: Was es wirklich gibt

Hier kursieren die meisten falschen Vorstellungen.

Die beschleunigte Review (Expedite)

Sie existiert für außergewöhnliche Umstände: einen kritischen Fehler oder eine Veröffentlichung im Zusammenhang mit einer Veranstaltung, an der Sie unmittelbar beteiligt sind. Einige oft vergessene Einzelheiten:

• Nur eine bereits zur Review eingereichte App kann beschleunigt geprüft werden;
• geben Sie bei einem kritischen Fehler in den Notizen die Schritte an, mit denen er sich in der aktuellen Version reproduzieren lässt;
• nennen Sie bei einer Veranstaltung das Ereignis, sein Datum und den Bezug der App dazu;
• Apple bearbeitet die Anfrage je nach Verfügbarkeit und Nachfrage, ohne Garantie;
• und vor allem behält sich Apple bei Missbrauch das Recht vor, künftige Anfragen abzulehnen.

„Man muss keinen Grund angeben“ ist also irreführend: Das Formular ist einfach, aber die Begründung muss in den Notizen stehen. Ein „viraler Moment“ oder „Marketing“ gehören nicht zu den Kriterien. Dafür würde ich diese Patrone nicht verschießen.

Der Anruf bei Apple: keine schnelle Warteschlange

Der Anruf wird oft als wenig bekannte Methode dargestellt, mit der man in eine separate Warteschlange gelangt. Das beschreibt Apple nicht.

Man kann nach einer ersten Antwort von App Review über das Antwortfenster einen Anruf mit einem Apple-Mitarbeiter anfordern und dabei Zeitzone und Sprache angeben. Diese Anrufe finden in der Regel innerhalb von drei bis fünf Werktagen statt. Sie sind ein ausgezeichnetes Mittel, um ein Missverständnis bei einer Ablehnung auszuräumen. Sie sind keinesfalls eine Abkürzung zu 48 Stunden. Denken Sie daran, dass die nächste Review von einer anderen Person durchgeführt werden kann: Lassen Sie die Ergebnisse immer schriftlich in App Store Connect bestätigen.

App-Review-Termine: das wahre Geheimnis

Was selten erwähnt wird und was ich allen meinen Kunden vor einer heiklen Ersteinreichung empfehle: App-Review-Termine über Meet with Apple. Dreißig Minuten per Video mit einem App-Review-Experten, dienstags und donnerstags je nach Verfügbarkeit, um konkrete Fragen dazu zu stellen, wie eine Guideline auf Ihre App angewandt wird.

Zwei Einschränkungen sollte man kennen: Der Termin dient der Information, er ersetzt, beschleunigt oder garantiert die Review nicht, und Apple genehmigt keine Funktion im Voraus. Aber bei der Einreichung bereits zu wissen, wie Apple Ihren Fall beurteilt, ist die bestmögliche Investition.

Aus der Schleife aufeinanderfolgender Ablehnungen ausbrechen

Der Albtraum ist bekannt: eine Ablehnung, eine Korrektur und dann eine neue Ablehnung aus einem anderen Grund. Um herauszukommen, muss man die richtigen Kanäle nutzen:

• In App Store Connect antworten und eine konkrete Frage stellen: zu der Funktion, Guideline oder dem Schritt, der geklärt werden muss. Ein Spezialist, der Ihre App kennt, antwortet Ihnen. Die Frage „Gibt es weitere Hindernisse?“ ist legitim, auch wenn niemand Ihnen eine Garantie geben kann.
• Bug Fix Submission: Bei einer bereits veröffentlichten App wird ein fehlerbehebendes Update nicht durch andere Guideline-Probleme blockiert, außer bei rechtlichen oder Sicherheitsfragen. Den Rest korrigieren Sie bei der nächsten Einreichung.
• Einspruch beim App Review Board, wenn Sie meinen, dass die App falsch verstanden wurde: einmal pro abgelehnter Einreichung, mit konkreten Argumenten.

Was den Ton angeht, erinnert Guideline 5.6 daran, alle respektvoll zu behandeln, auch im Austausch mit Apple. Sich zu beschweren bringt nichts; mit den Guidelines zu argumentieren schon.

---

Scope Creep: der beste Rat, mit einer Einschränkung

„Reichen Sie ein MVP ein“ ist ein ausgezeichneter Rat, und Apple bestätigt ihn auf seine Weise: Eine komplexe App oder eine, die neue Fragen aufwirft, kann eine eingehendere Prüfung erfordern, und wiederholte Ablehnungen aufgrund derselben Guideline verlängern die Review.

Die Beschreibung von „zwei Stapeln“ mit einer Eskalation an einen erfahrenen Spezialisten und 14 Tagen Wartezeit ist dagegen nirgendwo dokumentiert. Was Apple dokumentiert, sind regulierte Bereiche, die mehr Unterlagen und Zeit erfordern:

• Apps für Bankwesen, Finanzen, Gesundheit, Glücksspiel, Krypto oder Luftverkehr müssen von der juristischen Person eingereicht werden, die den Dienst anbietet (5.1.1(ix));
• für Glücksspiele muss zusätzliche Zeit eingeplant werden (5.3);
• medizinische Apps oder Apps mit lizenzierten Inhalten müssen die entsprechenden Genehmigungen vorlegen.

Eine letzte Einschränkung: Ein MVP ist keine dürftige App. Die Mindestanforderung von Guideline 4.2 gilt ab der ersten Version. Reduzieren Sie die Zahl der Funktionen, nicht deren Qualität.

---

Zusammenfassung: wahr, differenziert zu betrachten, falsch

---

Meine Checkliste vor der Einreichung

Vollständigkeit (2.1)

• Auf Geräten getestet, neueste iOS-Version, iPhone und iPad
• Keine Platzhalterinhalte, keine toten Links
• Backend online, gültiges Demokonto
• In-App-Käufe sichtbar, in der Sandbox funktionsfähig, Wiederherstellung verfügbar

Informationen für die Review

• Notizen: Was die App tut, Hauptablauf, nicht offensichtliche Funktionen, Käufe
• Aktuelle Kontaktdaten in App Review Information
• Video oder Unterlagen beigefügt, wenn die Umgebung schwer nachzubilden ist

Datenschutz und Sicherheit (5.1, 1.2)

• Datenschutzerklärung in App Store Connect und in der App
• Präzise Purpose Strings, wenn möglich System-Picker
• Weitergabe an Dritte (einschließlich KI) angekündigt und eingewilligt
• Kontolöschung in der App
• Bei Nutzerinhalten: Filtern, Melden, Blockieren, Kontakt

Metadaten (2.3)

• Screenshots, die die App in Benutzung zeigen
• Keine unbelegbaren Versprechen, keine gefälschten sozialen Belege
• Kostenpflichtige Käufe klar gekennzeichnet

Strategie

• Erste Version auf das Wesentliche beschränkt, weitergehende Angebote in einem späteren Update
• Mindestens eine Woche Puffer vor dem Starttermin einer neuen App
• Archiv jeder Einreichung: Build, Notizen, Screenshots, Austausch mit App Review
• App-Review-Termin vereinbart, wenn eine Guideline Fragen aufwirft

---

Das wahre Geheimnis: langweilig und ehrlich sein

Man liest manchmal, Apple wolle, dass man die Grenze auslotet. Ich bin anderer Meinung. Die Guidelines sind ein lebendiges Dokument, und Apple räumt ein, dass ein Teil Ermessenssache ist. Aber die Einleitung ist klar: Das Grundprinzip ist ein sicheres Erlebnis für Nutzer, und jeder Versuch, die Review zu täuschen, kommt einen sehr teuer zu stehen.

Im Übrigen besteht bei einer Regel Einigkeit: Seien Sie klar, seien Sie ehrlich, erklären Sie, was Sie tun, und zeigen Sie es. Eine vollständige, verständliche und überraschungsfreie Einreichung kommt innerhalb der normalen Fristen durch. Bei einem Update sind das oft weniger als 48 Stunden. Für eine neue App im Jahr 2026 planen Sie besser eine Woche ein und lassen sich angenehm überraschen.

Da Agenten es jedem ermöglichen, an einem Wochenende eine App einzureichen, wird App Review wieder zu dem, was es am Anfang war: ein Filter. Und das ist gut so. Dieser Filter ermöglicht es einem Nutzer, eine unbekannte App ohne Misstrauen zu installieren, und dieses Vertrauen macht den Wert des App Store für uns Entwickler aus. Die App-Review-Teams bearbeiten Hunderttausende Einreichungen pro Woche; ihnen die Arbeit zu erleichtern heißt auch, sich selbst das Leben leichter zu machen.

Da ist man besser auf der richtigen Seite des Filters.

---

Ich entwickle und veröffentliche Apps seit der Geburt des App Store, für mich selbst, für Start-ups oder für Häuser mit einer Boutique auf den Champs-Élysées. Wenn Sie eine heikle Ersteinreichung, eine soziale App, ein Abomodell oder eine App in einem regulierten Bereich vorbereiten, ist das die Art von Begleitung, die ich mit BNC Consulting anbiete. Schreiben Sie mir.

Kontakt aufnehmen

Und um unter Entwicklern darüber zu sprechen, kommen Sie zur Community ⌘+F: Geschichten über Ablehnungen teilen wir auch bei Meetups, bei einem Kaffee oder einem Abendessen.

Zum Schluss eine feste Umarmung an Raph’, Anders, Erica, Ewelina und alle meine anderen Freunde im App Review-Team, die eine besonders schwierige Arbeit leisten. Eine weitere an Martin, Mac, SiQing und die WWDR-Teams, die oft als Puffer dienen — und an alle anderen auf der ganzen Welt, die ich kenne, aber hier nicht nennen kann.

Danke, dass ihr da seid, um die Nutzer zu schützen. Auch das ist die gute Seite des App Store.

— Clément

---

Offizielle Quellen (abgerufen am 1. November 2026)

• App Review — Apple Developer
• App Review Guidelines (aktualisiert am 16. Oktober 2026)
• Eine beschleunigte Review anfordern
• App Review kontaktieren und einen Anruf anfordern
• Einen App-Review-Termin anfordern

Daten und Presse

• MobileGamer.biz — Review-Zeiten und Zustrom KI-generierter Apps (20. Oktober 2026, mit Apples Antwort und Zahlen)
• 9to5Mac — Anstieg neuer Apps um 84 %
• TweakTown — 560.000 neue Apps im ersten Halbjahr 2026
• RevenueCat — State of Subscription Apps 2026
• iPhoneSoft — AppReviewTimes schließt seine Pforten (März 2019)
• Apple — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (16. Oktober 2026)
• Phillip Shoemaker — Apple approved the fix. Then it called the developer a liar. (30. Oktober 2026)
• 9to5Mac — neue Regeln gegen Nudification und Bait-and-Switch

---

Wie üblich wurde dieser Artikel von Hand auf Französisch geschrieben. Die deutsche Übersetzung und die Illustrationen wurden mit den Werkzeugen von OpenAI erstellt.