Comment créer une page de liste d'attente pour une application mobile avant sa sortie sur l'App Store

Placez sur la landing page de votre app un formulaire de liste d'attente qui demande quel téléphone la personne utilise et si elle veut tester en avant-première. Envoyez les testeurs iPhone dans un groupe TestFlight avec un webhook et l'API App Store Connect, et chargez les testeurs Android dans un test fermé Google Play à partir d'un export. Le jour du lancement, envoyez à chaque groupe le lien vers sa boutique.

Avant qu'une app ne soit sur une boutique, il n'y a pas de bouton d'installation vers lequel envoyer les gens. Une liste d'attente sur votre propre landing page entretient leur intérêt d'ici là, et remplit un second rôle que les boutiques ne remplissent pas : trouver les testeurs dont vous avez besoin avant le lancement.

Ce qui change pour une application mobile

• Deux boutiques, deux listes. L'e-mail de lancement renvoie vers l'App Store ou Google Play, et les invitations de test passent par TestFlight ou un test fermé Play. Il vous faut connaître la plateforme de chaque personne pour envoyer le bon lien.
• Les testeurs doivent correspondre au compte de la boutique. TestFlight envoie une invitation par e-mail à n'importe quelle adresse. Un test fermé Play n'accepte que les comptes Google de sa liste : un testeur Android inscrit avec une adresse professionnelle ne peut donc pas installer le build.
• Google Play peut exiger des testeurs avant le lancement. Les comptes développeur personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs restés inscrits 14 jours d'affilée avant de pouvoir publier en production. Une liste d'attente est l'endroit d'où viennent ces 12 personnes.
• Les boutiques ont leurs propres outils d'avant-lancement. Ils valent la peine d'être utilisés à côté d'une liste d'attente, pas à sa place. Voir la comparaison ci-dessous.

Les champs d'une liste d'attente d'app

Demandez d'abord la plateforme, car elle change le sens du champ e-mail. Le modèle de téléphone est facultatif et vous indique sur quels appareils tester. La case bêta distingue les personnes qui veulent tester de celles qui veulent l'e-mail de lancement.

Le formulaire

Le formulaire fonctionne en HTML simple sur n'importe quelle landing page. Le script fait deux petites choses : il présélectionne la plateforme d'après le navigateur du visiteur, et n'affiche l'indication sur le compte Google qu'aux utilisateurs Android.

<form id="app-waitlist" action="https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx" method="post">
  <fieldset>
    <legend>Which phone do you use?</legend>
    <label><input type="radio" name="platform" value="iphone" required> iPhone</label>
    <label><input type="radio" name="platform" value="android"> Android</label>
  </fieldset>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" inputmode="email" required>
  <p id="email-hint" hidden>Use the Google account you sign in to Google Play with.</p>

  <label for="first_name">First name</label>
  <input id="first_name" name="first_name" autocomplete="given-name" maxlength="60">

  <label for="device">Phone model</label>
  <input id="device" name="device" maxlength="80" placeholder="iPhone 15, Pixel 8">

  <label><input type="checkbox" name="beta" value="true"> Invite me to test the app before launch</label>
  <input name="_gotcha" type="text" tabindex="-1" autocomplete="off" hidden>
  <button>Join the waitlist</button>
</form>

<script>
  const form = document.getElementById("app-waitlist");
  const agent = navigator.userAgent;
  const guess = /iPhone|iPad/.test(agent) ? "iphone" : /Android/.test(agent) ? "android" : null;
  if (guess) form.querySelector(`[name="platform"][value="${guess}"]`).checked = true;
  const hint = () => {
    document.getElementById("email-hint").hidden = form.platform.value !== "android";
  };
  form.addEventListener("change", hint);
  hint();
</script>

• La supposition ne fait que présélectionner un radio. Les gens peuvent la changer, et sans le script rien n'est sélectionné : required les oblige alors à choisir.
• inputmode="email" et autocomplete="email" comptent ici plus qu'ailleurs : la plupart des visiteurs de la landing page d'une app sont sur téléphone.
• Réglez Redirect after submit sur une page de remerciement qui explique la suite pour chaque plateforme. Pour une version du formulaire avec un framework, voir le guide principal et ajoutez ces champs.

Diriger les testeurs vers chaque boutique

iPhone : ajouter des testeurs à TestFlight

Dans App Store Connect, créez un groupe de test externe et une clé d'API sous Users and Access › Integrations, avec le rôle App Manager ou Admin. Ajoutez ensuite un relais qui écoute le webhook submission.created d'Ikiform. Celui-ci est un route handler Next.js qui utilise jose pour signer le jeton d'Apple ; il tourne sur n'importe quel serveur doté de fetch.

import { verifyWebhook, WebhookVerificationError } from "@ikiform/sdk/webhooks";
import { importPKCS8, SignJWT } from "jose";

