Sendrealm vs FCM, APNs, and Expo Push: Which Layer Should You Use?

Choosing a push notification solution is confusing because the names often describe different layers of the delivery path.

Firebase Cloud Messaging, or FCM, is Google’s cross-platform messaging service and the native delivery path used by Android applications. Apple Push Notification service, or APNs, is Apple’s delivery network for iPhone and iPad applications. Expo Push Service is an intermediary that accepts Expo push tokens and forwards notifications to FCM or APNs. Sendrealm is a customer messaging platform that manages provider credentials, device registration, identity, audiences, campaigns, automations, analytics, and delivery through those underlying networks.

These are not four interchangeable products. FCM and APNs are infrastructure that mobile push ultimately depends on. Sendrealm does not replace their device networks; it gives teams a consistent operational layer above them. Understanding that architecture makes the comparison much more useful.

The delivery chain in one picture

For a Sendrealm mobile push, the path looks like this:

Your product, backend, campaign, or automation
                    ↓
               Sendrealm
          ↙                    ↘
   FCM for Android          APNs for iOS
          ↓                    ↓
     Android device          Apple device

For an Expo Push Service implementation:

Your backend
     ↓
Expo Push Service
  ↙             ↘
FCM             APNs
 ↓               ↓
Android          iOS

For direct provider integration, your own backend assumes the orchestration role:

Your backend, token database, segmentation, retries, and analytics
          ↙                                      ↘
        FCM                                      APNs
         ↓                                        ↓
      Android                                     iOS

The final provider remains Google or Apple in every mobile case. The decision is about what your team wants to build and operate before the request reaches that provider.

What FCM provides

Firebase Cloud Messaging is a cross-platform service for notification and data messages. A trusted environment, such as an application server or Cloud Functions, sends through the Firebase Admin SDK or FCM protocol. Client applications receive messages using the platform SDK.

FCM is essential for Android delivery and can also be used as a cross-platform sending interface. On iOS, messages still travel through APNs behind the scenes, so Apple credentials and behavior remain part of the path.

FCM provides important primitives:

• notification and data messages;
• delivery to a device token;
• groups and topic subscription targeting;
• platform-specific payload controls;
• SDKs and server protocols;
• integration with the wider Firebase ecosystem.

If a team sends directly, it still needs to decide how product users map to tokens, how invalid tokens are removed, how preferences are stored, how segments are computed, how schedules and recurring journeys work, how message content is managed, and how support investigates a customer.

Those are not shortcomings in FCM. They are concerns at a higher product layer. FCM is very good at being a provider network and protocol. It is not intended to be a complete cross-channel lifecycle operating system.

What APNs provides

Apple Push Notification service is Apple’s remote notification infrastructure. Your provider server authenticates with APNs, builds a payload, includes a device token, and sends over Apple’s supported connection. APNs handles the encrypted persistent connection to Apple devices and applies platform delivery behavior.

Direct APNs integration gives access to Apple’s native concepts and newest provider features without waiting for another abstraction. It also makes your team responsible for:

• token-based or certificate-based provider authentication;
• APNs HTTP/2 requests and responses;
• device-token storage and association;
• sandbox and production environments;
• topic and Bundle ID correctness;
• expiration, priority, collapse, and payload fields;
• error processing and inactive token cleanup;
• provider connection behavior and observability.

APNs identifies an app installation, not a complete customer relationship. If one customer has an iPhone, an iPad, a web subscription, and an email address, the application has to build the identity and preference layer that connects them.

Apple also makes clear that remote notification delivery is not guaranteed. The provider may store, coalesce, delay, or omit notifications depending on device state and delivery conditions. Any platform built above APNs must preserve that best-effort reality.

What Expo Push Service provides

Expo Push Service simplifies mobile delivery for Expo applications. The app obtains an Expo push token, the backend sends to Expo’s API, and Expo queues the message for FCM or APNs. Push tickets and receipts expose provider handoff errors.

This is attractive when a team wants a straightforward mobile-only path and already uses Expo tooling. It avoids writing separate FCM and APNs send clients and offers a common message shape.

Expo’s own documentation notes that communicating directly with FCM and APNs is more complex but offers finer-grained control and access to provider features. Expo also supports obtaining native device tokens when a team wants to use another provider. The client library is not a permanent lock-in.

Expo Push Service remains a delivery intermediary, not a full email-and-push lifecycle platform. The application still needs to manage customer identity, durable audiences, preference topics, campaigns, complex automations, cross-channel analytics, and operational collaboration elsewhere.

Expo Go is also not the production path for modern native push integrations. Development builds, prebuild, expo run, or EAS builds include the required native modules and app-specific credentials.

What Sendrealm adds above FCM and APNs

Sendrealm uses the native providers while giving product, engineering, lifecycle, and operations teams one place to manage the customer communication around them.

One sending model across platforms

