Bibliothèque de prompts Claude Code : rendez votre web app prête pour l'App Store et Google Play

Auditez cette web app pour son utilisation dans une app WebView native iOS et Android et corrigez ce que vous trouvez. Vérifiez : balise meta viewport ; aucun débordement horizontal de 320 px à 1024 px ; zones tactiles d'au moins 44 x 44 px ; en-têtes, pieds de page et navigation inférieure fixes avec un padding env(safe-area-inset-top) et env(safe-area-inset-bottom) pour que rien ne se cache derrière l'encoche ou l'indicateur d'accueil ; aucun menu uniquement au survol ; une taille de police d'au moins 16 px dans les champs de saisie pour qu'iOS ne zoome pas ; aucune barre latérale réservée au desktop ; aucun élément qui dépend d'une souris. Rendez aussi le premier affichage rapide : chargez les composants lourds en différé (lazy loading) et affichez un squelette plutôt qu'un écran vide. Listez chaque fichier modifié et tout ce que vous n'avez pas pu corriger automatiquement.

Créez les pages /privacy et /terms de cette app. Inspectez d'abord la base de code et listez chaque catégorie de données personnelles que nous collectons ou traitons réellement : fournisseur d'authentification et ce qu'il stocke, tables de base de données contenant des données utilisateur, SDK d'analytics ou de suivi des erreurs, prestataires de paiement, services de notifications push, API tierces qui reçoivent du contenu utilisateur. Rédigez la politique de confidentialité à partir de cette liste, en langage clair, avec des sections pour les données collectées, la finalité, les tiers, la durée de conservation, les droits des utilisateurs, la suppression du compte (lien vers /delete-account), une adresse e-mail de contact et une mention précisant que les apps iOS et Android chargent ce même service. N'inventez aucune pratique que nous n'avons pas. Liez les deux pages depuis le pied de page et l'écran des réglages, rendez-les lisibles sur un écran de 320 px et marquez d'un TODO chaque affirmation dont vous n'êtes pas sûr, pour que je puisse la confirmer.

La guideline Apple 5.1.1 et Google Play exigent que les utilisateurs qui peuvent créer un compte puissent aussi le supprimer dans l'app. Implémentez ceci : un bouton Supprimer le compte dans les réglages, avec une boîte de dialogue de confirmation qui explique les conséquences ; une fonction côté serveur (edge function, route API ou cloud function qui n'utilise les identifiants admin ou service role que sur le serveur) qui supprime toutes les lignes appartenant à l'utilisateur authentifié, puis l'utilisateur d'authentification lui-même ; en cas de succès, déconnectez l'utilisateur et affichez un écran de confirmation ; une page publique /delete-account qui explique la procédure aux utilisateurs qui n'ont plus l'app installée et propose un contact par e-mail. S'il existe des abonnements, expliquez dans la boîte de dialogue que l'abonnement du store doit être résilié séparément dans les réglages de l'App Store ou de Google Play. Ajoutez des tests pour la fonction serveur si le projet dispose d'un environnement de test.

Les reviewers refusent les apps qui affichent des écrans blancs ou des erreurs brutes (Apple 2.1, Google Play broken functionality). Passez en revue chaque chargement de données et chaque route de cette app et assurez-vous que chacun dispose : d'un état de chargement (squelette ou spinner), d'un état vide avec une phrase utile et une action principale, et d'un état d'erreur avec un message lisible et un bouton Réessayer. Ajoutez une error boundary globale avec un écran de repli convivial. Gérez explicitement les pannes réseau : quand fetch échoue parce que l'appareil est hors ligne, affichez un message qui le dit au lieu d'une erreur générique. Supprimez les erreurs de console et les rejets de promesse non gérés. Listez les routes modifiées.

