How Much Do Push Notification Services Cost for Mobile Apps?

Push notification pricing is one of those costs that looks negligible at the start of a project and becomes a genuine budget line by the time a product reaches scale. The question asked too late is not what a service costs at launch, but what it costs at 50,000 users, and whether the architecture chosen on day one makes it easy or painful to switch providers when the bill starts to matter.

The push notification budget gets estimated on the free tier, then the product grows past it.

We have seen this play out on mobile products across travel, social, fitness, and entertainment, and the pattern is consistent. The push notification budget gets estimated based on the free tier, the product grows past the free tier threshold, and the team either absorbs a cost they did not plan for or starts rebuilding integrations at the worst possible moment.

Understanding what drives push notification costs, volume, platform split, segmentation logic, and the technical decisions made during build, lets you plan for the real number rather than the optimistic one. This article works through each of those factors, with the specific decisions and trade-offs we have encountered on real projects.

How Push Notification Pricing Models Actually Work

Push notification services charge in a small number of ways, and understanding which model a provider uses changes how you forecast costs as your user base grows.

The most common structure is pricing by monthly active users (MAU). You pay based on how many unique users your app has, not how many notifications you send. This suits products where each user receives a moderate, consistent volume of messages. The risk is that your cost scales with growth whether or not your notification strategy is generating any return.

Some providers charge by notification volume instead. You pay per message sent, usually in bands. This model rewards restraint, a tightly targeted campaign costs less than a broadcast to your full user base, but it can become unpredictable if send volumes spike.

A third model prices by feature tier rather than usage. You pay a flat monthly fee for access to capabilities: basic broadcast on the lower tier, segmentation and personalisation on higher tiers. Usage is effectively unlimited within the tier, which simplifies forecasting but means you pay for features you do not yet need.

Most services combine elements of these. A free tier up to a user or volume threshold, then MAU-based pricing above it, with advanced features gated behind higher tiers regardless of usage. Knowing which component is going to drive your bill helps you pick the model that fits your actual usage pattern.

Free Tiers: What They Include and Where They Run Out

Every major push notification service offers a free tier, and they are genuinely usable for early-stage products. OneSignal's free plan supports unlimited devices with basic segmentation. Firebase Cloud Messaging (FCM) is free with no stated user limit, though it trades off in analytics and automation. Pusher Beams offers a free tier up to 1,000 devices. The free tier from Braze does not exist in any meaningful sense, Braze is an enterprise platform and prices accordingly from the start.

The ceiling on free tiers is rarely the device count alone. What the free tier typically removes is the capability to do more than broadcast: automated workflows, A/B testing of messages, deep segmentation, rich media, and delivery analytics are usually gated. A product that launches on a free tier and then needs to segment by user behaviour, purchase history, or lifecycle stage will find it needs to upgrade before it has the scale to justify the cost.

Before selecting a free tier, map out the segmentation and automation features your notification strategy actually needs at launch. If those features are gated, you will pay for them sooner than the device count suggests.

The other limit is data. Free tiers often retain notification delivery data for a short window, sometimes 30 days, which makes it hard to understand what is actually working. Analytics on open rates, delivery failures, and user-level behaviour tend to sit on paid plans. That makes the free tier cheap to run but expensive to learn from.

Volume and How It Drives Cost Up

Volume is the most straightforward cost driver, but it interacts with notification strategy in ways that are not always obvious at the planning stage. A product that sends one push notification per user per week to 10,000 users is sending 40,000 messages a month. The same product sending four per week is sending 160,000. The cost difference between those strategies can mean the difference between sitting on a free tier and paying a meaningful monthly fee.

On the travel product we built for group bookings, aimed at adults in their early twenties to mid-thirties, we tried push notifications as one of several re-engagement tactics post-launch. The volume of messages needed to re-engage a dormant user base added up faster than the initial estimates suggested, and the insight was that push notifications are most cost-efficient when they are targeted at a specific user action rather than broadcast to the full install base.

Push notifications are most cost-efficient when targeted at a specific user action, not broadcast to everyone.

What actually drove user growth on that product was the booking flow itself: when someone organised a group trip, the app prompted each individual traveller to download the app to submit passport details and stay connected. One booking for ten people generated nine new users instantly. That loop was far more efficient than a push re-engagement campaign because it delivered a concrete reason to act, not just a reminder.

According to Statista, 2021, 42% of users adjust their notification settings to limit notifications when they receive too many. The cost of sending at high volume compounds: the service bill grows alongside the erosion of the permission you have already earned.

Platform Differences: iOS, Android and What Each Adds to the Bill

iOS and Android handle push notifications differently, and those differences affect both the technical integration and the cost model. On iOS, Apple requires users to explicitly grant notification permission before any push can be delivered. On Android, until version 13, notifications were on by default, users had to actively turn them off. Android 13 brought an opt-in requirement, but historical data still shows a significant gap in opt-in rates between the two platforms.

