APNs (push iOS)

Appwin envoie les push iOS avec ta clé Apple, pas la sienne. Les notifications partent donc de ton identité d'éditeur, et tu gardes la main si tu changes de prestataire.

Une clé APNs .p8 vaut pour toutes les apps de la même équipe Apple, et pour le sandbox comme pour la production. Un seul fichier suffit à plusieurs projets.

Le versant Android est sur FCM.

1. Créer la clé

Sur developer.apple.com : Certificates, Identifiers & Profiles → Keys → +

Nomme la clé (« appwin push »)
Coche Apple Push Notifications service (APNs)
Continue, puis Register
Download : le fichier AuthKey_XXXXXXXXXX.p8 se télécharge

Le .p8 ne se télécharge qu'une fois. Apple ne le régénère pas. Range-le dans ton gestionnaire de mots de passe avant de fermer l'onglet - fichier perdu, il faut révoquer la clé et en créer une autre.

Ne confonds pas cette clé avec la clé App Store Connect API : même format .p8, même portail, deux usages sans rapport. Celle-ci doit avoir APNs coché.

2. Relever les identifiants

Champ	Où le trouver
Key ID	Sur la fiche de la clé, ou dans le nom du fichier `AuthKey_XXXXXXXXXX.p8`
Team ID	Apple Developer → Membership details, ou en haut à droite sous le nom d'équipe
Bundle ID	Xcode → Target → General → Bundle Identifier
Private key	Le contenu du `.p8`, en-têtes comprises

Le contenu du .p8 ressemble à :

Texte brut

-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQg...
-----END PRIVATE KEY-----

Colle-le entier, lignes BEGIN et END incluses. Le plus simple reste Importer un fichier : Appwin lit le .p8 et en déduit le Key ID depuis son nom, ce qui évite de le retaper.

Le Bundle ID doit correspondre à l'App ID déclaré dans Identifiers. Un bundle qui ne correspond pas donne des envois acceptés par Apple mais jamais délivrés.

3. Renseigner dans Appwin

Réglages → Projets → ton app → Intégrations → Apple Push (APNs).

Champ	Valeur
Key ID	`2X9R4HXF34`
Team ID	`A1B2C3D4E5`
Bundle ID	`com.tonstudio.tonapp`
Private Key (.p8)	Contenu du fichier

Sandbox ou production

L'API choisit le serveur Apple selon un indicateur production stocké avec l'intégration : api.push.apple.com s'il est vrai, api.sandbox.push.apple.com sinon. Par défaut, c'est le sandbox.

Cet indicateur n'est pas encore exposé dans le formulaire. Concrètement, les envois visent aujourd'hui le sandbox : un jeton obtenu depuis un build Xcode arrive, un jeton TestFlight ou App Store non. C'est le piège classique du push iOS, et la raison numéro un des « l'envoi est parti, rien n'est arrivé ».

4. Enregistrer le jeton de l'appareil

Une clé côté serveur ne suffit pas : chaque appareil doit déclarer son jeton après avoir obtenu l'autorisation de l'utilisateur.

swift

import AppwinNotifications

func application(
  _ application: UIApplication,
  didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
  let token = deviceToken.map { String(format: "%02x", $0) }.joined()
  Task {
    try? await AppwinCore.registerPushToken(token, platform: "ios")
  }
}

Le jeton arrive en Data : c'est sa forme hexadécimale qu'attend Appwin, d'où la conversion ci-dessus.

Vérifier

Sans clé configurée, l'API simule l'envoi et le journalise plutôt que d'échouer. C'est voulu - on développe le reste du produit sans avoir les clés sous la main - mais ça veut aussi dire qu'une campagne peut sembler partie sans que rien ne soit envoyé.

Contrôle les logs de l'API : un APNs not configured - simulating delivery indique que la clé manque.

Dépannage

Symptôme	Cause probable
Envoi « réussi », rien reçu	Jeton de production, envoi vers le sandbox
`BadDeviceToken`	Jeton d'un environnement, serveur de l'autre
`InvalidProviderToken`	Key ID ou Team ID erroné, ou `.p8` tronqué
`TopicDisallowed`	Bundle ID renseigné différent de celui de l'app
Rien ne part du tout	Clé absente : l'API simule et le dit dans ses logs
Reçu en debug, pas en TestFlight	Même cause que la première ligne

Suite

FCM - le versant Android
Notifications - campagnes, audiences, automatisations