Nos apps natives iOS et Android chargent cette web app avec un user agent personnalisé qui contient le jeton WebViewGoldApp. Ajoutez un petit utilitaire isNativeApp() qui cherche ce jeton dans navigator.userAgent, ainsi qu'un attribut data ou une classe sur l'élément html (par exemple data-native-app) que le CSS peut cibler. Ensuite, uniquement dans l'app native : masquez le bandeau cookies s'il n'est pas légalement requis pour les utilisateurs de l'app, masquez toute promotion Téléchargez notre app ou Ouvrir dans l'app, masquez l'en-tête du site web et les liens du pied de page vers les pages marketing, masquez les liens externes vers les réseaux sociaux ou ouvrez-les avec target=_blank pour que le wrapper les envoie vers le navigateur du système, et affichez la navigation par onglets en bas à la place du menu desktop. Conservez le comportement normal du site web dans les navigateurs.

Cette app propose la connexion Google (et éventuellement d'autres connexions tierces). La guideline Apple 4.8 exige une option équivalente respectueuse de la vie privée, et Sign in with Apple est la réponse standard. Ajoutez-la avec le fournisseur Apple de notre bibliothèque d'authentification (Supabase Auth, Firebase Auth, Auth.js ou Clerk : détectez celle que nous utilisons et suivez sa procédure documentée pour le fournisseur Apple). Placez le bouton Apple avec la même taille et la même visibilité que le bouton Google, en respectant les directives d'Apple pour ses boutons. Gérez le cas où Apple ne renvoie le nom qu'à la première connexion en l'enregistrant lors de la première authentification. Notez sous forme de checklist dans SETUP-APPLE-LOGIN.md les étapes que je dois effectuer dans l'Apple Developer portal (Services ID, clé, URL de retour). Remarque : dans l'app native, le wrapper WebViewGold détecte automatiquement appleid.apple.com et gère la fenêtre popup, donc aucun code spécifique à l'app n'est nécessaire pour le flux lui-même.

Dans les apps iOS et Android, les produits numériques et les abonnements doivent être vendus par achat intégré (Apple 3.1.1, Google Play billing), pas via notre checkout Stripe. Le wrapper WebViewGold intègre RevenueCat et lance un achat quand la page navigue vers revenuecat://purchase?external_id=USER_ID&product=PRODUCT_ID (l'ID produit tel qu'il apparaît dans la console RevenueCat ; external_id est notre ID utilisateur, pour que RevenueCat puisse attribuer l'achat). Implémentez : quand isNativeApp() vaut true, les boutons Passer à la version supérieure et Acheter définissent window.location.href sur ce schéma avec l'ID de l'utilisateur courant et le produit correspondant ; dans les navigateurs, gardez Stripe. Ajoutez un endpoint serveur qui reçoit les webhooks RevenueCat, vérifie l'en-tête d'autorisation et met à jour les droits (entitlements) de l'utilisateur dans notre base de données, pour que la web app puisse débloquer les fonctionnalités au chargement suivant. Ajoutez un lien Restaurer les achats et un lien Gérer l'abonnement qui explique que les abonnements se gèrent dans les réglages de l'App Store ou de Google Play. N'affichez ni prix Stripe ni liens de paiement externes dans l'app native.

Les apps natives prennent en charge les notifications push via WebViewGold. La demande d'autorisation du système se déclenche quand la page navigue vers registerpush://, et l'état actuel peut être lu en naviguant vers checkNativePushPermissions://, qui injecte peu après une variable JavaScript nativePushEnabled (true ou false). Créez un écran d'activation qui apparaît une seule fois après l'onboarding ou la première connexion, uniquement quand isNativeApp() vaut true : il explique en une phrase ce que nous enverrons (par exemple des mises à jour de commande et des réponses), avec un bouton Activer les notifications qui navigue vers registerpush:// et un lien Plus tard qui mémorise ce choix dans localStorage pendant 30 jours. Dans les réglages, ajoutez une ligne Notifications qui vérifie nativePushEnabled et, si les notifications sont désactivées, affiche un lien qui navigue vers settingsapp:// pour ouvrir les réglages du système. Ne déclenchez jamais registerpush:// sur le tout premier écran de l'app.