Cursor
Cursor applique les project rules au chat, à Composer et aux exécutions de l'agent. Pour une app que vous publiez via WebViewGold, les règles doivent porter le contexte WebView, la syntaxe du pont JavaScript et la checklist des stores, pour que l'agent arrête de proposer des solutions qui ne marchent que dans le navigateur. Voici un modèle en deux fichiers et la façon de l'utiliser.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Les project rules se trouvent dans .cursor/rules/ sous forme de fichiers .mdc : du Markdown avec un court front matter qui décide quand la règle est chargée. alwaysApply: true l'inclut dans chaque conversation ; globs l'attache automatiquement quand des fichiers correspondants sont dans le contexte ; une description seule permet à l'agent de la charger quand il juge la règle pertinente ; et vous pouvez toujours référencer une règle par son nom avec @. L'ancien fichier unique .cursorrules à la racine du dépôt fonctionne encore, mais les nouveaux projets devraient utiliser le dossier, qui permet une règle toujours active et plusieurs règles ciblées.
Cette séparation correspond exactement aux besoins d'une app WebViewGold : le contexte WebView et les règles des stores toujours actifs, et les règles de mise en page mobile attachées uniquement quand l'agent modifie des fichiers d'interface, pour ne pas encombrer le travail sur le backend.
Enregistrez-la sous .cursor/rules/webviewgold-app.mdc. Remplacez les placeholders et supprimez les lignes du pont que vous n'utilisez pas. Chaque schéma provient de la documentation iOS de WebViewGold et de la documentation Android.
---
description: WebView runtime context, WebViewGold bridge and store rules for this app
alwaysApply: true
---
# Runtime
- This web app (production: https://app.example.com) is also published as native iOS and
Android apps with WebViewGold. The native apps load the production URL in a WebView.
There is no separate mobile codebase; never propose React Native, Expo or Capacitor.
- The native app sets the user agent marker `MYAPPNATIVE`. Detect it only via
`isNativeApp()` in `src/lib/platform.ts`.
- Google/Facebook OAuth is handled by the wrapper (Social Login Helper); Sign in with
Apple is handled automatically. Do not open OAuth in new windows or popups.
- When `isNativeApp()`: no "Download our app" or "Add to home screen" banners, no cookie
banner unless legally required, no service worker install prompts.
# WebViewGold bridge (native app only, always with a web fallback)
Call a feature by navigating: `window.location.href = "scheme://..."`. Results arrive
asynchronously as global variables or callbacks; poll with a timeout.
- Push permission prompt: `registerpush://`; status: `checkNativePushPermissions://` -> `nativePushEnabled`
- OneSignal subscription ID: `getonesignalplayerid://` -> `onesignalplayerid`
- Local notification: `sendlocalpushmsg://push.send?s=SECONDS=msg!MESSAGE&!#TITLE&!#URL`
- Share sheet: `shareapp://message?=TEXT&url=URL`
- Haptics: `lighthaptic://`, `mediumhaptic://`, `heavyhaptic://`, `successhaptic://`, `warninghaptic://`, `errorhaptic://`
- Biometrics: `bioauth://` -> iOS callbacks `onBioAuthSuccess()`, `onBioAuthFailure(code, msg)`, `onBioAuthUnavailable()`
- QR scanner: `qrcode://` (scanned URL is loaded); barcode: `barcodescanner://` -> `barcodescanresult`
- Purchases (RevenueCat): `revenuecat://purchase?external_id=USER_ID&product=PRODUCT_ID`;
restore `restoreinapppurchases://`; manage `cancelinapppurchase://`
- App version: `getappversion://` -> `versionNumber`, `bundleNumber`; install ID: `get-uuid://` -> `uuid`
- Full reference: https://www.webviewgold.com/llms-full.txt (read it before using any other scheme)
# Store rules (invariants)
- /privacy and /terms are real routes linked from footer and settings.
- Sign-up exists => Delete account exists (server-side deletion) plus a public /delete-account page.
- Third-party login exists => Sign in with Apple is offered with equal prominence.
- Digital goods, subscriptions and credits in the native app go through `revenuecat://`;
Stripe only for browser users and for physical goods. No external payment links in the app.
- Every fetch has loading, empty, error and retry states; never a blank screen.
- User-generated or AI-generated content has report and block actions.
- No placeholder text, dead links or mixed content.
# Done means
Works in a desktop browser and at 320px; native code behind `isNativeApp()`;
no new store-rule violations; lint and tests pass; summarize device tests I must run.Enregistrez-la sous .cursor/rules/mobile-ui.mdc. Adaptez les globs à l'organisation de vos dossiers.
---
description: Mobile layout rules for screens rendered inside the native WebView apps
globs: src/components/**/*.tsx, src/app/**/*.tsx, src/pages/**/*.tsx, src/**/*.css
alwaysApply: false
---
- Viewport: `width=device-width, initial-scale=1, viewport-fit=cover` must stay in the document head.
- No horizontal overflow between 320px and 1024px; test flex and grid children with `min-width: 0`.
- Tap targets at least 44x44px; spacing between adjacent targets at least 8px.
- Fixed or sticky headers, footers, tab bars and bottom sheets use
`padding-top: env(safe-area-inset-top)` / `padding-bottom: env(safe-area-inset-bottom)`.
- Inputs and selects use `font-size: 16px` or larger (prevents zoom on iOS).
- No hover-only interactions; every hover state has a tap equivalent.
- Images and embeds have explicit width and height or aspect-ratio to avoid layout shift.
- Long lists are paginated or virtualized; a WebView has less memory than a desktop tab.
- Prefer in-app bottom navigation over a hamburger menu in the native app.
- Dark mode: respect `prefers-color-scheme` or provide a setting; never pure white flashes on navigation.
WebViewGold nous a permis d'avoir le temps de mise sur le marché le plus court et le plus efficace jamais possible parmi toutes les autres plates-formes d'application que nous avons essayées au cours des 5 dernières années. Je ne sais pas pourquoi je ne vous ai pas découvert plus tôt, mais je suis vraiment, vraiment content de l'avoir fait. Nous approchons actuellement les 6000 téléchargements d'application sur l'App Store iOS et Google Play Store sans aucun problème!
Évite les trois fausses routes les plus courantes : proposer une réécriture native, casser OAuth avec des popups et embarquer dans l'app des bannières réservées au web. Le marqueur du user agent se définit dans WebViewGold : useragent_iphone / useragent_ipad dans Config.swift, USER_AGENT dans Config.java.
Les schémas exacts et les noms des variables de résultat. Sans ce bloc, Cursor invente un objet window.native ou se rabat sur la Web Share API. La dernière ligne le renvoie vers la documentation complète pour tout ce qui n'est pas listé.
Des invariants, pour qu'ils s'appliquent à chaque tâche future et soient vérifiés à la fin. La règle de paiement évite le refus le plus coûteux (Apple 3.1.1) ; les règles de suppression de compte et de Sign in with Apple évitent les plus fréquents (5.1.1, 4.8).
Attachée automatiquement seulement quand des fichiers d'interface sont dans le contexte, ce qui garde les conversations backend propres. C'est la même checklist que celle qu'appliquent les examinateurs au titre de la guideline 4.0 et de la règle de Google sur les fonctionnalités défaillantes.
En mode agent, Cursor planifie, modifie des fichiers, exécute des commandes et itère. La règle toujours active fait partie de chaque plan : quand vous demandez « un verrouillage Face ID sur la page du portefeuille », le plan prévoit déjà de protéger le code avec isNativeApp(), de naviguer vers bioauth://, d'implémenter les callbacks iOS, de garder un repli par mot de passe sur le web et de conserver une vérification côté serveur. La règle mobile rejoint le contexte dès que l'agent ouvre un fichier de composant.
Deux habitudes rendent le tout fiable. D'abord, ajoutez la documentation WebViewGold comme source de docs dans Cursor (la fonction @Docs accepte une URL ; utilisez https://www.webviewgold.com/llms-full.txt) pour que l'agent puisse lire la section d'une fonctionnalité au lieu de deviner. Ensuite, terminez vos prompts de fonctionnalité par « vérifiez le résultat par rapport à la documentation WebViewGold et aux règles des stores », ce qui oblige l'agent à relire les deux avant de rendre compte. Le guide llms.txt décrit en détail la routine de vérification.
Ajoutez un verrouillage biométrique devant la route /wallet. Suivez les règles du projet : dans l'app native, naviguez vers le schéma biométrique indiqué dans les règles et gérez les callbacks de succès, d'échec et d'indisponibilité ; sur le web, revenez à la saisie du mot de passe. L'état déverrouillé est conservé dans le session storage pendant 5 minutes et le serveur doit toujours vérifier la session à chaque requête sur le portefeuille. Respectez les règles d'interface mobile pour l'écran de verrouillage. Vérifiez ensuite votre résultat par rapport à https://www.webviewgold.com/llms-full.txt et aux règles des stores, et listez ce que vous avez vérifié.
Utilisez le dossier .cursor/rules pour les nouveaux projets ; il prend en charge plusieurs règles ciblées et le front matter qui contrôle quand chacune est chargée. Un ancien fichier .cursorrules fonctionne toujours si vous en avez un.
Les règles concernent les conversations du chat, de Composer et de l'agent. Les complétions en ligne dépendent du code environnant, ce qui est une raison de plus de regrouper isNativeApp() et les appels du pont dans un seul fichier utilitaire bien nommé.
Ajoutez-le comme source de docs (@Docs avec l'URL), référencez-le avec @Web dans un prompt, ou committez-en une copie dans le dépôt et indiquez le chemin dans la règle. Une copie committée est l'option la plus déterministe.
Pour l'app web, oui. Le build natif nécessite Xcode pour iOS, ou le Cloud Builder de WebViewGold, qui compile et envoie les deux apps depuis le navigateur.
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.