Push notifications are a critical feature to keep users informed and engaged with your app. But when they fail, users may miss updates, lose trust, or even disable notifications entirely. Testing ensures your notifications work as expected across devices, platforms, and app states. Here’s a quick breakdown of what you need to know:
- Permissions: iOS requires opt-in, Android varies by version.
- Device Tokens: Validate token generation, refresh after app reinstalls or OS updates.
- App States: Test notifications in foreground, background, and closed states.
- Navigation: Confirm tapping notifications leads to the correct screen.
- Rich Media: Ensure images, emojis, and links display properly.
- Network and Devices: Test under different network speeds, battery levels, and across multiple devices.
Skipping testing can lead to duplicate messages, sensitive data exposure, or delivery failures. Use real devices for accurate results, and always validate your setup for both iOS and Android. Follow this checklist to avoid common pitfalls and deliver a reliable user experience.
Push Notification Testing: Best Practices and Tools
Pre-Testing Setup Checklist
Push Notification Permissions by Platform: iOS vs Android Comparison
Before diving into test notifications, it's important to configure your environment properly. This helps catch potential issues early and minimizes troubleshooting later.
Check User Permissions and Consent
Permissions for notifications differ depending on the platform, so understanding these nuances is key. Here's a breakdown of how permissions work:
- iOS: Always requires explicit user permission when the app is first used.
- Android 13 and later: Notifications are off by default, requiring users to opt in.
- Android 12 and earlier: Notifications are enabled by default upon installation, unless manually turned off by the user.
Timing matters when requesting permissions. For instance, platforms like Adalo require users to log in before they can accept notification permissions. Without an active login session, the system can’t generate the necessary device token, meaning notifications won’t be sent. Additionally, ensure recipients have been active within the last two weeks, as some systems block messages to inactive users.
Testing should include both positive and negative scenarios. For example:
- Test what happens when users decline permission or manually disable notifications in their device settings.
- Check API responses for a "Failed" status, which usually means permissions have been revoked.
To ensure accuracy, use dual-device testing. Log into two separate accounts on different devices to confirm notifications are sent to the intended user, not the sender.
| Platform | Default State | Permission Request | User Control |
|---|---|---|---|
| iOS | Opt-in (Off) | Required on first use | System Settings |
| Android 13+ | Opt-in (Off) | Required | System Settings |
| Android 12 & Earlier | Opt-out (On) | Granted at installation | System Settings |
Test Device Token Generation
Device tokens are unique identifiers generated by services like Firebase Cloud Messaging (FCM) for Android and Apple Push Notification Service (APNs) for iOS. These tokens are essential for delivering notifications - without a valid token, your message won’t reach its destination.
"When a user installs an app and grants permission for push notifications, the operating system registers the user's device with a push notification service... The notification service generates a unique device identifier (token) which allows further communication to target that specific device." – Masha Filipova, QA Engineer, Trailhead Technology Partners
Make sure tokens are refreshed after events like app reinstalls, device restarts, or OS updates. Test using multiple user accounts on the same device to confirm tokens are user-specific and that notifications stop when a user logs out, resuming only when they log back in.
If iOS notifications fail but Android works, consider deleting the notification key in your Apple Developer account and pushing a new build to reset the token environment. Always test on real devices instead of simulators, as notifications require the app to be installed on physical hardware. You can verify token generation via API responses - if both successful and failed counts return as "0", the app may not be installed, or the token wasn’t created.
Once you’ve ensured proper token generation, move on to creating test accounts and payloads.
Create Test Accounts and Payloads
Set up two test accounts: one as the Sender and the other as the Receiver. Log the Sender into your desktop or web builder, and use a separate physical mobile device for the Receiver to simulate a realistic notification flow.
Prepare test payloads with the following mandatory fields:
- App ID
- Audience Identifier (such as Email or User ID)
- Title
- Body text
For native mobile tests, include the target screen in the payload to confirm that tapping the notification directs users to the correct in-app location. Test payloads should also include elements like emojis, special characters, and links to ensure proper rendering on both iOS and Android.
Make sure your payload logic excludes the logged-in user (Sender) to avoid delivery errors. Test sending the same payload while the Receiver’s app is in three states: foreground, background, and completely closed. For quick API testing, use cURL commands with your App API Key, App ID, and the Receiver’s User ID to verify that the notification endpoint responds as expected.
Testing Notifications in Different App States
Now that your pre-test setups are complete, it's time to dive into how notifications perform in various app states. Whether the app is open, running in the background, or completely closed, testing ensures notifications behave as expected across all scenarios.
Foreground State Testing
When the app is open and visible to the user, notification behavior depends on how you've configured it. This is your chance to tailor how notifications appear to align with your app's design and user experience goals.
Start by ensuring the device displays the notification correctly while the app is in the foreground. Confirm that the notification doesn't crash the app or interfere with unsaved user data. If you're using Adalo, native iOS and Android apps allow you to direct users to a specific "Target Screen" when they tap the notification. However, for PWAs, users are always redirected to the home screen.
Double-check that the notification's title and body text match what was sent from the server. Keep in mind that iOS, Android, and web browsers handle foreground notifications differently, so it’s crucial to test on all platforms.
Once you've confirmed foreground behavior, move on to testing notifications when the app isn't actively in use.
Background and Closed State Testing
To simulate background or closed states, swipe the app away before sending a notification.
When the notification arrives, verify it appears correctly in the device's notification center, including all content like emojis and special characters. Tap the notification to ensure it opens the app and navigates to the correct screen.
Remember, notifications are only sent to users who have been active in your app within the past two weeks. If your test shows "0" for both successful and failed delivery counts, it likely means the user doesn't have the app installed on their device.
Multitasking and App Switching
Testing doesn’t stop with standard app states. Users frequently switch between apps, so it's essential to evaluate how notifications perform during multitasking. Confirm that notifications display correctly while another app is in use, and make sure tapping the banner redirects the user back to your app and the intended screen.
"The best test is with a real device. The emulators... don't account for subtleties like how applications act when they are running in the background or how they interact with other processes on native hardware." – Eric Goebelbecker
Physical devices provide insights that emulators simply can’t replicate. They reveal how your app competes for system resources alongside other running applications, offering a more accurate picture of real-world performance.
Lastly, test notifications under high system load to ensure they’re delivered reliably. Don't forget to check how "Do Not Disturb" mode affects notification visibility and whether notifications appear when the device is locked.
Navigation and Interaction Testing
After ensuring state-testing accuracy, it's time to assess whether tapping notifications directs users to the right screens. When users tap a notification, they expect to land exactly where they need to be - not on an unrelated screen or stuck on the home page.
Tap Navigation Behavior
How navigation behaves depends on your platform and app configuration. For native iOS and Android apps built with Adalo, you can assign a specific "Target Screen" in the builder. This ensures users are taken directly to the intended screen when they tap a notification. If no target screen is set, the notifications won't trigger properly on native devices.
In contrast, for PWAs and notifications sent via the Adalo API, users are always directed to the app's Home Navigation Screen, regardless of any target screen settings.
"When a user taps on a push notification, the app should open and bring the user to the relevant section or content associated with the notification." – Masha Filipova, QA Engineer, Trailhead Technology Partners
Testing should cover scenarios where the app is in the foreground, background, or completely closed. Navigation must remain consistent whether the app is already running or needs to cold start. Pay special attention to background states during multitasking to ensure the app resumes and directs users to the correct internal screen, rather than showing the last viewed page.
| Platform/Method | Navigation Behavior |
|---|---|
| Native iOS & Android | Navigates to the specific "Target Screen" set in the app builder |
| PWA (Web) | Always directs to the app's Home Navigation Screen |
| Adalo API | Currently directs users to the app's Home Navigation Screen |
To further refine navigation reliability, test how the app performs under challenging network conditions.
Offline and Interrupted Scenarios
Real-world usage often involves less-than-ideal conditions. Users may tap notifications while switching between cellular and Wi-Fi, in areas with poor coverage, or even when their device is in airplane mode. Testing these scenarios helps uncover how apps built with Adalo handle such challenges.
For example, place your device in airplane mode and tap a notification. The app should either navigate smoothly to the target screen or display a clear "no connection" message - crashes or freezing are unacceptable. Additionally, test what happens after device interruptions like a full restart or an operating system update to ensure the device token remains valid and notifications continue functioning.
"By testing in various situations, such as when the app is open, closed, or when there's no internet, we can identify and fix any problems that may exist and create apps that have more reliable notifications." – Masha Filipova, QA Engineer, Trailhead Technology Partners
Finally, confirm that logged-out users stop receiving notifications immediately. Notifications should only resume after users log back in. If a user is logged into multiple devices, make sure actions on one device don't disrupt notification delivery or navigation on the others.
sbb-itb-d4116c7
Network and Device Condition Testing
To ensure reliable push notifications, it's crucial to evaluate their performance under various network and device constraints.
Test Across Network Types
Push notifications must work seamlessly across different network conditions. Test delivery on Wi‑Fi, 4G, 5G, and throttled 2G networks using network throttling tools to simulate slower speeds. This helps identify how your app handles delays or timeouts during delivery.
Additionally, check how your app behaves during offline-to-online transitions. For example, ensure that users don’t receive duplicate notifications when their connection is restored.
Test Under Device Constraints
Device settings, such as power-saving modes or low battery levels, can impact notification performance. Test notifications when the device is in power-saving mode (e.g., battery below 20%) to confirm that resource-heavy activities, like frequent polling, are minimized.
After a device restart or an operating system update, verify that the push token remains valid and notifications continue to arrive without issues. For time-sensitive notifications, ensure they are delivered at the correct local time across different time zones.
Multi-Device Testing
Many users access the same account on multiple devices, such as a phone, tablet, and desktop. Test notifications across all devices to ensure each one receives its own unique push token - for example, APNs for iOS and FCM for Android.
"By testing in various situations, such as when the app is open, closed, or when there's no internet, we can identify and fix any problems that may exist and create apps that have more reliable notifications." – Masha Filipova, QA Engineer, Trailhead Technology Partners
For manual testing, use at least two separate accounts: one to send notifications (e.g., on a desktop) and another to receive them (e.g., on a mobile device). Most systems block users from receiving notifications they trigger themselves, so this setup ensures accurate results.
Once network and device conditions are thoroughly tested, you can move on to platform-specific scenarios to complete your push notification testing checklist.
Platform-Specific and Edge Case Testing
iOS vs Android Testing
When it comes to push notifications, iOS and Android take very different approaches, making it essential to test them separately. For instance, iOS requires users to explicitly opt in to notifications right away, while Android 13 and later versions have also introduced permission requests. Earlier Android versions, however, opted users in by default. The technical setup for notifications also differs: iOS relies on Apple Push Notification Service (APNs) certificates, which need annual renewal, whereas Android uses Firebase Cloud Messaging (FCM), configured through a specific file.
Another key difference lies in character limits. iOS notifications can handle around 178 characters, while Android allows for a much larger limit of 663 characters. During testing, ensure the notification text displays properly on both platforms. Even notification visibility behaves differently: on iOS, notifications disappear from the lock screen once the device is unlocked, moving to the notification center. On Android, notifications remain visible until the user manually dismisses them.
"The way notifications work on iOS versus Android isn't just about visual design; it's about completely different philosophies on user experience and system control" – Glance Expert Guide Series
Always test on physical devices to account for hardware-specific behaviors. For example, verify that when an app is reinstalled or a device is rebooted, the old notification token is invalidated and replaced with a new one, ensuring your backend registers the update correctly.
Once platform-specific differences are addressed, extend testing to ensure proper rendering of notifications across languages and media types.
Localization and Rich Media Testing
After accounting for platform differences, focus on localization and rich media to maintain a consistent experience for users worldwide. Check that notification text, including emojis, displays uniformly on both iOS and Android devices. Ensure rich media elements - like images and videos - render properly in all app states. For apps with international users, verify that notifications are compatible with Right-to-Left (RTL) languages and that translated text stays within platform-specific character limits.
Rich media notifications can boost user engagement, but they require careful testing. For example, iOS supports aspect ratios like 4:3, 3:2, 2:1, or 1:1, while Android’s 1:1 images may appear stretched horizontally. To ensure smooth loading, keep image file sizes between 100–200 KB and videos or GIFs under 1 MB. Also, test fallback behavior: if rich media fails to load due to network issues, confirm that a text-only version of the notification is displayed instead.
Push Notification Testing with Adalo
Adalo simplifies cross-platform notification testing with its single-build approach, enabling you to publish one app for web, iOS, and Android from a single codebase. Follow Adalo’s setup guidelines to ensure smooth operation. Make sure the recipient is logged in and active to generate a valid notification token.
For native builds, confirm that a new token is registered after an app reinstall and that a Target Screen is selected for notifications to activate properly. Use the Adalo API (https://api.adalo.com/notifications) to test localized payloads. Keep in mind that API testing is available only with a Team or Business plan.
If notifications work on Android but fail on iOS Native builds, Adalo suggests deleting the notification key in your Apple Developer account and pushing a fresh build. Test across all three platforms - web (PWA), iOS, and Android - to ensure consistent behavior. Note that PWAs always direct users to the Home screen, while native builds allow for custom Target Screens.
Tools and Best Practices for Testing
Testing Tools Overview
Adalo offers a range of tools to simplify and enhance your notification testing process. The platform includes built-in tools that allow you to test push notifications directly, without the need for third-party services. For example, the "Trigger Notification" action within the Adalo builder lets you manually send notifications to logged-in users during testing. For more advanced scenarios, you can leverage the Adalo API (https://api.adalo.com/notifications) to programmatically test scheduled notifications and custom payloads. Keep in mind, this API access is available only with Team or Business plans.
To validate your API setup, tools like cURL come in handy. They let you test API endpoints, headers, and request bodies to ensure your notification server is functioning as expected. When testing, use two separate accounts: one as the Sender (on a desktop) and the other as the Receiver (on a physical mobile device). This is necessary because users cannot receive notifications they trigger themselves. Also, make sure the receiving account has recent activity to ensure notifications are delivered.
Cross-Device Testing
For accurate testing results, always use physical devices running iOS and Android. Web previews are limited in their ability to replicate platform-specific behaviors, such as permission prompts, rich media display, or deep linking. Testing should cover all three app states: foreground (app open), background (app minimized), and closed (app not running). Additionally, confirm that tapping a notification correctly navigates the user to the intended screen. This behavior can vary between native apps and PWAs.
Error Monitoring and Diagnostics
The Adalo API provides real-time feedback to help you troubleshoot issues quickly. A "successful" count indicates the notification was delivered, while a "failed" count suggests the user has revoked notification permissions. If both counts are zero, it likely means the user does not have the app installed. This instant feedback can help pinpoint configuration problems. For example, if notifications work on Android but not on iOS, it may be necessary to delete the notification key in your Apple Developer account and push a new build.
Final Checklist and Key Takeaways
Before hitting publish, make sure you've checked everything off this list. Start by testing notifications with two separate user accounts: one as the sender on a desktop and the other as the receiver on a physical device. Why? Because users can’t receive notifications they trigger themselves. Confirm that notification permissions are enabled after login and that the user has been active in the app within the last two weeks.
Run tests with the app completely closed - not just minimized in the background - to catch any delivery problems. Tap on each notification to ensure it takes users to the correct screen on both native iOS and Android builds. Be aware that Progressive Web Apps (PWAs) will always default to the Home Navigation Screen, no matter your settings.
If you're using the Adalo API for scheduled notifications, a "0" count for both successful and failed responses typically means the recipient doesn’t have the app installed. For iOS-specific issues, try deleting the notification key in your Apple Developer account and pushing a new build. These steps ensure every notification gets delivered as intended.
"Make sure you fully test your components before you publish. This minimizes issues." – Adalo
Thorough testing does more than just prevent technical hiccups - it has a direct impact on user retention and engagement. Reliable notifications delivered at the right time with the right message can bring users back to your app. By validating every possible scenario, you reduce the chances of negative experiences and unnecessary support tickets. Following this checklist ensures your notifications work seamlessly, keeping users engaged and satisfied.
FAQs
What is the best way to test push notifications on different devices and platforms?
To effectively test push notifications, start by setting up multiple test users and devices. For instance, create at least two user accounts - one to send notifications and another to receive them. Make sure the receiving user has granted notification permissions. It’s also important to test on a variety of devices, including iOS, Android, and desktop, to ensure everything works smoothly across platforms.
Next, simulate real-world scenarios by triggering notifications through different user actions and workflows. This includes testing manual triggers within the app as well as API-based notifications to confirm they are delivered consistently. Don't forget to check both scheduled and real-time notifications to see if they function properly, even when the app is running in the background or completely closed on the receiving device.
Lastly, ensure the app is updated to its latest version before testing and address any issues that come up during the process. By following these steps, you’ll be better equipped to provide reliable push notifications across all platforms.
How do push notification permissions differ between iOS and Android?
When it comes to push notifications, iOS and Android handle permissions quite differently. On iOS, apps must explicitly ask for user consent through a prompt when the app is first launched. Users can either grant or deny permission right then and there. On the other hand, Android takes a different approach - push notifications are typically enabled by default, though users have the option to tweak or turn them off for individual apps in their device settings.
Because of these platform-specific behaviors, it’s crucial to test how your app manages notification permissions on both iOS and Android. This ensures that users have a seamless experience, no matter which device they’re using.
Why aren’t push notifications working on my iOS device, and how can I fix it?
If push notifications aren’t showing up on your iOS device, start by confirming that notification permissions are enabled for the app. Without these permissions, notifications simply won’t work. Also, ensure the device is powered on, logged into the correct account, and connected to the internet - push notifications depend on these factors to reach the device.
If the basics check out, take a closer look at the app’s push notification certificates or keys in your Apple Developer account. Any misconfiguration there can block notifications. To dig deeper, try using Apple’s Push Notifications Console. It lets you send test notifications and verify device tokens, making it easier to pinpoint delivery issues specific to iOS.
Related Blog Posts
