Kurz gesagt
Kann eine mit KI gebaute App in die Stores?
Eine App mit KI zu bauen ist in den Store-Regeln nicht verboten; niemand fragt, welches Werkzeug den Code schrieb. Abgelehnt wird nicht das Werkzeug, sondern das Ergebnis: dünne Hüllen um eine Website verstoßen gegen Apples Mindestfunktionalität, nahezu identische Vorlagenderivate gegen die Spam-Regel. Vor der Einreichung müssen zudem Datenschutzerklärung, Datensicherheitsformular und ein Endpunkt zur Kontolöschung bereitstehen.
Sind mit KI gebaute Apps verboten?
Nein. Es gibt keine Regel „Code aus Werkzeug X wird nicht akzeptiert“, und niemand fragt im Review, welchen Editor Sie benutzt haben. Bewertet wird das Produkt selbst: was es tut, wie es aussieht, was es dem Nutzer gibt.
Das heißt nicht „also kein Problem“. Der typische Output von KI-Werkzeugen ähnelt genau den zwei Dingen, gegen die die Store-Regeln geschrieben wurden: einer dünnen Hülle um eine Website und einer Vorlage, mit kleinen Änderungen vervielfältigt. Die Ablehnung kommt nicht vom Werkzeug, sondern von dieser Ähnlichkeit.
Suchanfragen, die diese Seite beantwortet
- ki generierte app veröffentlichen
- app abgelehnt richtlinie 4.3 spam
- app abgelehnt mindestfunktionalität
- no code app store ablehnung
- website in app umwandeln abgelehnt
- mit ki gebaute app freigabe
- app ohne programmieren veröffentlichen
Welche Regel greift, und warum?
Zwei Richtlinien entscheiden. Die Mindestfunktionalität verlangt Funktionen, Inhalte und UI, die über eine neu verpackte Website hinausgehen; in den Worten der Regel gehört eine App, die nicht „app-like“ ist und keinen bleibenden Nutzen bietet, nicht in den App Store. Die Spam-Regel zielt auf dieselbe App unter verschiedenen Identitäten, und ihre Begründung ist offen: Unnötige Apps erschweren Nutzern das Finden.
Eine dritte Regel wird in KI-Produkten leicht verletzt: Apps sollen in ihrem Bundle eigenständig sein und dürfen keinen Code nachladen und ausführen, der Funktionen einführt oder ändert. Wer einen Fluss baut, der ein vom Modell erzeugtes Skript lädt und ausführt, überschreitet diese Linie unabhängig von der Absicht.
| Was Sie gebaut haben | Nächste Regel | Was tun |
|---|---|---|
| Hülle um die eigene Website | Mindestfunktionalität | Echte gerätenahe Funktion ergänzen |
| Aus Vorlage abgeleitete App | Spam | Eigene Marke, Icon, echte Features |
| Viele Versionen derselben App | Spam | In einer App zusammenführen |
| Modell-Output als Code ausführen | Codeausführung | Funktion in die App holen |
| Daten an KI-Dienst senden | Datenangabe | Im Formular und in Labels angeben |
Was ändert sich bei Google Play?
Bei Play liegt die Ablehnung meist an einer fehlenden Angabe, nicht an Codequalität. Das Datensicherheitsformular muss alles beschreiben, was die App erhebt und teilt — auch das, was die genutzten Drittbibliotheken erheben, nicht nur Ihr eigener Code. Bei einer App, die einen KI-Dienst aufruft, ist das leicht übersprungen und schwer zu reparieren.
Das Zweite ist die Kontolöschung. Lassen sich in Ihrer App Konten anlegen, verlangt Google sowohl einen In-App-Löschpfad als auch einen Weblink, den Nutzer ohne Installation erreichen. Dieser Link wird im Review von außen geprüft; funktioniert er nicht, wird das Release abgelehnt.
Acht Dinge, die vor der Einreichung fertig sein müssen
- Ein erreichbarer Link zur Datenschutzerklärung — die Seite muss wirklich laden.
- Ein ausgefülltes Datensicherheitsformular, inklusive der Erhebungen durch Drittbibliotheken.
- Bei Konten: ein In-App-Löschpfad und ein von außen erreichbarer Löschlink.
- Ein Testkonto samt Zugangsdaten für das Review-Team.
- Mindestens eine Funktion, die eine Gerätefähigkeit nutzt und im Browser nicht existiert.
- Eigenes Icon, eigener Name und eigene Store-Assets; keine Screenshots aus Vorlagen.
- Werden digitale Inhalte in der App verkauft: ein an das Store-Zahlungssystem angebundener Fluss.
- Ein sinnvoller Offline-Screen — keine leere weiße Seite.
Wie weit allein, und wann braucht es ein Team?
KI-Werkzeuge haben das Prüfen einer Idee verbilligt, und das ist ein echter Gewinn: Sie stehen binnen einer Woche vor Nutzern. Die Grenze zeigt sich dort, wo ein Fehler der App jemandem schadet. In einem Fluss, der Geld, Identität, Gesundheits- oder personenbezogene Daten berührt, ist ein Bug kein Bug mehr, sondern eine Haftung.
Die praktische Unterscheidung: Ein Prototyp beantwortet „funktioniert es“, ein Produkt beantwortet „was passiert, wenn es schiefgeht“. Fehlt Ihnen die zweite Antwort, braucht es ein Team — und dann ist eine Neuentwicklung selten nötig; meist genügt die fehlende Schicht.
Quellen
- 01App Store Review GuidelinesApple · 2025
- 02Provide information for Google Play's Data safety sectionGoogle Play Console Help · 2026
- 03Provide a way for users to request account and data deletionGoogle Play Console Help · 2026