Technologies / Messaging
Push notifications for mobile apps that users keep switched on
Push notifications for mobile apps look simple from the outside: send a message, a phone buzzes. In practice the work is split between permission strategy, delivery plumbing on Apple and Google, and a backend that decides who gets what and when. The plumbing changed recently on both platforms, and the permission rules now make a careless first-launch prompt expensive.
Push is one of the building blocks in our mobile app development technologies hub. For the content and timing side, read our guide to a push notification strategy that doesn’t annoy users.
- APNs token auth, not expiring certificates
- FCM on the HTTP v1 API
- Permission asked in context
- Keys and console access in your accounts
How push delivery works on iOS and Android
Your app never talks to a phone directly. On iOS, your server sends each message to Apple Push Notification service (APNs), which delivers it. On Android, messages go through Firebase Cloud Messaging (FCM). FCM can also deliver to iOS by relaying through APNs, which is why many teams use one FCM integration for both platforms. Each device registers and gets a token, the app sends the token to your backend, and the backend addresses messages to tokens or topics.
APNs: use token-based authentication
Apple supports two ways to authenticate your server. Older setups use certificates that expire and must be renewed, and a forgotten renewal stops iOS notifications. We use token-based authentication: a .p8 signing key with a 10-character Key ID, used to sign a JWT with ES256. One key works for many apps and servers. Apple requires the token to be refreshed no more than once every 20 minutes and at least once every 60 minutes, and rejects tokens older than an hour with an ExpiredProviderToken error. We build that refresh into the sender, not into a cron job someone has to remember.
FCM: legacy APIs are gone
Google deprecated the FCM legacy APIs on 20 June 2023 and began shutting them down on 22 July 2024. Apps must now send through the FCM HTTP v1 API, which uses short-lived OAuth access tokens from a service account instead of a static server key. If an older app or a third-party plug-in still uses the legacy endpoint, its Android notifications have stopped or are about to. This is one of the first things we check when we take over an app.
Permission rules: what changed and what to do
Both platforms now require the user’s consent before notifications show. How and when you ask decides your opt-in rate.
| Platform rule | What it means | What we do |
|---|---|---|
| Android 13 (API 33) POST_NOTIFICATIONS | Notifications are off by default on new installs and need a runtime permission. Apps that already had channels are pre-granted on upgrade. | Ask in context after the user sees value, as Google advises, not at first launch |
| Android exemptions | Media-session notifications and qualifying self-managed call notifications are exempt | Use them for playback and calling apps rather than asking for permission |
| iOS standard authorisation | A one-time system prompt; if declined, the user must go to Settings | Show a short pre-prompt screen explaining the benefit, then the system prompt |
| iOS provisional authorisation | Granted without a prompt; notifications arrive quietly in Notification Center with Keep and Turn Off buttons | Use for apps where users should sample notifications before committing |
| Apple Guideline 5.1.2(i) | Apps may not require users to enable push notifications to access functionality | Every feature works with notifications off |
Sources: Android developer documentation on the notification permission, Apple UserNotifications documentation, Apple App Review Guidelines.
When provisional notifications make sense
Provisional authorisation on iOS is underused. Instead of an interruptive prompt on day one, the app is allowed to deliver notifications quietly into Notification Center, with no sound, banner or lock-screen alert. The user then sees real examples and taps Keep or Turn Off.
It works well when your notifications are useful on their own: order updates, price drops, new content from people you follow. It works poorly for time-critical alerts, like a driver arriving, because quiet delivery may go unnoticed. For those apps we ask for full permission at the moment it is obviously useful, such as right after the user places an order.
Good moments to ask for permission
- Right after the first order or booking
- When the user follows a person or topic
- When they set a reminder or price alert
- After onboarding, never before it
- Never on the very first screen
Inheriting an app with broken or noisy notifications?
Send us the app and your current setup. Within one business day we reply with what we would check first: the FCM API version, APNs authentication, the permission flow and token hygiene.
Push providers compared
The delivery always ends at APNs and FCM. The choice is what sits between your backend and them.
| Option | Choose it when | Trade-offs |
|---|---|---|
| Direct APNs + FCM from your backend | You want full control and no extra vendor | You build token management, retries, scheduling and analytics yourself |
| FCM for both platforms | You already use Firebase, or want one API for iOS and Android | Still need APNs key setup; targeting and analytics are basic |
| Azure Notification Hubs | Your backend runs on Azure and you push to many platforms | Free tier includes 1 million pushes a month and 500 active devices; higher tiers for more |
| Engagement platforms (OneSignal, Braze and similar) | Marketing teams need segmentation, A/B tests and journeys without developer time | Monthly cost grows with audience; user data shared with another processor |
Check each vendor’s current pricing and data processing terms before committing.
How notifications fit your backend
The sending logic belongs on your server, inside your mobile app backend. We usually build it with a queue so that a spike (an order rush, a breaking story) does not overload the API, and so failed sends retry with backoff. Typical pieces: a device-token table linked to user accounts, topic or segment subscriptions, user preferences per notification type, quiet hours by time zone, and delivery logs.
Token hygiene matters more than most teams expect. Tokens change when apps are reinstalled or restored, and APNs and FCM report invalid tokens. We remove those on every response so you are not paying to send into a void, and so your delivery metrics are accurate. On Android, notification channels let users silence marketing while keeping order updates, so we define channels per type from the start. A notification should open the right screen, which is a routing job covered in our guide to deep linking in mobile apps.
Stacks we commonly use: Firebase for FCM and quick setup, or Node.js and Laravel backends calling APNs and FCM directly.
Hiring and maintenance implications
Push work spans mobile and backend, and the bugs sit between them: a token not sent after login, a payload that renders on Android but not iOS, a silent push that iOS throttles. You need developers who can test end to end on real devices, in foreground, background and killed states.
Maintenance is mostly about platform changes and credentials. Both FCM’s v1 migration and Android 13’s permission broke notifications in apps nobody was watching. We keep the APNs key and Firebase service account in your accounts, document who can rotate them, and retest notifications on each major OS release as part of app maintenance and support.
Push notification checklist before launch
What we verify on every app that sends notifications.
- APNs token-based auth with automatic JWT refresh
- FCM sends through the HTTP v1 API only
- Permission requested in context, with a pre-prompt screen
- App fully usable with notifications denied
- Android channels defined per notification type
- Invalid tokens removed on every send response
- User preferences and quiet hours respected server-side
- Deep links from each notification tested in killed and background states
- No personal or sensitive data in notification text on the lock screen
Push notifications for mobile apps: frequently asked questions
Do we need Firebase to send push notifications?
Not necessarily. iOS notifications always go through Apple’s APNs and Android through FCM. Your backend can call both directly. Many teams use FCM for both platforms because it relays to APNs and gives one API. Engagement platforms or Azure Notification Hubs sit on top of the same services. We choose based on your backend and marketing needs.
Our Android notifications stopped working. Why?
Two common causes. First, Google began shutting down the legacy FCM APIs on 22 July 2024, so servers or plug-ins still using the old server key stop delivering. Second, since Android 13 new installs need the POST_NOTIFICATIONS runtime permission, so users who never granted it receive nothing. We check both first.
When should the app ask for notification permission?
At a moment when the benefit is obvious, not on first launch. Google advises asking in context, and on iOS a declined prompt sends the user to Settings to change it. Good moments are right after a first order, a follow or setting an alert. A short pre-prompt screen explaining what they will get helps.
What are provisional notifications on iOS?
A permission type that is granted without a prompt. Notifications arrive quietly in Notification Center, with no sound, banner or lock-screen alert, and the user can choose Keep or Turn Off. It lets people sample your notifications before deciding. It suits content and updates, but not urgent alerts, which may go unnoticed.
Can we require users to turn on notifications?
No. Apple’s App Review Guidelines say apps may not require users to enable push notifications to access functionality, and Android users can switch them off at any time. Every feature must still work with notifications off. Explain the benefit clearly, offer in-app alternatives such as an inbox, and let users choose notification types.
Why use APNs token authentication instead of certificates?
Push certificates expire and must be renewed, and a missed renewal stops iOS notifications. Token authentication uses one .p8 signing key that works across many apps and servers, and signs short-lived JWTs that your server refreshes no more than once every 20 minutes and at least once every 60. It is simpler to manage and harder to break by accident.
Build notifications people choose to keep
Book a 30-minute scoping call. We will map your notification types, the permission flow on iOS and Android, and the backend pieces you need, before any code is written.