Varje iOS push-notifikationsintegration börjar vid samma grind: att bevisa för Apple Push Notification service att du får skicka meddelanden till din apps användare. Apple ger dig två sätt att göra det – en APNs-autentiseringsnyckel (.p8) eller ett APNs-certifikat (.p12) – och skillnaden mellan dem är skillnaden mellan en autentisering som du konfigurerar en gång och en som du kommer att förnya varje år, ofta vid sämsta möjliga tidpunkt.
Den här guiden förklarar hur APNs-autentisering faktiskt fungerar, när man ska använda en .p8-nyckel kontra ett .p12-certifikat, och de få fel som kan spåras tillbaka till att få detta felaktigt.
Hur APNs-autentisering fungerar
När din push-leverantör – PushEngage, eller din egen server – skickar en notifikation, ansluter den till Apples APNs-leverantörs-API och måste bevisa två saker: att den är auktoriserad att skicka å dina vägnar, och att den får rikta sig till din apps bundel-ID (”ämnet” i APNs-termer). .p8-nyckeln och .p12-certifikatet är bara två olika sätt att bevisa det.
Enhetssidan är separat. Din app registrerar sig hos APNs och tar emot en enhetstoken – den delen ändras aldrig oavsett vilken autentisering din leverantör använder. Autentisering är enbart en server-till-Apple-angelägenhet, vilket är anledningen till att du kan byta metoder utan att röra din app-binär.
Autentiseringsnyckeln .p8 (använd denna)
.p8 är en nyckel för att signera tokens. Din leverantör använder den för att skapa kortlivade JSON Web Tokens som autentiserar varje anslutning till APNs. Dess egenskaper gör den till standardvalet för nästan alla:
- Den går aldrig ut. Ingen årlig förnyelse, ingen push-avbrott på ett bortglömt datum.
- En nyckel täcker alla appar i ditt utvecklarkonto. Om du släpper en andra app autentiserar samma nyckel den också.
- Den fungerar för både utvecklings- och produktionsmiljöer – inga par av sandbox/produktionscertifikat.
- Den skickas som tre värden: själva .p8-filen, den 10-teckniga nyckel-ID:t och ditt Team ID.
Två saker att veta innan du skapar en. Apple begränsar dig till två aktiva APNs-nycklar per konto, så stora organisationer bör behandla nyckelskapande som en medveten handling, inte en vana per projekt. Och .p8-filen kan bara laddas ner en gång, vid skapandet – spara den någonstans ditt team kan hitta den, eftersom Apple inte ger dig den igen.
Certifikatet .p12 (den äldre metoden)
.p12 är ett TLS-klientcertifikat, exporterat från Nyckelhanteraren efter att Apple har utfärdat det. Det autentiserar själva anslutningen snarare än att signera tokens. Det fungerar fortfarande, och vissa företagssäkerhetspolicyer kräver det fortfarande, men dess begränsningar är anledningen till att Apple styr nya integrationer mot nyckeln:
- Det går ut varje år. Den vanligaste orsaken till plötsligt, totalt push-fel är ett APNs-certifikat som tyst har löpt ut.
- Det är begränsat till en enskild app. Varje bundel-ID behöver sitt eget certifikat, och varje certifikat behöver sin egen förnyelsekalender.
- Det kräver en Mac. Dansen med att exportera signeringsbegäran och nyckelringen har ingen webbläsarbaserad väg.
Vilken bör du använda?
| Autentiseringsnyckel .p8 | Certifikat .p12 | |
|---|---|---|
| Går ut | Aldrig | Varje 12:e månad |
| Omfattning | Alla appar i kontot | Ett bundel-ID |
| Miljöer | Utveckling + produktion | Separata eller kombinerade per certifikat |
| Skapad från | Valfri webbläsare | Mac med Nyckelhanteraren |
| Kontobegränsning | 2 aktiva nycklar | Par per app |
| Använd när | Nästan alltid | Policy kräver certifikat |
Det ärliga svaret: använd .p8-nyckeln om inte en säkerhetspolicy tvingar certifikatvägen. Färre rörliga delar, inget att förnya, en enda autentiseringsuppgift för hela din portfölj.
Skapa en .p8-nyckel på tre minuter
- Gå till Certifikat, identifierare och profiler → Nycklar i ditt Apple Developer-konto och registrera en ny nyckel.
- Namnge den, aktivera kryssrutan Apple Push Notifications service (APNs) och fortsätt.
- Ladda ner .p8-filen (kom ihåg: en chans), och notera Nyckel-ID som visas på bekräftelseskärmen och ditt Team-ID från sidan med kontomedlemskap.
- Ladda upp alla tre värden till din push-leverantör. I PushEngage är detta en enda skärm i dina appinställningar — guiden för APNs-autentiseringsuppgifter går igenom det med skärmdumpar.
Fel som detta förklarar
En överraskande andel av "push är trasigt"-ärenden är problem med autentiseringsuppgifter som är förklädda. De vanliga misstänkta:
- BadDeviceToken – du skickar en token från en sandbox-byggd app genom produktionsmiljön, eller vice versa. Felsökningsbyggen från Xcode pratar med sandbox; TestFlight och App Store-byggen pratar med produktion.
- TopicDisallowed – autentiseringsuppgifterna täcker inte det bundel-ID du riktar dig mot. Vanligt med .p12-certifikat per app och en kopierad konfiguration.
- Plötsligt 100% leveransfel – ett utgånget .p12. Kontrollera certifikatets utgångsdatum innan du kontrollerar något annat.
- InvalidProviderToken – en återkallad .p8-nyckel, eller felaktigt Key ID/Team ID-par tillsammans med en giltig fil.
Var detta passar in i din integration
APNs-autentiseringsuppgiften är det första steget av exakt en installationssession. Ladda upp .p8 till PushEngage en gång, och allt nedströms – iOS SDK 1.0-integrationen, rich media genom din notifikationstillägg, utlösta kampanjer och själva leveransen – körs mot den utan ytterligare ceremoni. Om du kommer från Firebase fungerar samma nyckel som du gav FCM här, vilket är en del av varför att migrera från FCM på iOS är ett eftermiddagsprojekt.
För strategilagret som kommer efter installationen, börja med guiden för app push-marknadsföring. Och när du är redo att skicka, tar den fullständiga guiden för iOS-installation dig från autentiseringsuppgifter till första kampanjen på under en timme.
