How to Test Push Notifications on Real Android and iOS Devices

Why Do Push Notifications Break on Real Devices?

A push notification is not a message your app draws on screen. It is an over-the-air payload that travels from your backend, through Apple's or Google's delivery service, to a specific device token, and is then rendered by the operating system - often while your app is not even running. Every link in that chain is a real-device concern.

Real hardware is where the parts an emulator glosses over actually execute. These are the failure points that only surface on a physical device:

• Real device-token registration: APNs and FCM issue a token tied to the physical install. A wrong or stale token means the send silently goes nowhere.
• The runtime permission prompt: Android 13 (API level 33) made notifications an explicit runtime opt-in via the POST_NOTIFICATIONS permission, per the Android notification runtime permission documentation. A user who denies it gets nothing, and your app has to handle that path.
• Background and terminated delivery: the OS decides how and when to wake your app. Delivery to a suspended or killed app behaves differently than to a foreground one.
• OEM battery optimization: Samsung, Xiaomi, Oppo, and others layer aggressive background limits on top of stock Android that can delay or drop notifications.
• Tap and deep-link handling: tapping a notification has to route the user to the correct screen, whether the app was open, backgrounded, or cold-started.

This is the same reason hardware-dependent features like fingerprint and Face ID need physical devices. If you automate those flows too, the walkthrough on biometric authentication with Appium uses the same real-device approach.

Can You Test Push Notifications on a Simulator or Emulator?

Yes, but only for the parts that do not touch the real delivery network. Since Xcode 11.4, Apple's iOS Simulator can display a simulated remote notification: you drag an APNs payload file onto the Simulator window or run xcrun simctl push from the terminal. That is genuinely useful for checking how a payload parses and how the banner looks. It is not a real send - it never reaches APNs and uses no device token.

Android emulators with Google Play services can receive real FCM messages, which is closer to production. But they still run stock Android without the OEM battery layers, and Doze and background limits behave differently than on a shipped Samsung or Xiaomi handset. Here is what each environment can and cannot validate:

Use the simulator for a fast inner-loop check while you build the payload. Move to a real device before you trust the result - especially for anything a user experiences when the app is closed.

How Do You Test Push Notifications on iOS (APNs)?

On iOS, every remote notification is delivered by Apple Push Notification service (APNs). There is no way around it - your backend or provider hands the payload to APNs, and APNs delivers it to a device token. Testing the real path on a physical iPhone follows five steps:

• Enable the Push Notifications capability and the correct entitlement in your app target.
• Register with the system using UNUserNotificationCenter and request authorization - this triggers the permission prompt on the real device.
• Capture the APNs device token returned to didRegisterForRemoteNotificationsWithDeviceToken once permission is granted. Log it or surface it on a test screen.
• Send a notification to APNs targeting that token from your backend or provider, using the payload you want to validate.
• Assert on the physical iPhone: the banner appears, the sound and badge are correct, and tapping it deep-links to the right screen.

Registration, token handling, and payload structure are documented in Apple's Registering your app with APNs reference. If your iOS app uses Firebase, FCM forwards to APNs behind the scenes, so you still upload an APNs authentication key to Firebase and the real delivery is an APNs delivery. The permission prompt is where many iOS push flows quietly fail: test the granted path, the denied path, and the path where a user re-enables notifications from iOS Settings.

How Do You Test Push Notifications on Android With Firebase (FCM)?

On Android, Firebase Cloud Messaging (FCM) is the delivery service. The flow mirrors iOS but the tooling is Firebase. To test it on a real Android device:

• Add Firebase to the app with a google-services.json file and the Firebase Messaging SDK.
• Capture the FCM registration token from getToken(). Most apps log it on startup, so you can read it from logcat or expose it on a debug screen.
• Send a test message - either from the Firebase console's Send test message flow or the FCM HTTP v1 API - targeting that token.
• On the real device, open the notification shade and assert the title and body match the payload.
• Tap the notification and confirm the app opens to the intended destination.

A minimal FCM HTTP v1 send looks like this - useful for scripting notifications into a test run rather than clicking through the console each time:

curl -X POST \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  https://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send \
  -d '{
    "message": {
      "token": "DEVICE_FCM_TOKEN",
      "notification": {
        "title": "Order shipped",
        "body": "Your order #1234 is on the way"
      }
    }
  }'

The token, payload keys, and delivery options are covered in the Firebase Cloud Messaging documentation. Remember the Android 13 permission gate: on newer devices the notification will not appear at all unless the user has granted the runtime notification permission, so make granting it part of your setup and test the denied path separately.

How Do You Automate Push Notification Testing With Appium?

