App-Store-Ablehnung
Guideline 2.5.2 verbietet Apps, Code herunterzuladen oder auszuführen, der nach dem Review verändert, was die App tut. Eine Web-App in WKWebView ist nicht das, worauf Apple abzielt; eine normale WebViewGold-App ist also sicher. Ärger beginnt, wenn deine App Code ausführt, mit dem sie nicht ausgeliefert wurde: KI-generierte Mini-Apps, Plug-ins von Nutzern oder Hot-Patching-SDKs.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Guideline 2.5.2 verlangt, dass Apps in ihrem Bundle in sich geschlossen sind. Sie dürfen keine Daten außerhalb ihres eigenen Containers lesen oder schreiben und keinen Code herunterladen, installieren oder ausführen, der Features oder Funktionen einführt oder ändert, weder die eigenen noch die einer anderen App. Es gibt eine enge Ausnahme: Lern-Apps, die Programmieren beibringen, dürfen Lernenden erlauben, Code herunterzuladen und auszuführen, solange dieser Code für nichts anderes genutzt wird und der Nutzer den Quellcode vollständig sehen und bearbeiten kann.
Hinter der Guideline steht das Apple Developer Program License Agreement, dessen Regel zu heruntergeladenem interpretiertem Code (in neueren Fassungen Abschnitt 3.3.1(B)) Apple in solchen Fällen zitiert hat. Grob gesagt ist heruntergeladener interpretierter Code nur zulässig, wenn er den Hauptzweck der App nicht ändert, keinen Store für anderen Code oder andere Apps schafft und weder die Signierung noch die Sandbox oder andere Sicherheitsfunktionen umgeht. Den genauen Wortlaut findest du in der aktuellen Fassung des Vertrags in deinem Developer-Account.
Guideline 2.5.6 verlangt, dass Apps, die im Web browsen, WebKit nutzen, und genau das tut WebViewGold: Deine Web-App läuft in WKWebView, Apples eigener Engine, innerhalb der Sandbox der App. Die Website nach der Freigabe zu aktualisieren ist die Art, wie jede webbasierte App funktioniert, und WebViewGold-Apps machen das seit 2014.
Apple geht es um den Zweck, nicht darum, woher die Dateien kommen. Ein Habit-Tracker, der auf seiner Website ein neues Diagramm bekommt, bleibt ein Habit-Tracker. Ein Habit-Tracker, der sich nach der Freigabe per Fernschalter in ein Casino verwandelt, verstößt gegen 2.5.2 und gegen die Regel zu versteckten Funktionen in 2.3.1, egal mit welcher Technik die Änderung kam. Wenn ein Web-Update ändert, was die App ist, liefere es als App-Store-Update mit ehrlichen Review-Notizen aus; der Guide zu Web- und nativen Updates zeigt, welche Änderungen einen neuen Build brauchen.
Die Nachricht sagt typischerweise, dass die App, eine Extension oder ein eingebundenes Framework offenbar Code enthält, der das Verhalten oder die Funktionalität der App nach dem Review ändern kann, oder dass die App Code herunterlädt oder ausführt. Manchmal nennt sie ein Framework aus deinem Projekt; manchmal beschreibt sie eine Funktion, die der Reviewer benutzt hat, zum Beispiel dass Nutzer in der App Apps erstellen und ausführen können oder dass sie ausführbare Plug-ins lädt. Der Reviewer bittet dich, diese Möglichkeit zu entfernen und neu einzureichen.
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
| Was deine App tut | Urteil | Warum |
|---|---|---|
| Lädt deine Web-App von deiner Domain in WKWebView; du deployst die Updates | In Ordnung | Webinhalt in WebKit, derselbe Zweck wie im Review |
Bündelt die Web-App in local-www (uselocalhtmlfolder) oder hält mit zipfiledownloadfromserver eine Offline-Kopie vor | In Ordnung | Deine eigene App, gerendert von WebKit; dieselbe Begründung wie für die Live-Website |
| Eine KI liefert Text, Bilder oder strukturierte Daten, die dein Code rendert | Nach 2.5.2 in Ordnung | Inhalt, kein Code; es gelten die Moderationsregeln von Guideline 1.2 |
| Eine KI oder deine Nutzer erzeugen HTML/JS-Mini-Apps, die in deiner App laufen | Hohes Risiko | Neue Software, die in deiner App läuft: Mindestens die Pflichten aus Guideline 4.7 gelten, und App-Builder wurden 2026 genau dafür abgelehnt |
| Plug-ins oder Erweiterungen, die Nutzer aus einem Katalog installieren | Nur im Rahmen von 4.7 | Index, Moderation, In-App-Kauf für digitale Güter, keine freigegebenen nativen APIs |
| Native Frameworks oder Skripte, die die App zur Laufzeit patchen (Hot-Patching-SDKs) | Abgelehnt | Der klassische 2.5.2-Fall; Apple hat Entwickler schon vor Jahren vor solchen Frameworks gewarnt |
| Ein Remote-Flag, das nach der Freigabe eine andere App einschaltet | Abgelehnt, Entfernung droht | Versteckte Funktionen (2.3.1) und ein geänderter Zweck |
| Ein Programmierkurs, in dem Lernende den Code ausführen, den sie schreiben | Möglich | Bildungsausnahme: Der Code ist vollständig einsehbar und bearbeitbar und wird für nichts anderes genutzt |
Reproduziere die in der Nachricht genannte Funktion im TestFlight-Build. Nennt die Nachricht ein Framework, suche im Xcode-Projekt danach (Podfile, Package Dependencies). Nativer Code, den Cursor oder Claude Code dem WebViewGold-Projekt hinzugefügt hat, ist der erste Verdächtige; die SDKs, die das Projekt mitbringt (OneSignal, Firebase, AdMob, RevenueCat), sind weit verbreitet und nicht das, worum es bei 2.5.2 geht.
Lösche jedes SDK, das Skripte herunterlädt, um natives Verhalten zu ändern, heruntergeladenen Code mit Zugriff auf native APIs auswertet oder Funktionen per Remote Config austauscht. Remote Config darfst du für Texte, Inhalte und A/B-Tests bestehender Funktionen behalten.
Wenn dein Produkt Code erzeugt oder ausführt, lass ihn auf deinem Server laufen und zeige das Ergebnis: eine Ausgabe, ein gerendertes Bild, einen Testbericht, einen Export. Live-Vorschauen kannst du in Safari öffnen, indem du die Vorschau-Domain zu safariwhitelist hinzufügst (Doku zu URL Handling). Eine reine Übergabe an den Browser hat 2026 Berichten zufolge für mindestens einen App-Builder nicht gereicht; betrachte sie also als Risikominderung, nicht als Garantie.
Die URL-Schemes von WebViewGold (Push, Scanner, Kontakte, NFC und so weiter) werden durch Navigationen in der WebView ausgelöst. Läuft von Nutzern oder einer KI erzeugter Code in deinem Hauptdokument, kann er sie genauso auslösen wie dein eigener Code. Rendere generiertes HTML in einem sandboxed iframe auf einem separaten Origin, entferne Links mit Custom Schemes aus der generierten Ausgabe und teste im Build, dass generierte Inhalte keine native Funktion öffnen können.
Ein Absatz: Die App zeigt deine Web-App unter deiner Domain in WKWebView; es wird kein nativer Code heruntergeladen; generierte Inhalte sind Daten, die dein eigener Code rendert; jede Codeausführung findet auf deinem Server statt. Guideline 2.3.1 verlangt ohnehin konkrete Notizen zu neuen Funktionen, und die Vorlage für Review-Notizen gibt dir eine Struktur.
Das Entfernen eines SDKs oder einer nativen Funktion braucht einen neuen Build mit höherer Build-Nummer. Hat sich nur deine Web-App geändert, deploye, prüfe im TestFlight-Build und antworte im Resolution Center.
Wenn deine App HTML anzeigt, das ein Modell oder ein Nutzer erzeugt hat (formatierte Antworten, Berichte, Diagramme), halte es aus deiner Hauptseite heraus. Ein leeres sandbox-Attribut blockiert Skripte, Formulare und Navigation; ein separater Origin hält es von deiner Session fern.
<!-- Hauptseite der App: generiertes HTML nie per innerHTML oder dangerouslySetInnerHTML einfügen -->
<iframe
src="https://render.yourapp-content.com/view?id=abc123"
sandbox=""
referrerpolicy="no-referrer"
style="width:100%;height:70vh;border:0"></iframe>
<!-- sandbox="" = keine Skripte, keine Formulare, keine Top-Navigation.
Mit allow-scripts führst du generierten Code aus: Plane vorher die 4.7-Pflichten und 2.5.2 ein.
Entferne auf der Render-Domain außerdem Custom-Scheme-Links (registerpush://, qrcode:// ...) aus der Ausgabe. -->Nicht jeder Treffer ist ein Problem; viele sind harmlos. Du suchst nach Stellen, an denen Text von einem Modell, einem Nutzer oder einem Remote-Server zu ausführbarem Skript wird.
# Stellen, an denen eine Web-App Code ausführt, den sie nicht mitgebracht hat
grep -rnE "eval\(|new Function\(|srcdoc|dangerouslySetInnerHTML|insertAdjacentHTML|document\.write\(" \
--include=*.{ts,tsx,js,jsx,html,vue,svelte} \
--exclude-dir={node_modules,dist,build,.next} .Erkläre zuerst die Architektur, dann die Änderungen. Reviewer reagieren gut auf eine präzise Beschreibung. Die Vorlage bleibt auf Englisch, weil App Review Englisch liest.
Hello App Review team, Thank you for your feedback on [App name] [version] ([build]). We would like to explain how the app works and what we changed. How the app works: [App name] displays our web app at [https://yourdomain.com] in WKWebView (WebKit). The app does not download or execute native code, and its purpose is the one described in the submission: [one sentence about what the app does]. What we changed: - [We removed the SDK [name], which could modify app behavior at runtime.] - [Users can no longer create and run mini apps inside the app. Generated content is now returned as text and images that our own code displays; code runs only on our servers.] - [Previews of user projects now open in Safari instead of inside the app.] Where to verify: [screen or steps]. [New build: [number].] If any part of the app still raises a concern under Guideline 2.5.2, we would be grateful if you could point us to the specific screen so we can address it directly. Best regards, [Name], [email], [phone]
eval oder new Function auf Modellausgaben.Ja, solange die App den Zweck und die Funktionen behält, mit denen sie geprüft wurde. Bugfixes, neue Inhalte und neue Screens im Rahmen desselben Zwecks sind bei webbasierten Apps normal. Ein geänderter Zweck oder Funktionen, die neue Berechtigungen oder Käufe brauchen, gehören in ein App-Store-Update mit Review-Notizen.
Nein. Ein Chatbot sendet Text und empfängt Text oder Bilder, die dein Code anzeigt; das ist Inhalt. Chatbots werden in Guideline 4.7 erwähnt, und Guideline 1.2 verlangt Filter und Meldefunktionen für generierte Inhalte.
Er lädt eine Offline-Kopie deiner eigenen Web-App herunter, die WebKit rendert, wenn das Gerät keine Verbindung hat. Es ist dieselbe App mit demselben Zweck wie die Live-Website, also gilt dieselbe Begründung wie für die URL. Nutze ihn nicht, um Funktionen auszuliefern, die die geprüfte App nicht hat.
Apps, die Menschen beim Bauen von Apps helfen, gibt es, aber das Ausführen der generierten Apps in der eigenen App ist der Punkt, an dem Reviews 2026 gescheitert sind. Generiere und führe auf deinem Server aus, liefere Ergebnisse als Dateien, Exporte oder Web-Vorschauen und rechne mit einem gründlichen Review. Prüfe den aktuellen Wortlaut von 2.5.2 und 4.7, bevor du die Funktion planst.
Ja, wenn er ausführbaren Code herunterlädt oder lädt, das App-Verhalten anhand von Remote-Anweisungen ändert oder private APIs aufruft. Beschränke native Änderungen auf Config.swift und die dokumentierten WebViewGold-Optionen und lass den KI-Agenten stattdessen an der Web-App arbeiten.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.