Apple lehnt Vibe-Coded-Apps ab. Das Signal reicht weit über den App Store hinaus.

Apple hat still und leise begonnen, eine bestimmte Kategorie von Einreichungen aus dem App Store zu entfernen und abzulehnen: Apps, die mit Tools für Vibe Coding gebaut wurden — jene Dienste, die aus wenigen Prompts ein funktionierendes Produkt generieren, ohne echten Code. Die Financial Times hat den Trend diese Woche dokumentiert, und er wiegt schwerer als jede einzelne Ablehnung.

Die Argumentation ist nicht KI-feindlich. Apple beruft sich auf dieselben Review-Guidelines wie seit Jahren: Mindestqualität, echte Funktionalität, keine Täuschung darüber, was die App wirklich tut. Was sich geändert hat, ist die Menge an Einreichungen, die diese Prüfungen nicht bestehen — und woher sie kommen.

Der App Store ist nicht der interessanteste Teil der Geschichte. Interessant ist, was sich zeigt, wenn man ein Produkt ausliefert, das eher generiert als entwickelt wurde — auf jeder Plattform mit einem Prüfer am Eingang.

Was App Review wirklich tut

Die Ablehnungen drehen sich um eine Handvoll Guideline-Nummern, die jeder geübte Entwickler im Schlaf kennt. 4.2.1 zielt auf nicht funktionierende Apps oder solche, die im Grunde nur Doppelgänger sind. 4.3 deckt Spam ab — einschließlich Apps, die ein populäres Produkt mit geringfügigen Abwandlungen kopieren. 5.2 zielt auf Apps, die den Nutzer darüber täuschen, was die Software tatsächlich macht. Keine dieser Regeln ist neu. Neu ist die Menge der Einreichungen, die daran scheitern.

Apple hat keine Zahlen veröffentlicht. Nach dem, was die FT rekonstruiert hat, sieht App Review Wellen von Einreichungen, die sichtbar an denselben Prüfungen und auf dieselbe Weise scheitern: Oberflächen, die auf Screenshots elegant wirken, beim ersten Start aber zusammenbrechen; „KI"-Funktionen, die sich auf einen Modellaufruf mit UI-Verpackung reduzieren; Listings, die Namen und Icon einer beliebten App übernehmen, das Produkt aber halb fertig ist. Die Prüfer müssen nicht weit suchen.

Warum Vibe-Coded-Apps an dieser Prüfung scheitern

Vibe Coding glänzt bei den ersten achtzig Prozent eines Produkts. Login-Screen, Listenansicht, Einstellungsseite, Onboarding-Flow — das Modell hat tausende davon gesehen und stellt eines in wenigen Minuten zusammen. Wo es entgleist, sind die letzten zwanzig Prozent: die Arbeit, die niemand spezifizieren mag und die das Modell von sich aus nicht vorschlägt.

Genau diese letzten zwanzig Prozent fallen einem Prüfer zuerst auf. Die Tastatur, die das Eingabefeld verdeckt. Der Netzwerkaufruf, der ohne Timeout hängenbleibt. Der leere Zustand, der mit Lückenfüllertext ausgeliefert wird. Die Berechtigung, die die App anfragt, ohne sie wirklich zu brauchen — weil das Modell sie aus einer Vorlage übernommen hat, in der sie nötig war.

Einige wiederkehrende Muster bei den Ablehnungen:

• Dünne Hüllen um ein LLM ohne eigene Funktionalität — der KI-Aufruf ist das Produkt, drum herum ist kaum etwas.
• Visuelle Klone beliebter Apps, deren darunterliegende Logik halbfertig oder gar nicht vorhanden ist.
• „KI-X"-Listings — KI-Fotoeditor, KI-Kalender, KI-Todo — bei denen der KI-Teil ein API-Aufruf ist und der Rest kaputt.
• Berechtigungen, Entitlements und SDK-Einbindungen, die per Vorlage übernommen wurden und die der Entwickler nicht wirklich braucht — weil das Modell sie aus einem Template eingeschleust hat.

Keiner dieser Fehlermodi ist neu. App Review fängt seit fünfzehn Jahren dieselben Dinge ab. Neu sind die geringen Produktionskosten — daher kommt jetzt viel mehr auf einmal an, und die Prüfung wird zum Ausgleich strenger. Die Latte steigt, weil der Boden gefallen ist.

Die Lehre heißt Plattformrisiko

Apple ist das sichtbarste Beispiel, weil Apple den einzigen ernstzunehmenden Vertriebskanal für iPhone-Software kontrolliert. Dieselbe Dynamik gibt es überall, wo es einen Gatekeeper gibt — Play Store, Chrome Web Store, GPT Store, Shopify-App-Marketplace, überall wo ein Produkt die Freigabe eines Dritten braucht, um seine Nutzer zu erreichen. Die Regeln ändern sich selten. Wenn sie sich ändern, ändern sie sich für alle in Ihrer Kategorie gleichzeitig.

Für alle, die KI-gestützte Software ausliefern, ist die praktische Folge nicht, diese Tools nicht mehr zu nutzen. Es ist, im Hinterkopf zu behalten, dass „in einem Wochenende gebaut" und „ein Produkt, das einen Review-Prozess übersteht" zwei unterschiedliche Aussagen sind — und die zweite von Anfang an einzuplanen.

Praktisch heißt das, präzise zu sein, was das Produkt für den Nutzer tut — „KI-gestützt" ist ein Marketingwort, kein Wertversprechen. Es heißt, in die Teile zu investieren, in denen Vibe-Coding-Tools am schwächsten sind und auf die Prüfer am genauesten schauen. Es heißt, die einschlägigen Guidelines vor der Einreichung zu lesen — nicht nach der Ablehnungs-E-Mail. Und es heißt, das gesamte Unternehmen nicht auf einen einzigen Vertriebskanal zu setzen, weil dieser Kanal seine Regeln früher oder später ändern wird.

KI-gestützte Entwicklung wird nicht langsamer. Die Latte, etwas auszuliefern, wird weiter fallen. Die Latte, etwas auszuliefern, das eine Prüfung — und einen echten Nutzer — übersteht, bewegt sich in die andere Richtung. Beides kann gleichzeitig zutreffen. Genau diese Lücke lohnt es vorauszudenken.