.png)
A direct comparison of the main push delivery options — what each actually does, what it costs, and how to think about switching.
What to Evaluate
Most comparison articles for push notification services default to feature checklists. The features that matter in practice are narrower.
iOS and Android support: Every service on this list supports both platforms. The relevant question is how the service handles platform-specific requirements (APNs token-based authentication, FCM HTTP v1 API, Android 13+ runtime permissions) and whether it abstracts that cleanly enough to reduce your maintenance surface.
SDK quality and cross-platform coverage: If your team ships React Native or Flutter, the SDK is the integration surface you will live with. A well-documented, actively maintained SDK with reliable iOS and Android parity matters more than a long feature list.
Targeting and segmentation: Can you send to a specific app version, a device group, or a custom segment? Can you define those segments without writing server-side query logic yourself? Teams that only need broadcast sends have simpler requirements than teams that need per-cohort or per-version targeting.
Delivery analytics: Platform push APIs confirm delivery to the provider's gateway, not to the device, and certainly not whether the notification was opened. Open rates and delivery receipts require additional instrumentation. Whether a service handles that — or whether you are building a custom analytics pipeline — is a meaningful operational difference.
Credential management: Push delivery requires APNs and FCM credentials. Managing these credentials across environments (staging, production), across team members, and across credential rotation cycles is operational overhead that compounds over time. Services differ significantly in how they handle this.
Pricing model: Per-notification, per-MAU, and seat-based pricing models have different cost curves depending on send volume, audience size, and team composition. Evaluate against your actual usage pattern, not theoretical limits.
Migration complexity: Switching push providers requires coordinating token portability, credential reconfiguration, SDK swap, and analytics continuity. Factor migration cost into any evaluation — it is not trivial.
The Main Options
Firebase Cloud Messaging (FCM/APNs direct)
FCM is Google's push delivery infrastructure and the underlying transport layer for most Android notifications. Combined with direct APNs integration for iOS, it covers both platforms at no cost.
What you get: reliable delivery infrastructure, no dashboard, no analytics, no segmentation, no targeting beyond what you build yourself. FCM is a transport, not a product. If your team wants full control over the send path and is willing to build token management, retry logic, delivery analytics, and targeting from scratch, this is the correct choice. If you want a managed product, FCM alone is not it.
The FCM HTTP v1 API is the current standard; the legacy HTTP and XMPP APIs were shut down in June 2024. Teams that have not audited their server-side send code since mid-2024 should verify no references to the legacy API remain.
Expo Push Notifications
Expo Push Notifications provides a unified push notification service for React Native apps built with Expo. It handles communication with FCM and APNs, reducing the amount of platform-specific sending infrastructure developers need to maintain.
What you get: a unified API for iOS and Android, integration with the expo-notifications library, push tickets, and receipts for checking whether notifications reached the underlying push service.
Expo's push service is free, with a documented limit of 600 notifications per second per project. It does not replace a full marketing automation platform with advanced audience segmentation and lifecycle campaigns. Teams that need more control can send notifications directly through FCM and APNs instead.
For development teams already using Expo, this is a practical option that reduces push integration complexity without introducing a separate customer engagement platform.
Braze
Braze is a customer engagement platform that includes push as one delivery channel among many (email, in-app messaging, SMS, content cards). The targeting and segmentation capabilities are enterprise-grade — behavioral triggers, lifecycle campaigns, A/B testing infrastructure, deep CRM integration.
The pricing reflects the scope. Braze is not a push notification service; it is a full CRM platform that includes push. For most mobile development teams evaluating push infrastructure, it is significant overkill. Teams with complex multi-channel lifecycle marketing requirements and budget to match will find it well-suited.
Customer.io
Customer.io is a customer engagement platform that supports push notifications alongside email, SMS, and in-app messaging. It is designed for teams that need automated communication workflows based on customer behavior and data.
Its React Native SDK supports push notifications through APNs and FCM, including rich notifications with links and images. Customer.io also provides Flutter and Expo integrations, allowing teams to connect push notifications with broader customer messaging workflows.
Unlike a delivery-only service, Customer.io focuses on coordinating messages across channels and customer journeys. That adds capabilities beyond basic push delivery but also introduces a broader platform integration.
Teams that need behavioral messaging across multiple channels may find it suitable. Teams looking only for a lightweight push delivery layer should evaluate whether that additional scope is necessary.
AppsOnAir Push
AppsOnAir Push is a push notification layer built within the AppsOnAir OTA distribution platform, currently in beta.
The primary differentiator is integration with the distribution side: if you are already using AppsOnAir to manage internal builds, beta distribution, and app versioning, push targeting maps directly to those existing segments. You can send to testers on a specific app version, to a distribution group, or to custom segments — without configuring separate audience logic.
Credentials are managed once in the same portal used for distribution.
Because it is in beta, it should be evaluated accordingly. Teams not already using AppsOnAir for OTA distribution are taking on a new platform dependency without the baseline integration benefit. Teams already on the platform get push without additional infrastructure.
Comparison
Migration Considerations
Switching push providers is more disruptive than most teams anticipate before attempting it.
Push token portability is the primary friction point. Device push tokens are issued by APNs and FCM respectively — they are not provider-specific. You can migrate tokens to a new provider. The problem is that your token database must be in good shape: stale tokens from uninstalled apps, tokens tied to old app versions, and tokens lacking device metadata all become visible migration problems. A token audit before migration is not optional.
Credential reconfiguration means uploading your APNs .p8 key and FCM service account credentials to the new provider, removing them from the old one, and verifying the new configuration against both platforms before cutting over. This is not complex, but it requires coordination if multiple team members or services currently hold credentials.
SDK swap requires an app release. You cannot swap the push SDK on existing installs without shipping a new build. During the transition window, you are either dual-sending to both providers or accepting that installs on old builds still receive from the old provider. Plan for this gap explicitly — it often extends longer than expected because older builds remain active in the field.
What to audit before migrating:
- Total registered token count vs. estimated active installs — a large discrepancy signals stale token accumulation.
- Token age distribution — tokens not refreshed in 60–90+ days are likely inactive.
- Error rate on current sends —
BadDeviceTokenandUnregisterederror codes from APNs, andUNREGISTEREDfrom FCM, indicate tokens that should already have been cleaned. - Whether delivery analytics are tied to the current provider's attribution — migrating may break historical continuity if analytics are not exported first.
Conclusion
The best push notification service is the one that fits how your team actually works. A team shipping marketing campaigns to millions of users and a team sending build-ready notifications to twenty testers have different requirements and should reach different conclusions. Evaluate based on your send volume, your segmentation needs, your existing stack, and your operational capacity — not on which service has the most features on paper.
If you are already using AppsOnAir for OTA distribution, the push beta extends the same portal without adding a new platform. Push targeting uses the same app version segments and distribution groups already defined for builds. Credentials are managed in the same place. Team access mirrors existing roles. There is no separate push SDK onboarding — the existing AppsOnAir SDK surfaces push. For teams on the platform, this is the lowest-friction path to managed push delivery.
