APNS: vad det är, arkitekturen för Apple Push Notification Service och hur den fungerar

Vad är APNS?

Apple Push Notification Service (APNS) är Apples egen tjänst för att dirigera push-notiser från applikationsservern till användarnas enheter. Till skillnad från FCM stöder APNS inte Android eller andra plattformar — den är helt bunden till Apples ekosystem.

Tjänsten fungerar via en permanent TLS-anslutning som varje Apple-enhet upprättar med APNS-servrarna vid uppstart. Denna anslutning hålls vid liv i bakgrunden och används för att leverera notiser med minimal fördröjning.

APNS tar hand om hela leveransinfrastrukturen: kryptering, autentisering, prioritering och återsändning vid otillgänglig enhet. Utvecklaren behöver bara tillhandahålla en korrekt formaterad nyttolast och en giltig push-token.

APNS utveckling

Från början fungerade APNS via ett binärt protokoll på port 2195–2196. Från 2015 flyttade Apple tjänsten till det moderna HTTP/2-protokollet, som stöder multiplexering, huvudkomprimering och server-push-notiser. HTTP/2 blev obligatoriskt från juni 2020.

Hur fungerar Apple Push Notification Service?

Processen för att leverera en push-notis via APNS består av fem steg: enhetsregistrering, hämtning av push-token, sändning av begäran från servern, APNS-routning och leverans till enheten.

• Registrering — vid start anropar applikationen registerForRemoteNotifications, systemet kontaktar APNS
• Token — APNS returnerar en push-token till enheten — en unik sträng som identifierar applikationen på enheten
• Sändning — applikationsservern skickar en POST-begäran till https://api.push.apple.com med token och nyttolast
• Routning — APNS hittar enheten via token och levererar meddelandet via TLS-anslutning
• Behandling — iOS/macOS visar notisen eller skickar den till applikationen beroende på tillstånd

Om enheten är otillgänglig (avstängd eller utan nätverk), lagrar APNS det senaste meddelandet för varje applikation och levererar det när anslutningen återupprättas. Maximal lagringstid är 4 veckor, därefter raderas meddelandet.

Autentisering i APNS: Token och Certificate

Apple stöder två sätt att autentisera applikationsservern vid sändning av push-notiser. Varje sätt har sina egna egenskaper gällande giltighetstid, hantering och användarvänlighet.

Token-based autentisering — rekommenderat sätt från Apple sedan 2019. Du skapar en p8-nyckel i Apple Developer Console, laddar upp den på servern och signerar varje APNS-begäran med den. Nyckeln upphör inte och fungerar för alla appar på ditt konto.

Vilket autentiseringssätt ska du välja

För nya projekt är Token-based autentisering klart att föredra: en p8-nyckel för hela kontot, obegränsad giltighet, utan bindning till miljö. Certificate-based (.p12) används fortfarande i äldre projekt, men kräver årligt byte och separata certifikat för Sandbox och Production. Ta hänsyn till certifikatets utgång vid CI/CD-planering.

Typer av APNS-push-notiser

APNS stöder tre typer av push-notiser som skiljer sig åt i beteende på enheten och krav på begäranattribut. Valet av typ beror på UX-scenariot och meddelandets brådska.

• Alert — standardnotis med rubrik, text och valfria åtgärdsknappar
• Background — tyst dataöverföring (silent push) utan visning för användaren, hanteras i application:didReceiveRemoteNotification
• VOIP — särskild typ för VoIP-applikationer (PushKit), levereras omedelbart även när appen är stängd

För Background-notiser måste du ange nyckeln content-available: 1 och prioritet 5 (energisnål leverans). Systemet kan begränsa antalet bakgrundsnotiser om applikationen inte hanterar dem i tid.

Inställning av leveransprioritet

APNS stöder två prioritetsvärden: 10 (omedelbar leverans) och 5 (energisnål). För alert-notiser, använd 10 — användaren bör få dem omedelbart. För background-notiser, använd 5 — systemet kan fördröja leveransen för att spara batteri. Felaktig prioritet för background kan leda till att notisen avvisas av APNS.