async function appStoreToken() {
  const key = await importPKCS8(process.env.ASC_PRIVATE_KEY!, "ES256");
  return new SignJWT({})
    .setProtectedHeader({ alg: "ES256", kid: process.env.ASC_KEY_ID!, typ: "JWT" })
    .setIssuer(process.env.ASC_ISSUER_ID!)
    .setAudience("appstoreconnect-v1")
    .setIssuedAt()
    .setExpirationTime("15m")
    .sign(key);
}

export async function POST(request: Request) {
  const payload = await request.text();
  try {
    const event = await verifyWebhook({ payload, headers: request.headers, secret: process.env.IKIFORM_WEBHOOK_SECRET! });
    if (event.type !== "submission.created") return new Response(null, { status: 204 });
    const { email, first_name, platform, beta } = event.data.fields;
    if (platform !== "iphone" || beta !== true) return new Response(null, { status: 204 });

    const response = await fetch("https://api.appstoreconnect.apple.com/v1/betaTesters", {
      method: "POST",
      headers: { authorization: `Bearer ${await appStoreToken()}`, "content-type": "application/json" },
      body: JSON.stringify({
        data: {
          type: "betaTesters",
          attributes: { email: String(email), firstName: first_name ? String(first_name) : undefined },
          relationships: { betaGroups: { data: [{ type: "betaGroups", id: process.env.ASC_BETA_GROUP_ID! }] } },
        },
      }),
    });
    if (response.ok || response.status === 409) return new Response(null, { status: 204 });
    return new Response(`App Store Connect answered ${response.status}`, { status: 502 });
  } catch (error) {
    if (error instanceof WebhookVerificationError) return new Response(error.reason, { status: 400 });
    throw error;
  }
}

• ASC_PRIVATE_KEY est le contenu du fichier .p8 fourni par Apple, sauts de ligne compris. ASC_KEY_ID et ASC_ISSUER_ID sont sur la même page.
• Les jetons d'Apple durent au plus 20 minutes : le relais en signe donc un nouveau à chaque livraison.
• Un 409 signifie qu'Apple a refusé la modification pour cause de conflit, souvent parce que l'adresse est déjà testeuse. Le relais le considère comme fait : si un testeur ne reçoit jamais d'invitation, vérifiez le groupe dans App Store Connect. Tout autre échec répond 502, et Ikiform réessaie la livraison.
• TestFlight autorise jusqu'à 10 000 testeurs externes par app. Le premier build donné à un groupe externe passe par la Beta App Review, et chaque build expire après 90 jours.

Ajoutez l'URL du relais sous Webhooks dans Ikiform et copiez le secret whsec_ dans IKIFORM_WEBHOOK_SECRET. Un espace de travail peut avoir 3 endpoints : celui-ci peut donc tourner à côté d'un relais qui alimente votre outil d'e-mailing.

Android : remplir un test fermé

L'API de publication de Google Play gère les testeurs des tests fermés via Google Groups, pas par adresses individuelles : ce côté est donc un export hebdomadaire. Exportez la liste avec Export CSV, filtrez-la dans un tableur sur platform = android et beta = true, et ajoutez les e-mails à la liste d'e-mails du test fermé sous Test and release › Testing › Closed testing › Manage track › Testers dans la Play Console. Envoyez ensuite à ces personnes le lien d'inscription au test depuis votre outil d'e-mailing.

Si vous visez l'exigence des 12 testeurs, invitez-en plus de 12. Les personnes qui se désinscrivent ou ne s'inscrivent jamais ne comptent pas, et les 14 jours exigent 12 testeurs inscrits pendant toute la période.

Le jour du lancement

Exportez toute la liste et répartissez-la par platform. Envoyez à chaque moitié un e-mail avec un seul lien de boutique. Les personnes qui ont choisi iPhone n'ont pas besoin du lien Play, et un seul e-mail avec deux badges perd des clics sur un petit écran. Si vous avez collecté device, comparez vos rapports de crash aux modèles indiqués avant d'envoyer.

Vérifiez que tout fonctionne

1. Dans Allowed domains du formulaire, ajoutez le domaine de votre site, plus localhost pendant le développement. Laissez vide pour accepter les envois de partout.
2. Ouvrez la page sur un téléphone. La bonne plateforme est présélectionnée, et sur Android l'indication sur le compte Google s'affiche.
3. Envoyez en tant que testeur iPhone. La soumission affiche platform à iphone et beta à true.
4. Ouvrez l'endpoint du relais sous Webhooks. La livraison affiche succeeded, et l'adresse figure dans votre groupe TestFlight.
5. Envoyez en tant que testeur Android, exportez le CSV et vérifiez que la ligne ressort avec le filtre platform réglé sur android.
6. Envoyez avec le honeypot rempli, _gotcha=bot. L'envoi reçoit quand même une réponse de succès, mais la soumission est stockée comme spam et n'envoie ni e-mail ni webhook.

Pièges

Questions