Platform mix matters for cost because it affects your effective reach per pound spent. If a meaningful portion of your user base is on iOS and your opt-in rate sits below 50%, a large part of your registered device count is generating no deliverable messages, but you may still be paying for those devices depending on how your provider counts MAUs.

We encountered this directly on a bootstrapped social football platform. The target audience was younger and skewed heavily towards Android. Budget constraints midway through the project led us to pause Android development and redirect all remaining budget to the iOS product. The client launched iOS-only, which meant reaching roughly half the potential market on day one. Because the core audience was disproportionately on Android, day-one adoption was around half what it could have been. The client eventually had to introduce advertising and abandon their planned subscription model because the user base was too small to sustain it.

The lesson for notification costs is the same: platform split is not just a development decision. It shapes who you can reach, what your effective audience size actually is, and therefore what your push notification spend is buying you.

Targeting and Segmentation Logic

Basic push notifications are inexpensive to send. Targeted ones cost more to set up and, depending on the provider, more to run, but they are the ones that generate a return. The gap between broadcasting to your full install base and sending a message to the 800 users who abandoned a booking at a specific step is the gap between a notification people find relevant and one they dismiss or, over time, opt out of entirely.

Segmentation logic sits at the heart of what separates push notification tiers. Entry-level plans typically allow basic segments: platform, location, subscription status. Mid-tier plans add behavioural segmentation based on in-app events. Enterprise plans layer in predictive targeting, lifecycle triggers, and real-time personalisation based on live user data.

What segmentation costs in practice

The cost is not always in the per-message fee. On a MAU model, the segmentation capability is tied to your tier, and moving from basic to behavioural segmentation often means stepping up to a pricing band that costs three to five times more. Whether that is worth it depends on whether your notification strategy is actually sophisticated enough to use what the higher tier provides.

Audit the segmentation logic your notification strategy actually requires before selecting a tier. Paying for behavioural segmentation on a product that sends a single weekly digest is waste; staying on a basic tier when you need lifecycle triggers will cost more in lost engagement than the tier upgrade would have.

Cadence and the case for restraint

A useful diagnostic is whether users can reduce their notification frequency without losing anything meaningful in the product. If they can, it suggests the current cadence is serving platform retention goals rather than genuine user needs. That is a cost problem as much as a design one: you are paying to send messages that users are actively tuning out.

How Technical Decisions During Build Affect Long-Term Costs

The choices made during build determine how easy or expensive it is to run, maintain, and change a push notification integration later. A well-abstracted notification layer makes it straightforward to swap providers, test new services, or adjust segmentation logic without a rebuild. A tightly coupled integration makes every change expensive.

On an alcohol buying and selling platform, we started building the mobile product before discovering that the client's existing web application had been built in a way that made a clean API layer impossible to implement. The developer who built the web side had structured it in a way that was too complex to expose cleanly. We ended up embedding web elements from the existing site directly into the mobile product instead.

That workaround added approximately 20% uplift in work across the entire project. Because the client wanted to hold the budget fixed, we dropped features towards the end to compensate. The final product was less scalable and less robust than planned, and any future changes to the integration will carry the same overhead.

The same principle applies to notification infrastructure. If the notification service is wired directly into the application logic rather than abstracted behind a clean interface, switching providers, or even upgrading tiers, becomes a development project rather than a configuration change. Teams often discover this when costs start to climb and they go looking for alternatives.

On a production management product for the motion picture industry, we expected to integrate directly with existing document platforms via their APIs. When we finally got access to those systems, they were far more locked down than anticipated. We had to pivot to an alternative approach, ingesting emails tied to specific production roles to process data indirectly. The challenge was ensuring that workaround felt natural rather than like an extra step to users, since the value of the integration was always that it felt seamless. Getting that right took significantly more time than a direct API integration would have.

When Platform Constraints Force a Workaround

Push notification delivery is not fully in your control. Apple and Google both impose constraints on what can be sent, when, and under what conditions, and those constraints can require architectural decisions that add cost, complexity, or both.

On a peer-to-peer currency exchange product, where users could exchange leftover foreign currency with other travellers at interbank rates, we built the core transfer mechanism well but did not factor in anti-money laundering requirements. Apple flagged the product as a potential vehicle for money laundering due to its unlimited transfer capability. We had to go back and retrofit several layers of compliance: more stringent Know Your Customer checks, enhanced transfer security, and hard limits on the number of transfers between any two parties. Each of those additions was a development cost that had not been in the original plan.

The same dynamic applies to push notifications. Apple's guidelines restrict certain categories of notification content, govern how notification permissions must be requested, and impose rules on background delivery that affect whether a time-sensitive message reaches a user at all. Building around those constraints after the fact is more expensive than accounting for them during design.

Review Apple's and Google's notification guidelines before finalising your notification architecture, not after. Retrofitting compliance is always more expensive than building for it from the start.

