Skip to main content
Autosana can test the complete push-notification journey on iOS Simulators and Android Emulators: your app registers for remote notifications, your backend or managed provider sends a real notification, and the flow verifies both delivery and deep-link behavior. Use this guide for visible notifications such as alerts, reminders, messages, and order updates.
Push-notification testing on physical iOS and Android devices requires an enterprise contract. Contact us for private-device availability and setup.

How a push test works

A typical test 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 or provider subscription with the test user.
  4. The flow performs the action that schedules the notification, or runs a runtime hook that calls your existing test endpoint.
  5. The agent presses Home and waits for the notification.
  6. The agent verifies the notification, taps it, and checks the destination screen.
Autosana does not need your APNs key or Firebase service-account credentials. Your backend or managed provider remains responsible for sending the notification. Depending on the integration, your backend may store a raw APNs device token, an FCM or Expo registration token, or a managed-provider subscription.

Prepare your test environment

Before writing the flow:
  1. Choose a test account that can safely receive notifications in your development or staging environment.
  2. Make the app send its latest device or registration token to your backend—or refresh its managed-provider subscription—after login and whenever the registration changes.
  3. Make sure your backend or provider can confirm that the current push registration is associated with the test account before the flow triggers the notification.
  4. Configure the build to use the same push provider and backend environment that the flow will exercise.
A dedicated account is not required for sequential tests; you can reuse an existing automation account. If push tests can overlap, give each run or worker a separate account or another unique targeting key. Reusing one account can cause a notification to reach the wrong run when registrations overwrite one another or multiple registrations remain associated with the same user.
Treat push registrations as temporary. Installing a new build, clearing app data, or resetting a virtual device can change the token or provider subscription. Refresh it during every run; do not copy one from an earlier run into the flow.

Platform requirements

Autosana supplies an iOS 16 or later Simulator runtime. Your app’s minimum deployment target can be lower than iOS 16.Configure the remaining requirements in your project:EAS Build and the Expo Push Service are independent. EAS Build syncs the Apple capabilities declared by your project, but running eas build alone does not add the push entitlement.
  • If the app uses the expo-notifications client library, add its config plugin. The plugin adds the development APNs entitlement even when your backend sends directly through APNs, FCM, or another provider instead of the Expo Push Service.
  • If the app does not use expo-notifications, declare aps-environment: development under ios.entitlements in the Expo app configuration, or use the push provider’s config plugin when it manages this capability.
  • If the project has a native ios directory and does not use Continuous Native Generation, configure the capability in Xcode.
You can verify the uploaded build before compressing it:
The output must contain aps-environment with the value development.
iOS Simulator tokens only work with the APNs sandbox. If your backend connects to APNs directly, send these tokens to api.sandbox.push.apple.com. Do not send them to the production endpoint, api.push.apple.com; APNs will reject the token, commonly with a BadDeviceToken response.If you send through Firebase, Expo, OneSignal, or another push provider, you normally do not select the APNs hostname yourself. Make sure that provider is configured to deliver this development build through the APNs sandbox.

Configure your push provider

Your provider must preserve the Simulator token’s development environment all the way to APNs. Use the matching instructions below; if your provider is not listed, look for its development, sandbox, or APNs environment setting.

Direct APNs

Send the Simulator token to api.sandbox.push.apple.com and use the app’s Simulator bundle ID as the apns-topic. Do not retry a BadDeviceToken response against the production endpoint.

Firebase Cloud Messaging

Continue sending the FCM registration token through the normal Firebase Admin SDK or FCM HTTP v1 endpoint. In the Firebase console, make sure the iOS app has a development APNs authentication key or certificate; FCM handles the connection to the APNs sandbox.

Expo

When using an ExpoPushToken, send to the Expo Push Service normally. Install expo-application so expo-notifications can detect the iOS push environment, or pass development: true to getExpoPushTokenAsync for the Simulator build. Do not force development to false. If you retrieve a native APNs token and send it yourself, follow the Direct APNs instructions above.

OneSignal

Configure the OneSignal app for the APNs development environment. If you provision it through the OneSignal API, set apns_env to development because the API defaults this field to production; use a .p8 key enabled for both Sandbox and Production.

Customer.io

In Workspace Settings > Push > iOS, enable Send all push notifications to sandbox. Customer.io recommends using a separate workspace for the sandbox environment, which also prevents Simulator registrations from mixing with production users.

Braze

Use a separate Braze App or App Group for the development build and configure it with the development APNs credential. Braze allows only one active .p12 certificate per app, so do not replace a live app’s production certificate just to test a Simulator build.

Airship

Initialize the Simulator build with the Airship development/test app key and secret. Let the current Airship SDK infer the APNs environment from the build, or set inProduction to false when your integration selects it explicitly.

AWS SNS

Create an SNS platform application whose platform is APNS_SANDBOX, register the Simulator token against that application’s ARN, and send through the resulting endpoint. Do not register the token under an APNS production platform application.

Azure Notification Hubs

Use a separate notification hub configured under Apple (APNS) in Sandbox mode. Do not switch a shared production hub to sandbox because registrations are tied to the APNs environment.

Iterable

Configure the Iterable app for APNS_SANDBOX and target the token generated by the Simulator build. A production registration or production push credential cannot be used with that token.Each Simulator and host Mac combination receives its own token, and the token’s length can vary. Store the token as an opaque string without assuming a fixed size or format.If you use Firebase Cloud Messaging on iOS, use Firebase Apple SDK 10.3.0 or later and configure an APNs authentication key in the matching Firebase project. If Firebase method swizzling is disabled, pass the APNs token to Firebase Messaging in your app code.
See Building Your Mobile App for Our Cloud for artifact and architecture requirements.

Create the flow

Trigger the notification from the app

Use the normal application workflow whenever an in-app action schedules the notification. For example:
The scheduling action and delay belong to your application. Autosana only needs instructions that describe when to press Home, how long to wait, what notification to expect, and what should happen after it is tapped.

Trigger the notification with a runtime hook

Use a runtime hook when the application has no convenient in-app trigger. The hook should call a narrow test endpoint that tells your backend to send a named notification to the dedicated test user.
  1. Add these values to the app’s Autosana environment:
    • PUSH_TEST_URL
    • PUSH_TEST_API_KEY as a secret
    • PUSH_TEST_USER_ID
  2. Create a cURL hook named Trigger Test Push:
  1. Reference the hook at the correct point in the flow:
Runtime hooks run synchronously, so the agent waits for the endpoint response before continuing. A successful endpoint response confirms only that your backend accepted the request; the notification appearing on the virtual device is the end-to-end assertion.
Have the test endpoint return a distinct error when the test user has no current push registration. This makes registration failures easier to distinguish from provider delivery failures.

Test the important app states

Create separate flows when your application handles notifications differently in each state:
  • Background: press Home before sending, then verify and tap the notification.
  • Foreground: keep the app open and verify the app’s foreground presentation or in-app handling.
  • Cold start: terminate or fully close the app through your normal test workflow, send the notification, and verify the deep-linked destination after tapping it.
  • Notification service extension: verify any modified title, body, attachment, or category produced by the extension.
Background or silent data delivery is controlled by the operating system and is not guaranteed to run immediately. Use bounded waits, avoid sending notifications repeatedly in a tight loop, and retain physical-device coverage for business-critical background processing.

Testing notifications on real devices

For device selection, run behavior, and availability, see Real Device Testing. For supported artifacts and standard physical-device build instructions, see Real device builds. Physical push-notification testing uses private devices so the app’s original signing and notification entitlements can be preserved. It requires an enterprise contract; contact us for availability and onboarding.

Troubleshooting

Provider references