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:- Autosana installs and opens your test build.
- The app requests notification permission and registers for remote notifications.
- The app associates the resulting token or provider subscription with the test user.
- The flow performs the action that schedules the notification, or runs a runtime hook that calls your existing test endpoint.
- The agent presses Home and waits for the notification.
- The agent verifies the notification, taps it, and checks the destination screen.
Prepare your test environment
Before writing the flow:- Choose a test account that can safely receive notifications in your development or staging environment.
- 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.
- 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.
- Configure the build to use the same push provider and backend environment that the flow will exercise.
Platform requirements
- iOS Simulator
- Android Emulator
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:The output must contain
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-notificationsclient 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, declareaps-environment: developmentunderios.entitlementsin the Expo app configuration, or use the push provider’s config plugin when it manages this capability. - If the project has a native
iosdirectory and does not use Continuous Native Generation, configure the capability in Xcode.
aps-environment with the value development.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 toapi.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 anExpoPushToken, 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, setapns_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 setinProduction to false when your integration selects it explicitly.AWS SNS
Create an SNS platform application whose platform isAPNS_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 forAPNS_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.Create the flow
Trigger the notification from the app
Use the normal application workflow whenever an in-app action schedules the notification. For example: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.-
Add these values to the app’s Autosana environment:
PUSH_TEST_URLPUSH_TEST_API_KEYas a secretPUSH_TEST_USER_ID
-
Create a cURL hook named
Trigger Test Push:
- Reference the hook at the correct point in the flow:
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.