Alle Artikel

Apple lehnt nutzlose Apps ab: Die Antwort besteht nicht darin, Wochen daran zu sitzen

· 6 Min. Lesezeit

Am 9. Juni 2026 hat Apple seine Prüfregeln verschärft, um „wertlose“ Apps auszusortieren. Viele lasen darin eine einfache Botschaft: Man müsse künftig wochenlang an einer Anwendung sitzen, damit sie angenommen wird. Das ist falsch. Apple misst nicht die Zeit, die Sie investieren. Apple prüft, ob die App eine Daseinsberechtigung hat.

Was Apple am 9. Juni 2026 geändert hat

Die zentrale Änderung betrifft die guideline 4.3(b). Apple ergänzt dort einen unmissverständlichen Satz:

„Reichen Sie keine Apps ein, die von bereits weithin verfügbaren Angeboten nicht zu unterscheiden sind. Das opportunistische Erstellen von Varianten bestehender Kategorien oder beliebter Apps verschlechtert die Auffindbarkeit im App Store, senkt die Gesamtqualität und schadet sowohl den Nutzern als auch den Entwicklern.“

Apple benennt sogar die Kategorien, die ohne ein wirklich anderes Erlebnis nicht mehr angenommen werden: Dating, Taschenlampe, Soundeffekte, Hintergrundbilder, einfacher Timer, Wahrsagerei. Apps mit Furz- oder Rülpsgeräuschen, Kamasutra oder Trinkspielen ordnet Apple der Kategorie „minderwertig, von geringer Qualität oder ohne Aufwand“ zu.

Das Kriterium ist nicht die investierte Zeit

Das ist der Punkt, den die meisten Kommentare übersehen. Apple lehnt eine App nicht ab, weil sie schnell entstanden ist. Apple lehnt sie ab, weil sie nichts beiträgt. Noch ein Klon fällt durch, selbst wenn er Sie drei Wochen gekostet hat. Eine gezielte App mit einem echten Grund zu existieren, in vier Tagen gebaut, kommt durch.

Der Wert ist also keine Frage der Stunden. Sie können einen Monat lang eine Idee verfeinern, die niemanden interessiert, oder in wenigen Tagen etwas ausliefern, das ein echtes Problem löst. Apple will das Zweite sehen.

Die Klausel, die wirklich alles verändert

Die wichtigste Verschärfung ist nicht die Ablehnung beim Einreichen, sondern das, was danach passiert. Apple behält sich jetzt vor, bereits veröffentlichte Apps zu entfernen:

„Wir können solche Apps künftig aus dem App Store entfernen, wenn sie nicht aktualisiert oder verbessert werden oder wenn sie keine Kunden gewinnen. Wiederholte Einreichungen dieser Art können zum Ausschluss aus dem Apple Developer Program führen.“

Eine App kann also angenommen werden, online bleiben und dann mangels Nutzern verschwinden. Und ein Entwickler, der eine belanglose App nach der anderen einreicht, riskiert seinen Account. Sechs Wochen ins Leere zu polieren, ohne die App je echten Nutzern vorzusetzen, wird damit zur schlechtesten aller Wetten.

Eine Einkaufslisten-App in einer überfüllten Kategorie

Ich habe dieses Jahr eine veröffentlicht, und auf dem Papier ist sie genau die Art App, auf die diese Regeln zielen. Einkaufslisten sind überfüllt. Apples eigene Beispiele nennen Taschenlampen, Hintergrundbilder und einfache Timer, und eine Einkaufsliste wohnt nah genug an dieser Straße, dass man zweimal überlegt, bevor man noch eine baut.

Sie kam bei der ersten Prüfung durch, ohne Ablehnung und ohne eine einzige Nachricht von einem Prüfer.

Prüfverlauf in App Store Connect für TapTap Grocery mit dem Status Review Completed.
App Store Connect. Die obere Zeile ist die Einreichung, die direkt auf Review Completed ging. Die Zeile darunter bin ich, der einen früheren Build zurückzieht, bevor die Prüfung begann, keine Ablehnung.