Trusted backend code calls one Sendrealm API or SDK. Sendrealm routes Android devices through FCM and iOS devices through APNs using the credentials configured for the Push App. Web subscriptions can participate through the web push path.

A direct send can target a Sendrealm device ID, an external product user ID, a contact, an email identity, or a raw token. Campaign and scheduled flows can target audiences. Each request uses one explicit targeting style so the scope remains understandable.

The sender can still provide Android and iOS overrides for behavior that differs by platform. A shared API does not require identical payloads.

Device registration SDKs

Sendrealm provides device-side SDK paths for Android, iOS, React Native bare, React Native Expo builds, and React web push. Those SDKs initialize the app, register provider tokens or subscriptions, expose permission state, link identity, record app-observed context, track notification opens, and return support diagnostics.

The React Native integration uses @sendrealm/react-native for both bare and Expo projects. See the Expo SDK guide and bare SDK guide.

Identity above tokens

Raw provider tokens are implementation details. Product teams usually think in customer IDs, accounts, emails, segments, and preferences.

After the app calls login(userId, email), a trusted backend can target the external user ID rather than managing a private token lookup for every send. A customer’s current devices can remain connected to the contact model. Logout and subscription changes update the operational state.

This is especially valuable when the same customer uses several devices or channels. Identity becomes a platform concern instead of being reimplemented by every notification producer.

Audiences and preferences

FCM topics are useful provider-level targeting primitives, but a lifecycle audience often needs richer conditions: account plan, locale, product behavior, topic preference, recent events, or a combination of contact and device state.

Sendrealm audiences, properties, topics, and events provide that layer. The same audience model can support email, push, and cross-channel campaigns. Teams do not need to export a segment into a second product solely because the next step uses another channel.

Campaigns and automations

Direct provider APIs deliver requests; they do not define the complete business journey. Teams still need scheduling, reusable content, waits, conditions, exit rules, reviews, and recovery.

Sendrealm supports direct product-triggered push, audience campaigns, scheduled sends, reusable templates, and event-driven automations. A single event can send email, wait, evaluate customer state, send push, or update an audience. The orchestration uses the same contact and delivery context.

Email and push together

This is the largest difference from a push-only abstraction. Sendrealm includes transactional email, campaigns, push, contacts, audiences, topics, events, templates, automations, and analytics in the same project.

A failed-payment journey can email a durable billing notice and send a push that opens the payment screen. A shipping update can use push for immediacy and email for the receipt-like record. A customer without a subscribed device can follow an email path without a separate identity sync.

The question becomes “Which communication fits this moment?” rather than “Which provider owns this user?”

Operational visibility

Sendrealm records its own request, queue, provider, device, and engagement evidence where supported. SDK diagnostics expose device ID, token presence, permission, subscription state, environment, version, and errors useful during setup.

No service can honestly promise that a provider-accepted push appeared on the screen. Android power rules, notification channels, network state, manufacturer behavior, iOS Focus, summaries, user settings, and provider throttling remain outside a sender’s control. The advantage is a clearer investigation path, not a fictional guarantee.

Usage-based pricing

Sendrealm’s push pricing follows notifications sent rather than charging based on registered devices or monthly active users. Segmentation, analytics, delivery reporting, device management, and opt-out handling are included with push usage according to the current push product page.

This aligns the bill with communication volume. A growing installed base does not automatically become a larger push bill when the team sends the same number of relevant notifications. Teams should still check current rates and model their actual traffic before choosing a provider.

Agent-ready operations

Through Sendrealm MCP, compatible AI clients can inspect provider readiness, devices, audiences, templates, automations, and delivery evidence; prepare work; run bounded tests; and hand broad production actions to a human approval boundary.

This is not a provider-network feature. It is an operational layer built around the messaging project. Learn more in the Sendrealm MCP overview.

Side-by-side comparison

The table compares responsibilities, not just API syntax. Direct provider delivery can have a low vendor bill while carrying a larger internal engineering and operations cost. A managed platform adds a service cost while removing parts of the infrastructure your team would otherwise own.

What your team owns with direct FCM and APNs

Direct integration is a real option, especially for teams with mature messaging infrastructure. Make the decision using the complete ownership list.

Your backend may need:

• a device-registration endpoint;
• a secure token database;
• mapping between users, accounts, and devices;
• token rotation and invalid-token cleanup;
• separate FCM and APNs authentication;
• payload generation for Android and iOS;
• retry, rate-limit, and idempotency policies;
• schedules, queues, and failure recovery;
• audience computation and exclusions;
• preference and opt-out enforcement;
• template storage and localization;
• provider response normalization;
• delivery and interaction analytics;
• internal tools for support and campaign operators;
• audit logs and access controls;
• bridges to email or other channels.

None of those tasks is impossible. The question is whether building them creates a product advantage for your company.

When direct providers may be the right choice

Sendrealm is not automatically correct for every architecture. Direct FCM and APNs can make sense when:

