Launching Push Notification Testing

By Jason Steinberg · July 2026 · 5 min read

Why push notifications break silently

Push notifications are a distributed system. Your backend sends a payload to APNs or FCM. The provider accepts it and routes it to the device. The OS decides whether to display it. The app decides what to do when it's tapped.

Four systems. Any one can fail independently. And when something goes wrong, it almost never crashes the app. The notification just doesn't show up, or it shows up and taps through to the wrong screen.

Most teams test push by checking whether the backend sent the message and whether the provider accepted it. Provider dashboards report "95% delivered." That number measures whether APNs or FCM accepted the request. It does not measure whether the user saw the notification, whether the deep link worked, or whether the destination screen loaded correctly.

The gap between "provider accepted" and "user experienced" is where push bugs live. Android 13's runtime permissions alone caused a 20-30% drop in push reach for apps that didn't actively prompt users. That's not a transport error. That's a flow that was never tested end to end.

And users are unforgiving. Research shows that even one push notification per week leads to 10% of users disabling notifications and 6% uninstalling the app when the experience is poor. Each broken deep link or missed notification wastes one of a limited number of re-engagement opportunities.

Autosana now tests the complete push notification journey on iOS Simulators and Android Emulators.

How it works

A push notification test on Autosana follows the same path as a real user:

1. Autosana installs and opens your test build
2. The app requests notification permission and registers for remote notifications
3. The app associates the resulting token with the test user
4. The flow triggers the notification through an in-app action or a runtime hook that calls your test endpoint
5. The agent presses Home and waits for the notification
6. The agent verifies the notification appeared, taps it, and checks the destination screen

Autosana does not need your APNs key or Firebase credentials. Your backend remains responsible for sending the notification. Autosana handles the device, the app, and the verification.

Two ways to trigger

From the app. If an in-app action schedules the notification, the flow describes the action and waits:

Log in as the test user. Accept notification permission. Enable the order-ready reminder. Press Home. Wait up to 30 seconds for an "Order ready" notification. Tap the notification. Verify the app opens the test order.

From a runtime hook. When there's no convenient in-app trigger, a runtime hook calls a test endpoint on your backend. Store the endpoint URL and API key in Autosana, reference the hook in your flow, and the agent waits for delivery before continuing.

Both are natural language. No test scripts, no notification mocking, no simulated payloads.

Every app state matters

Notifications behave differently depending on where the user is when the push arrives. Most teams only test one of these. Autosana can test each separately:

• Background — the app is suspended. Press Home before sending, verify the notification banner, tap it, and check the destination.
• Foreground — the app is open. Verify the app's in-app handling or foreground presentation.
• Cold start — the app is fully terminated. Send the notification, tap it, and verify the deep link resolves correctly from a dead start.
• Notification service extension — verify any modified title, body, attachment, or category produced by the extension before display.

Cold start deep links are where most push bugs hide. The app has no active session, no cached state, and the deep link has to bootstrap everything from scratch. These are the flows teams almost never test because they're hard to reproduce manually.

Provider compatibility

Autosana works with whatever push provider your app already uses. Your backend sends through its normal pipeline. Autosana handles the device side.

Documented setup for: Direct APNs, Firebase Cloud Messaging, Expo Push Service, OneSignal, Customer.io, Braze, Airship, AWS SNS, Azure Notification Hubs, and Iterable.

If your provider isn't listed, the same pattern applies: configure it for the APNs Sandbox environment on iOS, and Autosana handles the rest.

---

Get started

Push notification testing is live now. Full setup instructions, platform requirements, and troubleshooting are in the docs.

Get started at autosana.ai.

Prefer a walkthrough first? Book a demo.