On the anonymous messaging app we worked on, we identified a tension between GDPR, which gives users the right to have their data removed, and the legal requirement to retain data in case of criminal investigation. We implemented a data retention policy of around six months, so that deleting an account did not immediately wipe message history. That policy had to be built into the notification and data infrastructure deliberately. Without it, we would have faced either a GDPR risk or an inability to support a police investigation if one arose. The point is that platform and legal constraints shape what your notification architecture has to do, and therefore what it costs to build and run.

The Hidden Cost of Getting Notifications Wrong

The direct cost of a push notification service is the monthly fee. The indirect cost of a poor notification strategy is considerably larger, and it shows up in places that do not appear on the same line in a budget.

Users who receive too many notifications do not stay silent. According to Business of Apps, over 71% of users uninstall apps due to intrusive notifications. That is an acquisition cost written off entirely. Every user acquired through paid channels, referral incentives, or the kind of organic loop we built into the group travel booking flow, where one booking generated nine new users, represents a real spend. Losing that user to notification fatigue is a financial problem.

The damage compounds. An uninstalled app cannot be re-engaged via push, which removes your cheapest re-engagement channel and forces a return to paid acquisition. The cost of replacing a churned user is consistently higher than the cost of retaining one.

The trust dimension

On a marketplace checkout project, we observed that confusion around fees, specifically whether a fee was added on top of a price or already included, caused measurable hesitation and drop-off even when the amounts were small. The same psychology applies to notifications. A user who receives a notification that feels irrelevant or manipulative does not just ignore it. Their trust in the product drops, and that drop affects their behaviour at every subsequent touchpoint, not just their notification settings.

What good looks like

According to eMarketer, 61% of new app users who received push notifications launched the app within the first month, compared to 28% of users who did not receive them. The channel works when what is sent is worth receiving. The cost of getting it wrong accumulates in the service bill, the users you lose, and the acquisition spend required to replace them.

Comparing the Major Push Notification Services

The major services occupy different points on the cost and capability spectrum. Choosing between them is a function of where your product is now and where it needs to be in 18 months.

FCM is free but it is infrastructure, not a platform. It handles delivery but provides almost no campaign tooling, analytics, or segmentation out of the box. Teams using FCM typically pair it with something else for the campaign layer, which adds integration work. OneSignal gives you a faster start with usable tooling on the free tier, but the jump to paid tiers is noticeable once MAU crosses the threshold.

Questions to Ask Before Selecting a Service

The right service is the one that fits your user scale, notification strategy, and technical architecture, not the one with the most features or the lowest entry price. These are the questions worth answering before committing.

1. What is your expected MAU at 6 months, 12 months, and 24 months? Map each provider's pricing against those projections, not just the launch figure.
2. What segmentation does your notification strategy actually require at launch? If basic segments are enough now, make sure upgrading later is a configuration change, not a rebuild.
3. What is your platform split? If your audience skews heavily towards one platform, factor that into your effective reach calculation before estimating what the service will cost to run.
4. How tightly will the notification service be coupled to your application logic? A clean abstraction layer makes provider switching cheap; a direct integration makes it expensive.
5. What analytics does your team actually need? If you need delivery rates, open rates, and cohort-level behaviour data to inform your strategy, make sure those sit on a tier you can afford.
6. What compliance requirements apply? Data retention, GDPR, and platform-specific content rules all have implications for how the notification layer must be built.

On the fitness and wellness product we worked on with two co-founders new to app development, the project never progressed beyond design and research because design sign-off kept getting reversed, approval given to be polite rather than as a genuine decision, and budget exhausted on iterations that added no material value. The same pattern appears in service selection: choosing a provider based on what it looks like rather than what the product actually needs creates rework. The questions above are worth answering carefully before any contract is signed.

Conclusion

Push notification costs are predictable if you plan for the right variables. The free tier will cover your launch. Volume, platform split, and segmentation requirements will determine what you pay at scale. The technical decisions made during build will determine how expensive it is to change anything later.

The social football platform we worked on is a clear illustration of how platform decisions made under budget pressure have downstream effects that outlast the project itself. Launching iOS-only to preserve feature quality was the right call given the constraints, but launching into an audience that was disproportionately on Android meant the notification spend, and the acquisition spend, was reaching a smaller share of the people it needed to reach. The subscription model became unworkable, and advertising came in to fill the gap.

Good notification strategy is not expensive to run. A well-targeted, low-cadence notification programme on a provider that fits your actual scale costs less than a high-volume broadcast strategy and produces better outcomes. The cost of getting notifications wrong shows up in uninstalls, in lost re-engagement channels, and in the acquisition budget needed to replace users who left.

The architecture decision matters as much as the service choice. A notification layer built to be swappable keeps your options open as costs change. One wired directly into application logic turns a configuration decision into a development project every time something needs to change.

If you are weighing up push notification services for a new product or reviewing the costs on an existing one, let's talk about your notification strategy.

This article is part of our guide to App Development Cost.

Frequently Asked Questions