Appium does not send the push - it verifies the result. A common mistake is reaching for Appium's mobile: pushNotification command, but per the Appium XCUITest driver reference, that command only simulates a notification on the iOS Simulator through simctl and does not work on real iOS devices. The reliable pattern on real hardware is: trigger the notification through FCM or APNs, then use Appium to open the tray, assert the content, tap it, and validate the destination screen.

The critical capability is isRealMobile. With Appium desired capabilities, TestMu AI defaults to emulator and simulator execution - real device execution requires explicitly setting isRealMobile to true. Point the driver at the TestMu AI mobile hub and open the notification shade with driver.openNotifications():

// Real Android device on the TestMu AI cloud grid
UiAutomator2Options options = new UiAutomator2Options();
options.setPlatformName("android");
options.setDeviceName("Galaxy S24");
options.setPlatformVersion("14");
options.setApp("lt://APP_ID");          // your uploaded .apk / .aab build
options.setAutomationName("UiAutomator2");

HashMap<String, Object> ltOptions = new HashMap<>();
ltOptions.put("w3c", true);
ltOptions.put("isRealMobile", true);    // route to a REAL device, not an emulator
ltOptions.put("build", "Push Notification Tests");
ltOptions.put("name", "FCM delivery - background state");
ltOptions.put("network", true);         // capture network logs
ltOptions.put("devicelog", true);       // capture device logs
options.setCapability("LT:Options", ltOptions);

String hub = "https://" + LT_USERNAME + ":" + LT_ACCESS_KEY
           + "@mobile-hub.lambdatest.com/wd/hub";
AndroidDriver driver = new AndroidDriver(new URL(hub), options);

// 1) Trigger the push from your backend / FCM while the app is backgrounded.
// 2) Open the notification shade and assert the notification arrived.
driver.openNotifications();
WebElement push = new WebDriverWait(driver, Duration.ofSeconds(20))
    .until(ExpectedConditions.visibilityOfElementLocated(
        By.xpath("//*[contains(@text,'Your order #1234 is on the way')]")));

// 3) Tap the notification and assert it deep-links into the app.
push.click();
Assert.assertTrue(driver.findElement(By.id("com.myapp:id/order_detail")).isDisplayed());

On iOS, swap in XCUITestOptions and keep isRealMobile true; because mobile: pushNotification is off the table on real hardware, you trigger via APNs and assert the banner and tap-through the same way. For the desired-capabilities details, see the guide to Appium capabilities, and for asserting the system dialogs that appear alongside notifications, the walkthrough on handling alerts and popups in Appium. New to the framework? Start with the Appium tutorial to run your first cloud session.

What Push Notification States and Behaviors Should You Test?

A single "did the notification arrive?" check misses most real bugs. Push behavior changes with the app's state, so validate each one independently:

Beyond states, cover the behaviors users actually hit:

• Permission grant vs deny: the app must handle both, and the re-enable-from-Settings path.
• Deep links: a tap routes to the exact screen referenced in the payload.
• Rich content: images, action buttons, and collapsed or grouped notifications render correctly.
• Badges and counts: the app icon badge updates and clears as expected.
• Poor network: delivery on 2G, 3G, or an intermittent connection, and recovery when connectivity returns.

Foreground, background, and terminated delivery are defined at the OS level by Apple's UserNotifications framework and Android's notification system, which is exactly why they must be observed on real devices rather than inferred.

How Do You Run Push Notification Tests at Scale on a Real Device Cloud?

One real iPhone and one real Android phone on a desk cover two configurations. Production is thousands. A real device cloud closes that gap: TestMu AI provides on-demand access to 10,000+ real Android and iOS devices, so the same push test runs across OS versions and OEM skins without a physical device lab.

For push notification testing specifically, four capabilities matter:

• Real hardware via isRealMobile: execution runs on physical devices, so device tokens, permission prompts, and OEM battery rules are genuine.
• Network profiles: apply 2G, 3G, 4G, 5G, offline, or custom throttling to confirm delivery holds up on the connections real users have.
• Parallel execution: run the same notification scenario across many devices at once, compressing a device-matrix sweep from hours to minutes.
• Session artifacts: every run captures device logs, network logs, video, and screenshots, so a missing push can be traced to the send, the token, or the OS instead of guessed at.

Because pre-release builds often are not published to the app stores yet, a secure tunnel lets a cloud device reach a build hosted on your own network, so you can validate push flows on a staging build before it ships.

Conclusion

Start small: capture a real device token from a debug build, send one notification through FCM or APNs, and assert it on a real phone across foreground, background, and terminated states. Once that loop is solid, wrap it in Appium with isRealMobile set to true and add the permission, deep-link, and poor-network cases.

From there, scale the matrix on TestMu AI's real device cloud so the same suite runs across the Android and iOS versions your users actually carry. The getting started with Appium testing docs walk through connecting your first real-device session, and a push that has been validated on real hardware is one you can ship with confidence.