Un identifiant par client
Les agences qui publient le même produit pour plusieurs clients utilisent un schéma comme com.agency.clientname, ou mieux, le domaine du client inversé. Ne réutilisez jamais un ID d'un client à l'autre.
De quoi il s'agit et pourquoi c'est définitif
L'identifiant est une chaîne en DNS inversé, par exemple com.yourbrand.appname. iOS l'appelle bundle identifier, Android package name (techniquement l'applicationId). Les utilisateurs ne le voient jamais, mais tous les systèmes qui communiquent avec votre app l'utilisent comme clé primaire : les stores, les services de push, les systèmes d'achat, les fichiers de vérification des deep links et votre propre backend.
App Store Connect fige le bundle ID d'une fiche d'app dès l'envoi du premier build. Google Play fige le package name avec le premier bundle envoyé sur n'importe quel canal, même le test interne, et un package name déjà utilisé sur Play ne peut plus jamais être réutilisé par une autre app, même après la suppression de l'originale. Les projets WebViewGold sont livrés avec des identifiants par défaut (com.webviewgold.myappname sur Android), et ceux-ci sont déjà pris : le renommage est donc la première étape de tout projet.
« Le changer plus tard » signifie donc : une nouvelle fiche d'app, une nouvelle page sur le store, zéro note, et des utilisateurs qui doivent installer une seconde app. Traitez l'identifiant comme un nom de domaine que vous ne pourriez pas transférer.
Des règles de nommage qui conviennent aux deux stores
- Inversez un domaine que vous contrôlez :
com.yourbrand.appname. Il n'a pas besoin de pointer vers un site web, mais il doit être unique, et un domaine qui vous appartient le garantit. - Uniquement des lettres minuscules, des chiffres et des points. Commencez chaque segment par une lettre ; Android refuse les segments qui commencent par un chiffre et n'autorise pas les tirets.
- Au moins deux segments (Android l'exige), trois par convention.
- Évitez les mots-clés Java comme segments (
new,default,class) pour que le projet Android compile sans surprise. - Utilisez la même chaîne sur iOS et Android. Rien ne l'impose, mais RevenueCat, Firebase, OneSignal et vos propres logs sont bien plus lisibles avec une identité unique.
- Laissez de côté les noms de builders, « test », « beta », « v2 » et l'année. L'ID leur survivra à tous.
- N'inversez pas un domaine de plateforme que vous louez (app.lovable, vercel.app). Utilisez le domaine de votre marque, même si la web app vit aujourd'hui sur un sous-domaine.
Tous les endroits où l'identifiant doit concorder
| Système | Champ | Remarques |
|---|---|---|
| App Store Connect | Bundle ID de la fiche d'app | Choisi parmi les App IDs enregistrés dans votre compte développeur ; verrouillé après le premier build |
| Projet Xcode | Bundle Identifier de la cible WebViewGold | Les cibles d'extension doivent l'utiliser comme préfixe, par exemple com.my.app.OneSignalNotificationServiceExtension ; ne changez pas le nom du projet « WebViewGold », la documentation avertit que le renommer cause des problèmes |
| Google Play Console | Package name du bundle envoyé | Verrouillé par le premier envoi sur n'importe quel canal de test |
| Projet Android Studio | applicationId dans build.gradle (renommage via la vidéo de refactoring de la documentation Android sur la publication) | Sauvegardez le projet avant de le renommer |
| Cloud Builder | Champ bundle ID / package name | Définissez-le avant le premier build ; le Cloud Builder gère pour vous la partie Xcode et Gradle |
| RevenueCat | App de l'App Store et app du Play Store | Doit correspondre exactement, sinon les achats échouent sans message |
| Firebase (push, Crashlytics) | Bundle ID iOS et package name Android des apps enregistrées | Définitif une fois enregistré ; GoogleService-Info.plist et google-services.json sont générés pour cet ID précis |
| OneSignal / Pushwoosh | Configuration de l'app | Les certificats et les clés sont émis pour l'App ID |
| Universal Links / App Links | apple-app-site-association (TEAMID.bundleid) et assetlinks.json (package_name) | Une faute de frappe ici casse les magic links sans le moindre message d'erreur |
Mon WebView iOS est enfin approuvé. Merci !!
Les Universal Links et App Links en dépendent
Quand un utilisateur touche un magic link de Supabase ou un lien partagé depuis votre app, iOS et Android décident d'ouvrir ou non votre app en comparant les fichiers de votre domaine avec l'identité de l'app installée. Le fichier apple-app-site-association mentionne TEAMID.com.yourbrand.appname ; assetlinks.json mentionne le package name ainsi que l'empreinte SHA-256 de la clé de signature. Si vous renommez l'app avant le lancement, il suffit de mettre à jour les deux fichiers, ce qui est simple. Si vous la renommez après le lancement, l'ancienne app, toujours installée sur des milliers de téléphones, ne correspond plus et perd ses deep links ; le guide des deep links montre la configuration complète. Le schéma d'URL personnalisé (yourapp://) est indépendant du bundle ID et peut changer à tout moment.
Marque blanche et configurations multi-clients
Une licence par produit final
La licence WebViewGold couvre un produit final personnalisé. Cinq apps clientes sur une plateforme nécessitent cinq licences, et cinq mises à niveau Cloud Builder si vous compilez dans le navigateur.
Publiez sous le compte du client
La guideline 4.3 d'Apple (spam) et les règles de Google sur le contenu répétitif visent les apps identiques publiées depuis un même compte. L'app de chaque client a sa place dans le compte développeur de ce client, avec son propre contenu et sa propre identité visuelle.
Tenez un registre
Un tableur avec client, bundle ID, package name, Team ID, empreinte de la clé de signature et identifiants push. Vous en aurez besoin pour chaque assetlinks.json et chaque projet RevenueCat.
Questions fréquentes
Puis-je changer le bundle ID avant le premier envoi ?
Oui, librement. Dans App Store Connect, vous pouvez même supprimer une fiche d'app qui n'a jamais reçu de build. Tout devient définitif avec le premier build ou bundle envoyé.
Les identifiants iOS et Android doivent-ils être identiques ?
Non, les stores ne les comparent pas. Les garder identiques est une convention qui évite la confusion dans RevenueCat, Firebase et votre backend.
Que se passe-t-il si j'envoie avec le com.webviewgold.myappname par défaut ?
Google Play refuse l'envoi, car le package name existe déjà dans l'app d'un autre développeur. Sur iOS, l'enregistrement de cet App ID échoue pour la même raison. Renommez d'abord.
Le bundle ID apparaît-il quelque part publiquement ?
L'URL du Play Store le contient (play.google.com/store/apps/details?id=com.yourbrand.appname). Les URL de l'App Store utilisent à la place un ID numérique.
J'ai perdu mon domaine. L'identifiant est-il désormais faux ?
Non. L'identifiant n'est qu'une chaîne unique ; il n'a jamais besoin de pointer quelque part. Gardez-le et passez à autre chose.
Trois façons de mettre votre app dans les stores
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.
Faites-le vous-même
$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 principaleCloud Builder
$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 gratuiteFull Service
$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.