APNs vs FCM vergelijking voor iOS en Android: token lifecycle, payload-limieten, leveringsverwachtingen en een praktische checklist om ontbrekende pushmeldingen op te lossen.
APNs (Apple Push Notification service) en FCM (Firebase Cloud Messaging) zijn de bezorgpijpen die een bericht van je server naar een telefoon verplaatsen. Ze bepalen niet wat je app met het bericht doet, maar ze beïnvloeden sterk of het bericht aankomt, hoe snel het aankomt en welke vorm het moet hebben.
Als mensen zeggen dat een pushmelding “werkt op Android maar niet op iOS” (of andersom), is het zelden één enkele bug. iOS en Android behandelen achtergrondwerk, energiebesparing, permissies en berichtprioriteit anders. Hetzelfde bericht kan vertraagd worden, vervangen door een nieuwer bericht, zonder geluid worden getoond of helemaal niet verschijnen als de app niet wakker gemaakt kan worden om het te verwerken.
Deze vergelijking richt zich op de onderdelen die de meeste verrassingen in de praktijk veroorzaken: hoe apparaat-tokens in de tijd veranderen, hoe groot je payload kan zijn en hoe die gestructureerd moet worden, welke levering je realistisch kunt verwachten en de veelvoorkomende redenen waarom meldingen lijken te ontbreken.
Dit gaat niet over het kiezen van een push-provider UI, marketingstrategie of het bouwen van een volledig analytics-pijplijn. Het doel hier is betrouwbaarheid en sneller debuggen.
Een paar termen die we vaak gebruiken:
De basis goed krijgen bespaart uren met gissen als een “simpele push” zich anders gedraagt op iOS en Android.
APNs en FCM zijn beide tussenpersonen tussen je server en de telefoon van een gebruiker. Je app kan niet betrouwbaar zelf een pushmelding over het internet naar een apparaat afleveren, dus je geeft die taak aan Apple (APNs) of Google (FCM), die al vertrouwde connecties naar hun apparaten onderhouden.
De algemene flow is vergelijkbaar: je app krijgt een token, je backend stuurt een bericht naar de push-service met dat token, en de push-service routeert het naar het apparaat.
Op iOS registreert de app zich voor remote notifications en vraagt (meestal) toestemming aan de gebruiker. Apple levert vervolgens een device token. Je backend (vaak je “provider” genoemd) stuurt een pushrequest naar APNs met dat token en je payload. APNs bepaalt of het kan afleveren en stuurt de notificatie door naar het apparaat.
Je backend authenticereert naar APNs, meestal met token-gebaseerde auth (een signing key). Oudere setups gebruiken certificaten.
Op Android registreert de app-instantie zich bij FCM en ontvangt een registratie-token. Je backend stuurt een bericht naar FCM en FCM routeert het naar het juiste apparaat. Afhankelijk van de appstatus en het berichttype kan FCM automatisch een notificatie tonen of data aan de app afleveren voor verwerking.
Je backend authenticereert naar FCM met server-credentials (API key of service account).
Wat jij controleert: app-code, wanneer je toestemming vraagt, tokenopslag, backendlogica en de payload die je stuurt. Wat Apple en Google controleren: het leveringsnetwerk, bereikbaarheid, throttlingregels en veel last-mile omstandigheden zoals energiebesparing en systeembeleid.
Het grootste dagelijkse verschil tussen APNs en FCM is dat tokens niet "eenmaal instellen voor altijd" zijn. Behandel ze als adressen die zonder waarschuwing kunnen veranderen.
Op iOS is het APNs device token gekoppeld aan het apparaat, je app en je Apple developer-configuratie. Het kan veranderen na een herinstallatie van de app, een apparaatrestore, bepaalde OS-updates of bij het wisselen tussen push-omgevingen (sandbox vs production) tijdens ontwikkeling.
Op Android kan het FCM-registratietoken vernieuwen wanneer de app op een nieuw apparaat wordt hersteld, de gebruiker app-gegevens wist, Google het token roteert of de app opnieuw wordt geïnstalleerd. Je app moet refresh-events verwachten en het nieuwe token snel naar je server sturen.
Een eenvoudige regel: altijd tokens upserten, nooit “insert en vergeet.” Wanneer je tokens opslaat, bewaar genoeg context om duplicaten en verkeerde doelen te vermijden:
Verwijderingen zijn ook belangrijk. Meestal leer je dat een token dood is via afleverfouten, niet via een nette “uninstall”-melding. Als APNs een fout teruggeeft zoals Unregistered (vaak met status 410), of FCM zegt NotRegistered/Unregistered, verwijder dat token direct zodat je niet voor altijd blijft retryen.
Een makkelijke manier om privacylekken te veroorzaken: een klant logt uit en iemand anders logt in op hetzelfde toestel. Als je het token niet wist of opnieuw koppelt bij logout, kun je meldingen naar de verkeerde persoon sturen, ook al lijkt de levering “te werken.”
Het grootste praktische verschil tussen APNs en FCM is wat je in een bericht kunt stoppen en hoe de telefoon het behandelt als het aankomt.
De meeste teams vertrouwen op een kleine set velden:
order_id, status)Beide services hebben payload-grootte-limieten, en de limiet omvat ook je custom data. Als je de limiet raakt, kan aflevering mislukken of gedraagt het bericht zich niet zoals je verwacht.
Een betrouwbaar patroon is een korte notificatie plus een ID sturen, en dan details ophalen van je backend:
Voorbeeld: in plaats van een volledige order-samenvatting te sturen, stuur { "type": "order_update", "order_id": "123" } en laat de app via je API de laatste status ophalen.
Op Android zal een FCM-bericht met een “notification”-payload doorgaans door het systeem worden getoond wanneer de app op de achtergrond draait. Een data-only bericht wordt aan je app-code gegeven, maar kan vertraagd of geblokkeerd worden door achtergrondlimieten en batterijinstellingen.
Op iOS zijn alerts (titel/body) eenvoudig, maar achtergrondupdates zijn strikter. Een achtergrond-push garandeert niet dat je code meteen draait. Behandel het als een hint om te verversen, niet als een real-time trigger.
Als je betrouwbaarheid nodig hebt, houd de payload minimaal, voeg een stabiele identifier toe en ontwerp je app om de status te reconciliëren wanneer deze opent of hervat wordt.
Bij zowel APNs als FCM is levering best-effort. De provider zal proberen je bericht te leveren, maar belooft niet dat het apparaat het daadwerkelijk toont.
Bereikbaarheid is de eerste limiter. Je stuurt een notificatie met een time-to-live (TTL) of expiry. Als het apparaat pas online komt nadat die window is verstreken, wordt de push weggegooid. Als TTL heel lang is, kan de gebruiker later een oud bericht zien, wat op een bug lijkt.
Prioriteit beïnvloedt timing, maar het is geen gratis upgrade. Hoge prioriteit kan helpen dat tijdgevoelige berichten sneller aankomen, vooral als het apparaat slaapt. Overmatig gebruik kan leiden tot throttling, batterijbelasting of dat het OS je app als storend bestempelt.
Beide systemen ondersteunen collapsing zodat een nieuw bericht een ouder bericht vervangt in plaats van op te stapelen. APNs gebruikt een collapse identifier en FCM gebruikt een collapse key. Als je collapse gebruikt op iets als order_status, ziet de gebruiker mogelijk alleen de laatste status, niet elke stap.
Zelfs als de provider succesvol aflevert, kan de telefoon alsnog voorkomen dat de gebruiker het ziet:
Behandel push als een onbetrouwbaar transport: houd belangrijke status in je backend en laat de app huidige status verversen bij openen, zelfs als een notificatie nooit verschijnt.
Veel "leveringsproblemen" zijn eigenlijk permissie- en instellingenproblemen.
Op iOS is de eerste permissieprompt belangrijk. Als de gebruiker op “Niet toestaan” tikt, verschijnen er geen meldingen totdat ze het in Instellingen aanpassen. Zelfs nadat ze toestaan, kunnen ze Lock Screen, Notification Center, banners, geluiden of badges uitschakelen. Focus-modi en Scheduled Summary kunnen meldingen ook verbergen of vertragen.
Op Android hangen de vereisten af van de OS-versie. Nieuwere versies vragen om een runtime-notificatiepermissie, dus een app-update kan plotseling meldingen stoppen totdat de gebruiker opnieuw toestemming geeft. Zichtbaarheid hangt ook af van notificatiekanalen. Als een kanaal gedempt of op lage belangrijkheid staat, komen pushes aan maar veroorzaken ze geen interrupt.
Achtergrondbeperkingen kunnen verwachtingen ook breken. Low Power Mode op iOS en batterijoptimalisaties op Android kunnen achtergrondwerk vertragen, achtergronddata stoppen of voorkomen dat de app een data-only bericht verwerkt.
Om te bevestigen wat er gebeurt, log wat het apparaat ziet, niet alleen wat je backend heeft verzonden:
Zelfs als je backend in een no-code tool is gebouwd, is client-side logging wat het onderscheid maakt tussen “bericht niet ontvangen” en “ontvangen maar onderdrukt.”
Als een push ontbreekt, behandel het als een keten: token, provider, payload en app-gedrag. De symptomen kunnen op iOS en Android hetzelfde lijken, dus controleer in dezelfde volgorde een paar punten.
Versmal dan of het de inhoud van het bericht is of het apparaat/app-gedrag:
Een praktisch patroon: als iOS-gebruikers misses melden maar Android werkt, begin met het sturen van een minimale alert op iOS. Als dat werkt, richt je op payload-structuur en app-handling. Als het niet werkt, focus op tokens en APNs-credentials/omgeving.
De meeste push-problemen zijn geen outages. Het zijn kleine mismatchen tussen wat je app verwacht en wat APNs of FCM accepteert, of wat de telefoon toelaat.
De meest voorkomende is verzenden naar een token dat niet meer geldig is. Tokens veranderen na herinstallatie, restore of refresh. Als je server de oude waarde blijft gebruiken, gaan pushmeldingen nergens heen.
Een andere is het behandelen van pushlevering als gegarandeerd. Best-effort levering betekent dat late of ontbrekende berichten normaal zijn wanneer apparaten offline zijn of onder energiebesparende regels vallen. Voor belangrijke events (orderupdates, veiligheidsalerts) heb je een in-app fallback nodig zoals het ophalen van de laatste status bij openen.
Veelvoorkomende oorzaken van ontbrekende notificaties:
Voorbeeld: een retail-app stuurt een “order verzonden”-melding met een grote JSON-brok geschiedenis van tracking. De send-call lijkt goed, maar de payload wordt afgewezen of ingekort en de gebruiker ziet niets. Houd de push klein en zet details achter een API-call.
Voordat je aanneemt dat de provider het probleem is, voer een sanity check uit:
Doe daarna een snelle apparaatcheck: notificaties toegestaan voor de app, juiste kanaal/categorie ingesteld (Android-kanalen zijn een veelgemaakte valkuil), Focus/Niet Storen, en achtergrondbeperkingen.
Een supportmedewerker drukt op “Send order update” voor Order #1842. De backend-logs tonen “notification sent,” maar de klant ziet niets op zijn iPhone of Android-telefoon.
Begin in de backend. De meeste “missende” notificaties worden ofwel nooit geaccepteerd door de push-service, of ze worden geaccepteerd maar later weggegooid omdat het apparaat ze niet kan (of wil) tonen.
Zoek naar één traceerbare verzendpoging (één orderupdate zou één pushrequest moeten produceren). Verifieer dan:
Als je logs een afwijzing laten zien zoals “unregistered/invalid token,” is het een token lifecycle-issue. Als de provider het bericht accepteert maar niets aankomt, richt je op payloadtype en OS-gedrag.
Valideer nu dat het toestel de melding mag tonen:
Een veelvoorkomend uitkomst: het token is oké, maar het bericht is data-only (Android) of mist de juiste iOS-setup voor achtergrondverwerking, dus het OS toont nooit een alert. De oplossing is het juiste payload-type sturen voor wat je wilt (zichtbare alert vs achtergrondupdate) en schone logs bijhouden van token-updates en provider-responses.
Pushmeldingen lijken simpel totdat ze een kernfunctie worden. Betrouwbaarheid komt van de onderdelen die jij controleert: token-hygiëne, payload-discipline en een fallback-pad.
Plan voor misses. Push is geweldig voor “kijk nu”-momenten, maar het moet niet de enige route zijn voor kritieke events. Een in-app inbox helpt gebruikers later bij te werken, en e-mail of SMS kan hoge-waarde acties dekken zoals wachtwoordherstel of betalingsproblemen.
Houd de payload lean. Behandel de push-payload als een prompt, niet als het volledige bericht. Stuur een event-type en een ID en haal details op via je backend-API wanneer de app opent of wanneer hij een geschikte achtergrondupdate ontvangt.
Schrijf een kort runbook voor je team zodat debuggen consistent blijft: opt-in status, token-freshness, provider response codes, payload-grootte/-vorm en omgeving/credentials.
Als je bouwt met AppMaster (appmaster.io), kan het handig zijn om tokenopslag, auditlogs en push-triggerende businesslogica bij elkaar in één backend te houden, terwijl je nog steeds native iOS- en Android-apps levert die APNs en FCM correct behandelen.
Wat is de eenvoudigste manier om APNs vs FCM uit te leggen?APNs is Apples bezorgdienst voor iOS-pushmeldingen, en FCM is Google's bezorgdienst voor Android (en kan ook iOS targeten via APNs). Je app beslist nog steeds wat er met het bericht gebeurt, maar deze diensten bepalen hoe je authenticatie regelt, hoe je payloads formatteert en welk aflevergedrag je kunt verwachten.
Blijven apparaat-tokens voor altijd hetzelfde?Behandel tokens als veranderlijke adressen. Sla ze op met platform- en omgevingsgegevens, werk ze bij zodra de app een nieuwe waarde meldt, en verwijder ze wanneer de provider aangeeft dat ze ongeldig zijn. De praktische regel is om altijd tokens in te voegen of bij te werken (upsert) en een “last seen”-timestamp bij te houden zodat je verouderde records snel ziet.
Wat veroorzaakt meestal dat een iOS- of Android-pushtoken verandert?Op iOS veranderen tokens vaak na een herinstallatie, het herstellen van het apparaat, sommige OS-updates of wanneer je tijdens ontwikkeling wisselt tussen sandbox en productie. Op Android kan een FCM-token vernieuwen na herinstallatie, wanneer de gebruiker app-gegevens wist, bij het herstellen van het apparaat of wanneer Google tokens roteert. Je app moet refresh-events afhandelen en het nieuwe token meteen naar je backend sturen.
Hoe moet ik een push-payload structureren om problemen te vermijden?Houd de push-payload klein en behandel het als een prompt. Stuur een korte titel/body (als je een zichtbare melding wilt) plus een stabiele identifier zoals order_id, en laat de app daarna de volledige details ophalen uit je API. Dit voorkomt payload-limieten, vermindert vreemde randgevallen en zorgt voor consistenter gedrag tussen platforms.
Wat is het verschil tussen “notification” en “data-only” berichten?Een notificatie-payload is bedoeld om aan de gebruiker te worden getoond, terwijl een data-only payload bedoeld is voor de app om te verwerken. Op Android kunnen data-only berichten vertraagd of geblokkeerd worden door achtergrondlimieten en batterijinstellingen, dus ze zijn geen betrouwbare trigger voor direct werk. Op iOS garanderen achtergrond-pushes ook niet dat je code meteen draait; beschouw ze als een hint om te verversen in plaats van een real-time job-runner.
Worden pushmeldingen gegarandeerd afgeleverd en weergegeven?Nee, bezorging is best-effort. Zelfs als APNs of FCM je verzoek accepteert, kan het apparaat offline zijn, kan het bericht verlopen door TTL, kan het OS de levering throttlen, of kunnen gebruikersinstellingen meldingen onderdrukken. Ontwerp je app zo dat kritieke status altijd klopt wanneer de gebruiker deze opent, zelfs als de notificatie nooit verschijnt.
Wat is de snelste manier om een ontbrekende notificatie te debuggen?Begin met het scheiden van “verzonden” en “weergegeven”. Bevestig dat het token actueel is, stuur een minimaal testpayload met titel/body en controleer dat je de juiste APNs/FCM-credentials en (voor iOS) de juiste omgeving gebruikt. Als de provider het bericht accepteert, controleer dan telefoinstand en instellingen zoals Focus/Niet Storen, app-meldingsrechten en Android-notificatiekanalen—want het bericht kan ontvangen maar onderdrukt zijn.
Waarom werken notificaties op Android maar niet op iOS (of andersom)?Op iOS komen de meeste problemen door geweigerde permissies, Focus-modi of het targetten van de verkeerde APNs-omgeving (sandbox vs productie). Op Android zijn veelvoorkomende blokkades de runtime notificatiepermissie op nieuwere OS-versies, gedempte/laag-importance notificatiekanalen en agressieve batterijoptimalisaties die achtergrondverwerking vertragen. Dezelfde backend-send kan er goed uitzien terwijl het apparaat stilletjes voorkomt dat de gebruiker iets ziet.
Hoe beïnvloeden TTL en “collapse key” wat gebruikers zien?TTL bepaalt hoe lang de provider moet blijven proberen terwijl het apparaat offline is, en collapse-instellingen bepalen of nieuwere berichten oudere pending berichten vervangen. Een korte TTL kan ervoor zorgen dat notificaties verdwijnen als de telefoon even offline is, en collapse keys/identifiers kunnen ervoor zorgen dat alleen de laatste update zichtbaar is. Stel deze waarden bewust in op basis van de gebruikerservaring die je wilt, niet als ongewijzigde defaults.
Hoe kan AppMaster me helpen een betrouwbare push-setup te bouwen?Houd tokenopslag, targetingregels en verzendlogs bij elkaar zodat je elke pushpoging end-to-end kunt traceren. AppMaster kan helpen door token-tabellen, auditlogs en push-triggerende businesslogica in één backend te centraliseren, terwijl je native iOS- en Android-apps nog steeds APNs en FCM correct afhandelen. De sleutel is het loggen van tokenupdates, provider-responses en client-side ontvangst zodat je kunt vaststellen of de fout bij de server, provider of het apparaat ligt.
27 jan 2026
7 min
26 jan 20268 min
21 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
