If you are planning to add push to your app, it helps to understand how do push notifications work in an app before you flip a single switch. Push feels like magic – a message lands on someone’s lock screen even when your app is closed – but underneath it is a well-defined pipeline of servers, tokens, and permissions. Knowing that pipeline makes setup faster, debugging saner, and your expectations realistic.
This guide is the “why” before the “how.” We’ll walk through Firebase Cloud Messaging, device tokens, permission prompts, and the real differences between Android and iOS delivery – all in plain English. Once the concepts click, the actual configuration in AppLikeWeb becomes far less intimidating.
What a push notification actually is
A push notification is a short message delivered to a device by the operating system, not by your app directly. That distinction is the whole game. Your app does not sit awake polling a server every few seconds – that would drain the battery and get your app throttled. Instead, the device maintains a single, efficient connection to a platform messaging service, and that service is what actually wakes the device and shows the alert.
Because the operating system owns that channel, push works even when your app is backgrounded or fully closed. It also means you are always playing by the platform’s rules: the user has to grant permission, and the OS decides how and when the message appears.
How do push notifications work in an app: the pipeline
Every push notification travels the same basic route from your server to a user’s screen. Here is the journey, step by step:
- The app registers with Firebase Cloud Messaging (FCM) when it first launches and receives a unique device token.
- That token is sent back to your messaging backend, which stores it as the “address” for this specific install.
- When you want to send a message, your backend hands the notification and the target token(s) to FCM.
- FCM routes the message to the correct platform transport – its own channel on Android, Apple Push Notification service (APNs) on iOS.
- The operating system on the device receives the message and displays it, or hands it to your app if the app is open.
Notice that your app is only involved at the very start (getting a token) and the very end (optionally reacting when tapped). Everything in the middle is infrastructure – which is exactly why a managed service like Firebase exists.
Where Firebase Cloud Messaging fits in
Firebase Cloud Messaging is Google’s free, cross-platform messaging layer. Think of it as a universal post office. Instead of your backend having to speak directly to Google’s Android transport and Apple’s APNs separately – each with its own authentication and quirks – you talk to FCM once, and FCM handles the last mile to each platform.
FCM also handles the hard parts you would otherwise build yourself: retrying delivery when a device is offline, managing connection efficiency, and grouping devices into topics so you can message thousands of users at once. AppLikeWeb uses Firebase for exactly this reason. When you enable push on your app, you connect it to a Firebase project, and that project becomes the engine that carries your messages.
Device tokens: the address of every install
A device token is a long, unique string that identifies one installation of your app on one device. It is not tied to a phone number or an email – it is generated by FCM and belongs to that specific app-on-device pairing. If the user reinstalls the app, clears its data, or moves to a new phone, the token changes.
A few practical implications follow from this:
- Tokens expire and rotate, so your backend should always treat the latest token as the source of truth.
- Sending to a stale token simply fails silently – there is no user to blame, just an old address.
- To message “everyone,” you either store every token or use FCM topics that devices subscribe to.
Permission prompts: the user is always in control
No message reaches a user who has not agreed to receive it. Both major platforms require explicit consent, but they ask for it differently, and this shapes your strategy.
On modern Android, apps must request notification permission with a system prompt, and the user can decline. On iOS, permission has always been required – the user sees the familiar “Allow Notifications?” dialog, and if they tap no, you are locked out until they re-enable it in Settings. The lesson is the same on both: you usually get one clean chance to ask, so ask at a moment when the value of notifications is obvious, not the instant the app opens.
Android vs iOS: why delivery is not identical
Even though FCM smooths over most of the differences, the two platforms behave differently once a message reaches the device, and it is worth setting expectations:
- iOS routes through APNs. FCM must hand every iOS message to Apple’s service, which means your Firebase project needs the correct Apple credentials configured. Apple is also stricter about background delivery and may deprioritize messages it considers low value.
- Android is generally more permissive. Messages tend to arrive promptly, though aggressive battery-saver settings on some manufacturers can delay them.
- Timing is best-effort, not guaranteed. If a device is offline, the message waits and is delivered later; very old undelivered messages may be dropped.
None of this requires you to write platform code – AppLikeWeb generates native Android and iOS apps and wires the Firebase connection for both – but understanding it explains why an iOS message occasionally lands a little slower than its Android twin.
Putting it together in your AppLikeWeb app
Once the pipeline makes sense, the setup is refreshingly short. AppLikeWeb converts your existing responsive website into native apps and includes Firebase push as a built-in feature. You connect a Firebase project, and your native Android and iOS apps inherit the ability to receive notifications – no server code to write, no native SDKs to wrestle with. From there you can send announcements, re-engagement nudges, or updates straight to the people who installed your app.
When you are ready for the click-by-click configuration – creating the Firebase project, adding your app, and sending your first test message – head to our dedicated push notification setup guide on the AppLikeWeb blog, which picks up exactly where this explainer leaves off.
Ready to turn your website into native apps with push built in? Start converting your website with AppLikeWeb today.