Format för APNS-nyttolast

APNS accepterar nyttolast i JSON-format med maximal storlek på 4 KB för vanliga notiser och 5 KB för VOIP. Nyttolasten innehåller den obligatoriska aps-ordboken med visningsinställningar och valfria anpassade fält.

{
    "aps": {
        "alert": {
            "title": "Nytt meddelande",
            "body": "Du har 3 olästa chattar"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

Nyckeln thread-id grupperar notiser i iOS Notification Center. Nyckeln category kopplar notisen till UNNotificationCategory för att visa åtgärdsknappar. Utan dessa nycklar visas alla notiser separat.

Anpassade fält i APNS-nyttolasten

Förutom den obligatoriska aps-ordboken kan APNS-nyttolasten innehålla valfria anpassade fält på toppnivå. Dessa fält är tillgängliga för applikationen via userInfo-ordboken vid notisbehandling. Anpassad data är användbar för att överföra entitetsidentifierare, skärmar eller länkar. Maximal nyttolaststorlek är 4 KB, så undvik att överföra stora datamängder via push; ladda dem via API efter att notisen öppnats.

Exempel på sändning via HTTP/2 API

För att skicka en push-notis på servern måste du göra en POST-begäran till APNS-endpointen med korrekta autentiseringsrubriker. Nedan ges ett exempel i Node.js med Token-based autentisering.

const http2 = require("http2")
const fs = require("fs")
const jwt = require("jsonwebtoken")

const token = jwt.sign(
    { iss: "TEAM_ID", iat: Math.floor(Date.now() / 1000) },
    fs.readFileSync("AuthKey.p8"),
    { algorithm: "ES256", keyid: "KEY_ID" }
)

const payload = JSON.stringify({
    aps: { alert: { title: "Hej!", body: "Test-push" } }
})

const client = http2.connect(
    "https://api.push.apple.com"
)

const req = client.request({
    ":method": "POST",
    ":path": "/3/device/DEVICE_PUSH_TOKEN",
    "authorization": "bearer " + token,
    "apns-push-type": "alert",
    "apns-topic": "com.example.app",
    "apns-priority": "10"
})
req.end(payload)

req.on("response", (headers) => {
    if (headers[":status"] === 200) {
        console.log("Push skickades framgångsrikt")
    }
})

Efter sändning returnerar APNS HTTP-status 200 vid lyckad leverans eller en felkod med beskrivning i svarskroppen. Det är viktigt att hantera felet token-unregistered (410) — en sådan token bör tas bort från servern eftersom applikationen har avlägsnats från enheten.

APNS-fel och deras hantering

APNS returnerar HTTP-statusar för varje sändningsbegäran. Lyckad sändning — status 200. Fel kräver olika hanteringsstrategier. BadDeviceToken (400) eller Unregistered (410) — enhetens token är föråldrad, bör tas bort från servern. PayloadTooLarge (413) — gränsen på 4 KB överskriden, minska nyttolasten.

Felet TooManyRequests (429) — begärandegränsen överskriden. APNS sätter en kvot på antal sändningar per sekund. Vid 429 måste du implementera exponentiell backoff och göra om sändningen. Rekommenderat är att inte överskrida 100 begäranden per sekund per HTTP/2-anslutning.

Fel från APNS-sidan — 500 och 503 (Internal Server Error / Service Unavailable). Detta är tillfälliga fel i Apples infrastruktur. I sådana fall, upprepa sändningen med 1–5 sekunders fördröjning, max 3 försök. Permanenta 5xx-fel med en fullt fungerande server är sällsynta och beror vanligtvis på TLS-anslutningsproblem.

För produktionsmiljön, implementera loggning av alla APNS-fel med token, felkod och tid. Detta hjälper till att snabbt identifiera problem med certifikat, kvotering eller specifika enhetstokens. Kontrollera regelbundet certifikatens giltighetstid om du använder Certificate-based autentisering.