Sie kam durch, weil sie eine Sache macht, die sonst niemand im Store auf dieselbe Weise macht. TapTap Grocery ist ein Bildschirm und ein Tipp. Sie tippen auf ein großes farbiges Symbol, und der Artikel steht auf der Liste. Es gibt kein Suchfeld, keine Rezeptsammlung, keine Vorratsverwaltung, keinen Barcodescanner, keinen Essensplaner. Ein Kind, das noch nicht lesen kann, kann Äpfel hinzufügen, weil das Bild ein Apfel ist. Sie läuft auf der Apple Watch, wo eine Liste hingehört, wenn beide Hände voll sind.

Die Funktionen, die ich weggelassen habe, sind das ganze Argument. Einkaufs-Apps bekommen mit der Zeit Rezepte und Wochenpläne, weil man danach greift, wenn man einen Grund für einen höheren Preis braucht. Jede Ergänzung kostet einen Tipp, einen Bildschirm oder eine Entscheidung, genau in dem Moment, in dem jemand in der Küche steht und ein Kind am Ärmel zieht. Sie wegzulassen war keine Faulheit. Es ist das Produkt.

Das ist mit einem wirklich anderen Erlebnis gemeint. Es braucht keine neue Kategorie, und es heißt nicht, die Etablierten in der Funktionsliste zu überbieten. Es heißt, eine haltbare Antwort auf die Frage zu haben, die die Prüfung wirklich stellt: Warum gibt es das, wo die anderen schon da sind? Hier lautet die Antwort, dass die anderen nicht ein Tipp und ein Bildschirm sind und es auch nicht werden können, wegen allem, was sie hinzugefügt haben.

Warum ein MVP in wenigen Tagen die richtige Antwort ist

Wenn Apple Nutzen und echte Verwendung belohnt, dann ist die Logik: schnell eine Version ausliefern, die eine Sache gut macht, sie echten Nutzern in die Hand geben und dann iterieren. Nicht wochenlang daran feilen, bevor man überhaupt weiß, ob jemand sie will.

Ein gutes MVP steht auf einem klaren Kern:

  • Eine Hauptfunktion, die wirklich funktioniert, kein Mockup
  • Echte native Funktionen, die eine simple Website in einem webview nicht bieten kann
  • Ein sauberer Einstellungsbildschirm mit Datenschutz und Verwaltung der Benachrichtigungen
  • Eine Möglichkeit zu messen, ob die Leute wiederkommen, um zu entscheiden, was als Nächstes gebaut wird

Dieser Kern lässt sich in wenigen Tagen bauen, wenn man weiß, wohin man will. Der Rest, die Nebenfunktionen und die Grenzfälle, kommt danach, sobald die App bewiesen hat, dass sie jemanden interessiert.

Schnell aus Erfahrung, nicht schnell aus Schlamperei

Es gibt eine Nuance, die man nicht verpassen darf. „In wenigen Tagen ausliefern“ ist nicht dasselbe wie „hinschludern“. Die Apps, die Apple gerade aussortiert, sind genau die, die schnell und ohne Handwerk entstanden sind, oft von vibe coding Werkzeugen generiert. Die Geschwindigkeit rettet sie nicht, ihr fehlender Nutzen verurteilt sie.

Der Unterschied liegt in der Erfahrung. Nach achtzehn Jahren Anwendungsentwicklung weiß man, was die Prüfung besteht und was durchfällt. Man weiß, welche nativen Funktionen ein Reviewer erwartet, wo die guideline 4.2 hakt, warum eine getarnte Web-App auf Dauer nie hält. Man verliert keine Zeit damit, diese Regeln über Ablehnungen neu zu entdecken. Man baut die App gleich beim ersten Mal richtig.

Das heißt schnell ausliefern, ohne schlecht auszuliefern. Man streicht die Verschwendung, nicht die wesentlichen Funktionen. Der Kern ist nie verhandelbar. Was wegfällt, sind die Wochen, die man damit verbringt, etwas zu polieren, das niemand braucht.