Refus App Store
La guideline 2.5.2 interdit aux apps de télécharger ou d'exécuter du code qui modifie ce qu'elles font après l'examen. Une app web chargée dans WKWebView n'est pas ce que vise Apple : une app WebViewGold classique ne risque donc rien. Les ennuis commencent quand votre app exécute du code qu'elle n'embarquait pas : des mini-apps générées par IA, des plug-ins d'utilisateurs ou des SDK de hot-patching.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
La guideline 2.5.2 demande que les apps soient autonomes dans leur bundle. Elles ne peuvent ni lire ni écrire de données hors de leur propre conteneur, ni télécharger, installer ou exécuter du code qui ajoute ou modifie des fonctionnalités, les leurs ou celles d'une autre app. Il existe une seule exception, étroite : les apps éducatives qui enseignent la programmation peuvent laisser les élèves télécharger et exécuter du code, à condition que ce code ne serve à rien d'autre et que l'utilisateur puisse en voir et en modifier entièrement la source.
La guideline s'appuie sur l'Apple Developer Program License Agreement, dont Apple a cité dans ces affaires la règle sur le code interprété téléchargé (section 3.3.1(B) dans les versions récentes). Dans les grandes lignes, le code interprété téléchargé n'est acceptable que s'il ne change pas la finalité principale de l'app, ne crée pas de boutique pour d'autres codes ou d'autres apps, et ne contourne ni la signature, ni le sandbox, ni les autres mécanismes de sécurité. Consultez l'accord en vigueur dans votre compte développeur pour la formulation exacte.
La guideline 2.5.6 exige que les apps qui naviguent sur le web utilisent WebKit, et c'est exactement ce que fait WebViewGold : votre app web tourne dans WKWebView, le moteur d'Apple lui-même, à l'intérieur du sandbox de l'app. Mettre à jour le site après l'approbation, c'est ainsi que fonctionne toute app basée sur le web, et c'est ce que font les apps WebViewGold depuis 2014.
Ce qui compte pour Apple, c'est la finalité, pas l'origine des fichiers. Une app de suivi d'habitudes qui reçoit un nouveau graphique sur son site reste une app de suivi d'habitudes. La même app qui se transforme en casino par un interrupteur distant après l'approbation enfreint la 2.5.2 et la règle de la 2.3.1 sur les fonctionnalités cachées, quelle que soit la technologie qui a livré le changement. Si une mise à jour web change la nature de l'app, publiez-la sous forme de mise à jour App Store avec des notes pour l'examen honnêtes ; le guide des mises à jour web et natives montre quelles modifications demandent un nouveau build.
La note indique en général que l'app, une extension ou un framework lié semble contenir du code capable de modifier le comportement ou les fonctionnalités de l'app après l'examen, ou que l'app télécharge ou exécute du code. Parfois, elle nomme un framework de votre projet ; parfois, elle décrit une fonctionnalité que l'examinateur a utilisée, par exemple le fait que l'app permet de créer et d'exécuter des apps, ou qu'elle charge des plug-ins exécutables. L'examinateur vous demande de retirer cette capacité et de resoumettre.
Excellent travail! Je n'ai jamais codé quoi que ce soit, mais j'ai réussi à travailler avec cela. Facile et rapide! Avec une grande aide des créateurs!
| Ce que fait votre app | Verdict | Pourquoi |
|---|---|---|
| Charge votre app web depuis votre domaine dans WKWebView ; vous déployez les mises à jour | Accepté | Du contenu web dans WebKit, avec la même finalité que lors de l'examen |
Embarque l'app web dans local-www (uselocalhtmlfolder) ou garde une copie hors ligne avec zipfiledownloadfromserver | Accepté | Votre propre app, rendue par WebKit ; le même raisonnement que pour le site en ligne |
| Une IA renvoie du texte, des images ou des données structurées que votre code affiche | Accepté au regard de la 2.5.2 | Du contenu, pas du code ; les règles de modération de la guideline 1.2 s'appliquent |
| Une IA ou vos utilisateurs génèrent des mini-apps HTML/JS qui tournent dans votre app | Risque élevé | Un nouveau logiciel qui tourne dans votre app : au minimum, les obligations de la guideline 4.7 s'appliquent, et des générateurs d'apps ont été refusés pour cette raison en 2026 |
| Plug-ins ou extensions que les utilisateurs installent depuis un catalogue | Seulement dans le cadre de la 4.7 | Index, modération, achat intégré pour les biens numériques, aucune API native exposée |
| Frameworks natifs ou scripts qui modifient l'app à l'exécution (SDK de hot-patching) | Refusé | Le cas typique de la 2.5.2 ; Apple a mis en garde les développeurs contre ces frameworks il y a des années |
| Un flag distant qui active une autre app après l'approbation | Refusé, risque de retrait | Fonctionnalités cachées (2.3.1) et finalité modifiée |
| Un cours de programmation où les élèves exécutent le code qu'ils écrivent | Possible | Exception éducative : le code est entièrement visible et modifiable, et ne sert à rien d'autre |
Reproduisez sur le build TestFlight la fonctionnalité citée dans la note. Si la note nomme un framework, cherchez-le dans le projet Xcode (Podfile, Package Dependencies). Le code natif que Cursor ou Claude Code a ajouté au projet WebViewGold est le premier suspect ; les SDK livrés avec le projet (OneSignal, Firebase, AdMob, RevenueCat) sont très répandus et ne sont pas visés par la 2.5.2.
Retirez tout SDK qui télécharge des scripts pour modifier le comportement natif, évalue du code téléchargé avec accès aux API natives ou change des fonctionnalités via une configuration distante. Gardez la configuration distante pour les textes, le contenu et les tests A/B de fonctionnalités existantes.
Si votre produit génère ou exécute du code, faites-le tourner sur votre serveur et affichez le résultat : une sortie, une image rendue, un rapport de test, un export. Vous pouvez ouvrir les aperçus en direct dans Safari en ajoutant le domaine de l'aperçu à safariwhitelist (documentation URL Handling). Un simple renvoi vers le navigateur n'aurait pas suffi pour au moins un générateur d'apps en 2026 : voyez-y une réduction du risque, pas une garantie.
Les URL schemes de WebViewGold (push, scanners, contacts, NFC, etc.) sont déclenchés par des navigations dans la WebView. Si du code généré par les utilisateurs ou par une IA tourne dans votre document principal, il peut les déclencher exactement comme votre propre code. Affichez le HTML généré dans une iframe sandboxée sur une origine distincte, retirez de la sortie générée les liens à scheme personnalisé, et vérifiez sur le build que le contenu généré ne peut ouvrir aucune fonctionnalité native.
Un paragraphe suffit : l'app affiche votre app web sur votre domaine dans WKWebView ; aucun code natif n'est téléchargé ; le contenu généré se compose de données affichées par votre propre code ; toute exécution de code a lieu sur votre serveur. La guideline 2.3.1 demande de toute façon des notes précises sur les nouvelles fonctionnalités, et le modèle de notes pour l'examen vous donne une structure.
Retirer un SDK ou une fonctionnalité native demande un nouveau build avec un numéro de build plus élevé. Si seule votre app web a changé, déployez, vérifiez sur le build TestFlight et répondez dans le Resolution Center.
Si votre app affiche du HTML produit par un modèle ou par un utilisateur (réponses mises en forme, rapports, graphiques), tenez-le à l'écart de votre page principale. Un attribut sandbox vide bloque les scripts, les formulaires et la navigation ; une origine distincte le tient éloigné de votre session.
<!-- Page principale de l'app : n'injectez jamais de HTML généré avec innerHTML ou dangerouslySetInnerHTML -->
<iframe
src="https://render.yourapp-content.com/view?id=abc123"
sandbox=""
referrerpolicy="no-referrer"
style="width:100%;height:70vh;border:0"></iframe>
<!-- sandbox="" = pas de scripts, pas de formulaires, pas de navigation de premier niveau.
Ajouter allow-scripts revient à exécuter du code généré : prévoyez d'abord les obligations de la 4.7 et de la 2.5.2.
Sur le domaine de rendu, retirez aussi de la sortie les liens à scheme personnalisé (registerpush://, qrcode:// ...). -->Tous les résultats ne posent pas problème ; beaucoup sont inoffensifs. Vous cherchez les endroits où du texte venu d'un modèle, d'un utilisateur ou d'un serveur distant devient un script exécutable.
# Les endroits où une app web exécute du code qu'elle n'embarquait pas
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} .Expliquez d'abord l'architecture, puis les modifications. Les examinateurs réagissent bien à une description précise. Le modèle reste en anglais, la langue de travail des examinateurs.
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 ni de new Function sur la sortie du modèle.Oui, tant que l'app garde la finalité et les fonctionnalités avec lesquelles elle a été examinée. Corrections de bugs, nouveaux contenus et nouveaux écrans au service de la même finalité sont la norme pour les apps basées sur le web. Un changement de finalité, ou des fonctionnalités qui demandent de nouvelles autorisations ou de nouveaux achats, relèvent d'une mise à jour App Store avec des notes pour l'examen.
Non. Un chatbot envoie du texte et reçoit du texte ou des images que votre code affiche : c'est du contenu. Les chatbots sont cités dans la guideline 4.7, et la guideline 1.2 demande le filtrage et le signalement du contenu généré.
Il télécharge une copie hors ligne de votre propre app web, que WebKit affiche quand l'appareil n'a pas de connexion. C'est la même app, avec la même finalité que le site en ligne : le même raisonnement que pour l'URL s'applique donc. Ne vous en servez pas pour livrer des fonctionnalités que l'app examinée ne possède pas.
Des apps qui aident à créer des apps existent, mais c'est l'exécution des apps générées à l'intérieur de votre propre app qui a fait échouer des examens en 2026. Générez et exécutez sur votre serveur, livrez les résultats sous forme de fichiers, d'exports ou d'aperçus web, et attendez-vous à un examen minutieux. Vérifiez la formulation actuelle de la 2.5.2 et de la 4.7 avant de concevoir la fonctionnalité.
Oui, s'il télécharge ou charge du code exécutable, modifie le comportement de l'app sur instruction distante ou appelle des API privées. Limitez les modifications natives à Config.swift et aux options documentées de WebViewGold, et laissez plutôt l'agent IA travailler sur l'app web.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.