Jede iOS-Push-Benachrichtigungs-Integration beginnt am selben Punkt: Sie muss dem Apple Push Notification Service beweisen, dass Sie berechtigt sind, die Benutzer Ihrer App zu benachrichtigen. Apple bietet Ihnen zwei Möglichkeiten, dies zu tun – einen APNs-Authentifizierungsschlüssel (.p8) oder ein APNs-Zertifikat (.p12) – und der Unterschied zwischen ihnen ist der Unterschied zwischen einer Anmeldeinformation, die Sie einmal konfigurieren, und einer, die Sie jedes Jahr erneuern müssen, oft zum ungünstigsten Zeitpunkt.
Diese Anleitung erklärt, wie die APNs-Authentifizierung tatsächlich funktioniert, wann ein .p8-Schlüssel im Vergleich zu einem .p12-Zertifikat verwendet werden sollte und welche wenigen Fehler darauf zurückzuführen sind, dass dies falsch gemacht wurde.
Wie die APNs-Authentifizierung funktioniert
Wenn Ihr Push-Anbieter – PushEngage oder Ihr eigener Server – eine Benachrichtigung sendet, stellt er eine Verbindung zur APNs-Anbieter-API von Apple her und muss zwei Dinge beweisen: dass er berechtigt ist, in Ihrem Namen zu senden, und dass er berechtigt ist, die Bundle-ID Ihrer App anzusprechen (in APNs-Begriffen das „Thema“). Der .p8-Schlüssel und das .p12-Zertifikat sind nur zwei verschiedene Möglichkeiten, dies zu beweisen.
Die Geräte-Seite ist getrennt. Ihre App registriert sich bei APNs und erhält einen Geräte-Token – dieser Teil ändert sich nie, unabhängig davon, welche Anmeldeinformationen Ihr Anbieter verwendet. Die Authentifizierung ist ausschließlich eine Angelegenheit zwischen Server und Apple, weshalb Sie die Methoden wechseln können, ohne Ihre App-Binärdatei zu berühren.
Der .p8-Authentifizierungsschlüssel (verwenden Sie diesen)
Der .p8 ist ein Token-Signierschlüssel. Ihr Anbieter verwendet ihn, um kurzlebige JSON Web Tokens zu erstellen, die jede Verbindung zu APNs authentifizieren. Seine Eigenschaften machen ihn zur Standardwahl für fast jeden:
- Er läuft nie ab. Keine jährliche Erneuerung, keine Push-Ausfälle an einem vergessenen Datum.
- Ein Schlüssel deckt jede App in Ihrem Entwicklerkonto ab. Wenn Sie eine zweite App veröffentlichen, authentifiziert derselbe Schlüssel diese.
- Er funktioniert sowohl für Entwicklungs- als auch für Produktionsumgebungen – keine Sandbox/Produktions-Zertifikatspaare.
- Er wird als drei Werte übertragen: die .p8-Datei selbst, die 10-stellige Schlüssel-ID und Ihre Team-ID.
Zwei Dinge, die Sie wissen sollten, bevor Sie einen erstellen. Apple beschränkt Sie auf zwei aktive APNs-Schlüssel pro Konto. Große Organisationen sollten die Erstellung von Schlüsseln daher als bewusste Handlung betrachten und nicht als Gewohnheit pro Projekt. Und die .p8-Datei kann nur einmal heruntergeladen werden, zum Zeitpunkt der Erstellung – speichern Sie sie an einem Ort, an dem Ihr Team sie finden kann, denn Apple wird sie Ihnen nicht noch einmal geben.
Das .p12-Zertifikat (der Legacy-Pfad)
Das .p12 ist ein TLS-Client-Zertifikat, das nach der Ausstellung durch Apple aus dem Schlüsselbund (Keychain Access) exportiert wird. Es authentifiziert die Verbindung selbst und nicht das Signieren von Tokens. Es funktioniert immer noch, und einige Unternehmenssicherheitsrichtlinien verlangen es immer noch, aber seine Einschränkungen sind der Grund, warum Apple neue Integrationen zum Schlüssel lenkt:
- Es läuft jedes Jahr ab. Die häufigste Ursache für plötzliche, vollständige Push-Ausfälle ist ein APNs-Zertifikat, das stillschweigend abgelaufen ist.
- Es ist auf eine einzelne App beschränkt. Jede Bundle-ID benötigt ein eigenes Zertifikat, und jedes Zertifikat benötigt einen eigenen Erneuerungskalender.
- Es erfordert einen Mac. Der Exportvorgang für die Signierungsanforderung und den Schlüsselbund hat keinen reinen Browserpfad.
Welches sollten Sie verwenden?
| .p8-Authentifizierungsschlüssel | .p12-Zertifikat | |
|---|---|---|
| Läuft ab | Niemals | Alle 12 Monate |
| Geltungsbereich | Alle Apps im Konto | Eine Bundle-ID |
| Umgebungen | Entwicklung + Produktion | Getrennt oder kombiniert pro Zertifikat |
| Erstellt aus | Jeder Browser | Mac mit Schlüsselbundverwaltung |
| Kontolimit | 2 aktive Schlüssel | Pro App-Paare |
| Verwenden, wenn | Fast immer | Richtlinie erfordert Zertifikate |
Die ehrliche Antwort: Verwenden Sie den .p8-Schlüssel, es sei denn, eine Sicherheitsrichtlinie erzwingt den Zertifikatspfad. Weniger bewegliche Teile, nichts zu erneuern, eine Anmeldeinformation für Ihr gesamtes Portfolio.
Erstellen eines .p8-Schlüssels in drei Minuten
- Gehen Sie in Ihrem Apple Developer-Konto zu Zertifikate, Identifikatoren & Profile → Schlüssel und registrieren Sie einen neuen Schlüssel.
- Benennen Sie ihn, aktivieren Sie das Kontrollkästchen Apple Push Notifications service (APNs) und fahren Sie fort.
- Laden Sie die .p8-Datei herunter (denken Sie daran: eine Chance), und notieren Sie sich die Schlüssel-ID, die auf dem Bestätigungsbildschirm angezeigt wird, und Ihre Team-ID von der Kontomitgliedschaftsseite.
- Laden Sie alle drei Werte zu Ihrem Push-Anbieter hoch. In PushEngage ist dies ein einzelner Bildschirm in Ihren App-Einstellungen – der Leitfaden für APNs-Anmeldeinformationen führt Sie mit Screenshots durch.
Die Fehler, die dies erklärt
Ein überraschend großer Teil der „Push ist kaputt“-Tickets sind Anmeldeprobleme, die sich als etwas anderes tarnen. Die üblichen Verdächtigen:
- BadDeviceToken — Sie senden ein Token einer Sandbox-erstellten App über die Produktionsumgebung oder umgekehrt. Debug-Builds von Xcode sprechen mit der Sandbox; TestFlight- und App Store-Builds sprechen mit der Produktion.
- TopicDisallowed — die Anmeldeinformationen decken nicht die Bundle-ID ab, die Sie anvisieren. Typisch für .p12-Zertifikate pro App und eine kopierte Konfiguration.
- Plötzliches 100%iges Zustellungsversagen — ein abgelaufenes .p12. Überprüfen Sie das Ablaufdatum des Zertifikats, bevor Sie etwas anderes überprüfen.
- InvalidProviderToken — ein widerrufener .p8-Schlüssel oder das falsche Key ID/Team ID-Paar neben einer gültigen Datei.
Wo dies in Ihre Integration passt
Die APNs-Anmeldeinformation ist der erste Schritt einer einzigen Einrichtungssitzung. Laden Sie die .p8 einmal in PushEngage hoch, und alles nachgelagerte — die iOS SDK 1.0-Integration, Rich Media über Ihre Benachrichtigungserweiterung, ausgelöste Kampagnen und die Zustellung selbst — läuft ohne weitere Zeremonie dagegen. Wenn Sie von Firebase kommen, funktioniert derselbe Schlüssel, den Sie FCM gegeben haben, hier, was teilweise erklärt, warum die Migration von FCM unter iOS ein Nachmittagsprojekt ist.
Für die Strategieebene, die nach der Einrichtung kommt, beginnen Sie mit dem Leitfaden für App-Push-Marketing. Und wenn Sie bereit sind zu senden, führt Sie der vollständige Leitfaden für die iOS-Einrichtung in weniger als einer Stunde vom Anmeldeverfahren zur ersten Kampagne.
