Key Takeaway
Most Adalo push failures trace to one of five things: the app was never published as a native build (push does not work in the web preview or PWA), the user denied or never granted notification permission, a missing or stale device token, sending from test instead of production, or an expired Apple/Google credential. Work through them in that order. If reliability stays shaky after that, the cause is often the no-code delivery chain itself.
You set up a push notification in Adalo, hit send, and nothing arrives. Or it lands for one tester and not another, or on Android but not iPhone. This is one of the most common Adalo support threads as of 2026, and the frustrating part is that "push not delivering" has several distinct causes that all look identical from the outside. This guide walks through them in the order they most often break, with a concrete check for each.
Start here: is the app actually published natively?
This is the single most common reason Adalo push notifications do not work, and it catches almost everyone once. Push only fires on a real native build installed from the App Store or Google Play (or a TestFlight / internal-testing build). It does not work in:
- The Adalo web preview or share link
- A Progressive Web App (PWA) added to a home screen, especially on iOS
- The in-editor live preview
Test in a browser tab or the Adalo preview and push will silently do nothing, no matter how correctly it is configured. Publish a native build to TestFlight (iOS) or Google Play internal testing (Android), install that on a real device, and test there. If push starts working, this was your whole problem.
Permissions: granted, denied, or never asked
Even on a native build, a device only receives push if the user granted notification permission. On iOS the prompt appears once. If a tester tapped "Don't Allow," the app cannot re-prompt, and every send to that device silently fails.
- iOS: Settings, the app name, then Notifications. Confirm "Allow Notifications" is on. If it was denied, you usually have to delete and reinstall the app to see the prompt again.
- Android: Settings, Apps, your app, then Notifications. Android 13+ also requires a runtime notification permission, so an older build that never requested it will not deliver.
- Check your flow: make sure a screen actually triggers the register-for-push step early, not buried behind a login the tester skipped.
Device-token problems
To reach a specific user, Adalo has to have stored a valid device token for them. A token is created when the app registers with Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM) on that device, and tokens go missing or stale more often than people expect.
- No token recorded: the user opened the app before granting permission, or on a version where push registration was not wired up. Check whether the user record has a push token field populated.
- Stale token: reinstalling the app, restoring a phone, or a major OS update can rotate the token, leaving the old one dead.
- Fix: have the user fully reopen the app after granting permission so a fresh token registers, then confirm it on their record before sending.
Test vs. production: the environment trap
Push infrastructure separates sandbox/test from production, and a notification configured against one will not reach a device registered in the other. This is the classic cause of "it works in TestFlight but not the live App Store app," or the reverse: a TestFlight build talks to the APNs sandbox, an App Store build talks to production, and their credentials and tokens are not interchangeable. If you uploaded a development APNs key but published a production build, production sends fail. The fix: make sure the key configured in Adalo matches the build type, and re-test on a matching build.
iOS vs. Android: different failure modes
The two platforms fail in different ways, so a notification that works on one and not the other is normal, not a bug in your logic. Match the symptom to the likely cause:
| Symptom | Likely on iOS | Likely on Android |
|---|---|---|
| Nothing arrives at all | Expired APNs key/cert, or sandbox/production mismatch | Missing or misconfigured FCM server key |
| Works for some users, not others | Permission denied on first prompt; cannot re-ask | Android 13+ runtime permission never requested |
| Delivered but delayed or dropped | Low-priority push throttled by the OS | Battery optimization / Doze mode killing background delivery |
| Stopped working suddenly | APNs auth key revoked or rotated | FCM project/key changed or quota issue |
Credentials expire: re-check Apple and Google
If push worked for months and then stopped for everyone at once, suspect a credential. APNs certificates expire (auth keys do not, but can be revoked), and FCM keys can change if someone touches the Google project. Re-generate or re-upload the relevant key, then send a fresh test. Check this early when the failure is sudden and total rather than user-specific.
A realistic word on delivery rates
Even when everything is configured correctly, push is not 100% reliable on any platform. The OS can throttle, batch, or drop low-priority notifications, users silence apps, and Android background delivery is at the mercy of battery optimization. Industry-wide, healthy native push delivery sits high but never perfect, and engagement on what lands beats email (commonly high single digits versus 1 to 2 percent for email, as of 2026).
No-code tools add another link to that chain. Across Adalo's own forums, push reliability is one of the most reported pain points. If you have worked through every cause above and delivery is still inconsistent for a real user base, you may be hitting the platform's ceiling rather than a setting you can flip.
A quick triage checklist
- Confirm you are testing on a real, natively published build, not a preview or PWA.
- Verify notification permission is granted on the device (and was actually requested).
- Check that a valid, current device token exists on the user's record.
- Make sure your APNs/FCM credentials match the build type (sandbox vs. production).
- If it broke suddenly for everyone, re-check Apple and Google credentials for expiry.
- Judge reliability across many users, not one phone, since some loss is normal.
FAQ
Why do Adalo push notifications work in TestFlight but not the live app?
Almost always a sandbox-vs-production mismatch. TestFlight builds use the APNs sandbox endpoint and your live App Store build uses production. If the credential configured in Adalo or the registered token does not match the environment, the live app silently fails to deliver. Re-check that your APNs key/certificate is set for production and re-test on the App Store build.
Why does push work on Android but not iPhone (or vice versa)?
The platforms use separate delivery systems (APNs for Apple, FCM for Android) with separate credentials and failure points. iOS most often fails on an expired or mismatched APNs key, or a denied permission prompt that cannot be re-shown. Android most often fails on a missing FCM server key or an Android 13+ runtime permission that was never requested. Diagnose each platform on its own.
How do I fix a missing device token in Adalo?
Have the user grant notification permission, then fully close and reopen the app on a native build so it re-registers with APNs/FCM and writes a fresh token. Confirm the token field is populated before sending. If reinstalling fixed it, the previous token was stale (common after OS updates or phone restores).
Is it normal for some Adalo push notifications to never arrive?
Some loss is normal everywhere: the OS throttles low-priority pushes, Android battery optimization can kill background delivery, and users silence apps. But if a large share of correctly-permissioned users consistently miss notifications, that points past normal loss toward a configuration issue or a platform reliability ceiling.
The bottom line
Adalo push problems are almost always one of a handful of fixable causes: a non-native test build, denied permission, a missing or stale device token, a test-vs-production mismatch, or an expired Apple/Google credential. Work the triage list in order and you will resolve most cases. What the checklist cannot fix is the reliability ceiling of a no-code delivery chain once you are sending to a real, growing user base. That is a different decision than a settings tweak.
If push reliability is genuinely mission-critical (the difference between a customer showing up or not), that is where many teams stop maintaining the plumbing themselves. Rehost is a done-for-you operator based in Los Angeles: we design, build, host, monitor, and run a custom native app for you, push integration included, configured against real APNs/FCM credentials and watched in production. Your team never logs into a dashboard. You own the app, the App Store and Google Play accounts, the domain, the code, and the data, all portable if you cancel. Rehost Business starts at $950/mo billed by monthly active users, no setup fee, with an app shipping in about two weeks. Sanity-check the numbers on the app cost calculator, see how the model works on what is Rehost, or just tell us what your app needs to do.