• the company already has a mature token, identity, queue, preference, and analytics platform;
• the application needs a new provider-specific feature before higher-level platforms expose it;
• extremely custom payload or connection behavior is central to the product;
• push is an internal infrastructure capability rather than a lifecycle channel;
• the team intentionally accepts the engineering ownership in exchange for maximum control;
• regulatory or deployment requirements demand a custom provider-server boundary.

Even then, calculate maintenance and on-call work, not only per-message vendor cost. Provider APIs evolve, credentials rotate, mobile platforms change permission and background behavior, and customer-facing operators still need tools.

When Expo Push Service may be enough

Expo Push Service can be a strong fit when:

• the app is fully centered on Expo;
• the immediate need is mobile push rather than cross-channel lifecycle messaging;
• the team is comfortable managing customer-token mappings and campaign logic itself;
• Expo push tickets and receipts provide enough operational evidence;
• the application does not need the broader Sendrealm audience, email, automation, or MCP model.

It offers a focused and approachable path. Moving to another sender later is possible because Expo applications can obtain native device tokens, but that migration still requires server and identity work.

When Sendrealm is the stronger fit

Sendrealm becomes particularly valuable when several of these are true:

• the product ships on Android and iOS, with web push now or later;
• the mobile codebase includes Expo builds, bare React Native, or both across products;
• teams want to target customers and audiences rather than manage raw tokens;
• push and email belong to the same onboarding, activation, billing, or retention journeys;
• lifecycle teams need templates, campaigns, schedules, and automations without building internal tools;
• support needs recipient- and device-level evidence in one place;
• the organization wants usage pricing that does not grow merely with registered devices;
• development and production need explicit separation;
• AI assistants should inspect and prepare work without receiving provider credentials or unilateral production-send authority.

The value grows with coordination. If the only requirement is one hard-coded Android notification to one token, a direct FCM call may be enough. If the requirement is to operate customer communication across identities, devices, audiences, channels, and teams, the managed layer becomes more valuable.

A backend send with Sendrealm

The application registers and links the device through a Sendrealm device SDK. Trusted backend code sends using the server SDK:

import Sendrealm from '@sendrealm/sdk';

const client = new Sendrealm({
  apiKey: process.env.SENDREALM_API_KEY
});

await client.push.notifications.send({
  app_id: 'YOUR_SENDREALM_APP_ID',
  external_ids: ['user-123'],
  notification: {
    title: 'Payment confirmed',
    body: 'Your subscription is active.',
    launch_url: 'myapp://billing'
  },
  data: {
    invoice_id: 'inv_123'
  },
  android: {
    channel_id: 'billing',
    sound: 'default'
  },
  ios: {
    sound: 'default',
    badge: 1
  }
});

The API presents one customer-facing operation while retaining platform overrides. Sendrealm then uses the configured Firebase and APNs credentials for the actual provider requests.

Never put SENDREALM_API_KEY, Firebase service account JSON, or an APNs .p8 key in client code. Mobile clients use the public Push App ID only. See the mobile credentials guide for the exact separation.

Migrating from direct providers

A migration does not require changing every product journey at once.

1. Create a Sendrealm Push App for the exact Android package and iOS Bundle ID.
2. Upload the existing Firebase service account and APNs key values securely.
3. Install the Sendrealm device SDK in a development build.
4. Register one Android and one physical iOS test device.
5. Link controlled test users with stable external IDs.
6. Send explicit tests from trusted backend code.
7. Compare provider responses and device behavior with the old path.
8. Move one bounded product notification or automation.
9. Monitor registrations, invalid tokens, opens, and support diagnostics.
10. Retire the old token endpoint and send path only after the rollback period.

Avoid running two independent SDK registration systems indefinitely. Expo’s notification guidance also warns that mixing client-side implementations can create conflicts. Define which SDK owns registration, permission, and open handling during every migration stage.

The useful comparison is build versus operate

FCM and APNs answer: “How does this payload reach an Android or Apple device?” Expo Push Service answers: “How can an Expo-oriented app send to both providers through one service?” Sendrealm answers a broader question: “How does our team operate push as part of customer communication?”

That broader layer includes the identities behind devices, the audiences they belong to, the events that trigger communication, the templates and schedules used by operators, the email alternative or companion, the evidence available to support, and the safeguards around production actions.

Using Sendrealm does not remove FCM or APNs from the architecture. It removes the need for every application team to rebuild the same orchestration around them.

Evaluate the option that matches your actual problem:

• Choose direct FCM or APNs for provider-level control when you are prepared to own the surrounding platform.
• Choose Expo Push Service for a focused Expo mobile delivery path when its scope matches the product.
• Choose Sendrealm when push needs to work with customer identity, audiences, events, campaigns, automations, analytics, email, and agent-assisted operations in one project.

Explore the Sendrealm push platform, review the SDK overview, or begin with the mobile provider credential guide.