Which service do you recommend, OneSignal or Firebase Cloud Messaging?

It depends on what else you already run. If Firebase handles authentication, storage, or analytics in your stack, FCM keeps everything in one place. OneSignal gives you a dashboard, journeys, and cross-platform reporting earlier, which suits teams without a backend engineer on hand. We also connect straight to APNs and FCM when a client wants no third party in the delivery path.

How do you measure whether a notification was actually delivered?

We log the moment our backend hands a payload to APNs or FCM, then match that against the platform delivery reports. A phone that is offline, uninstalled, or saving battery will not collect the message, so an accepted send is not a delivered one. The dashboard separates accepted, delivered, opened, and the deep link screen that actually loaded.

How many notifications per week is too many?

There is no universal number, because tolerance depends on what each message is worth to the reader. We set a per-user cap per day and per week, keep transactional messages on a separate budget so an order update never waits behind a promotion, and apply quiet hours per timezone. Then we watch disable rates on each platform and lower volume wherever they climb.

Can you add push to an app that never had it?

Yes, and that is most of the work we take on. We register devices, add a preferences screen, move any client-side send logic into an authenticated server function, and wire deep links to screens that already exist. The app does not need to be rebuilt to gain the pipeline.

What does notification setup cost?

Work is quoted at our flat rate of $39 per hour, or as a fixed scope once we have seen the app and the events you want to send. Inside a mobile MVP build the pipeline sits within the typical order of $4,800 to $8,500 across four to six weeks that our pricing page lists. Added to a live app on its own, the job usually stays inside a few weeks unless you want a full preference center and an attribution model.

Push Notification & Messaging System Setup

Push notification setup on OneSignal, Firebase Cloud Messaging, or direct APNs: permissions, segments, frequency caps, deep links, and delivery tracking.

See our work:

Voteme App→Walking Cure→Wish Manifestation→

Push Notification & Messaging System Setup

Push is usually the last part of a mobile product to get engineering attention. The permission prompt appears during onboarding, before the user knows what the app is for, and the first campaign goes to the whole install base. A month later, more people have notifications switched off than read them.

The channel works when the policy around it holds: who receives what, how often, and at which hour.

What we build

A pipeline has three parts, and they fail separately.

The delivery path runs from your backend to APNs on iOS and FCM on Android. OneSignal or Firebase Cloud Messaging can sit above both to manage tokens, segments, and scheduling, and some clients call APNs and FCM directly.

The audience model holds tokens, user attributes, topics, and behavioral segments. Tokens change on reinstall or phone restore, so it has to refresh itself and retire dead devices.

The policy layer sets the budgets, quiet hours, caps, and preferences screen that decide who may receive what, with an in-app inbox for everyone who declined push.

Why notifications get ignored when frequency is not managed

Permission is granted once and revoked once. Someone who finds your app noisy does not mute one campaign, they switch off notifications for the whole app in system settings. On iOS they can also leave messages delivered quietly to the notification center, which counts as delivery while nothing reaches the lock screen.

Relevance matters as much as volume. A message sent to every install reaches people in the wrong city, on the wrong plan, at the wrong stage of use, and they learn it was not addressed to them. After two or three, the fourth goes unread even when it is exactly right.

Per-user caps per day and per week.
A separate budget for transactional messages, so an order or security notice never waits behind a promotion.
Quiet hours per timezone, with a next-morning fallback instead of a 03:00 send.
Priority handling, so Android delivers an update quietly instead of interrupting.

Who this is for

Marketplaces and on-demand services where order and booking updates are the pulse of the product. Community apps where replies and mentions bring people back. Subscription products needing renewal reminders on time. Clinics with appointment reminders. Internal tools that page a person when a job fails.

What we deliver

The first permission ask

The prompt belongs in onboarding, planned so the ask lands after a moment where the value is visible: a first booking, a first saved item, a first reply. On iOS we can start with provisional authorization, which delivers quietly until the user promotes messages to alerts. A preferences screen lets someone keep order updates and turn promotions off, while behind the prompt we register the device token, refresh it on platform change, and keep permission state on the server.

Transactional and marketing on separate tracks

Order, booking, security, and account messages ride one track. Promotions, announcements, and re-engagement ride another, with separate caps, senders, analytics, and Android notification channels, so a user can turn off offers without losing a delivery update.

Segments, topics, and relevance

Audiences come from app events and profile attributes: city, language, plan, last activity, and whether a person completed the action a campaign asks for. Topic subscriptions cover interest streams the user chooses, and sends go to a defined segment computed at send time, so a list exported last week cannot reach people who already changed plans.

Deep links that land on the right screen

The payload carries its destination and the entity it refers to, so a message about an order opens that order instead of the home screen. We handle the three states of a tap: app closed, in the background, and open. If the target no longer exists, the app falls back to a parent screen, and web links open the app when it is installed.

In-app inbox

An inbox keeps every message retrievable inside the app. It serves people who declined push and holds messages worth reading later but not worth interrupting for.

How delivery is measured

Each stage can fail on its own, so we count four. Accept is when APNs or FCM returns a success response, which only means the platform took the payload. Delivered is where a device collected the message, excluding phones that stay offline, uninstalled, or in power saving; Apple and Google publish per-message delivery data, which we import directly. Opened comes from the app on a tap, and the destination screen loading is the stronger signal, because a tap that lands on a missing screen is not a useful open. Converted is what the message was meant to cause: a booking, a payment, a reply.

We also track the permission rate per platform, the disable rate, and the opt-out rate per campaign, with a marketing holdout group as the baseline for retention and revenue.

Where the project starts

A plain idea with nothing built yet. We design the event names, the segment model, and the caps while the app is being built, so the first release carries the pipeline and its analytics.

An existing conventional codebase. We audit what already sends, which after a few years is usually two or three paths: a legacy service, a dashboard configured by hand, and a marketing tool wired to the store. We consolidate those onto one pipeline and add the preference and cap layer.

An AI-built or rapidly assembled prototype. These generate a token and discard it, or keep a send call in the client where any user can trigger messages to others. We keep the idea and the screens, move sending into an authenticated server function, secure the credentials, and verify the APNs key end to end.

How the engagement runs

Discovery covers your event list, what each message should achieve, and anything already sending. We set up the pipeline in a test environment, register real devices, and prove delivery on both platforms before anything reaches a user. Message design, deep link routing, the preferences screen, and the dashboard follow, with documentation of providers and tracked events.

What it costs

Notification work is quoted at our flat rate of $39 per hour, or as a fixed scope once we have seen the app and the events involved. Inside a mobile MVP build the pipeline sits within the mobile MVP typical order of $4,800 to $8,500 across four to six weeks that the pricing page lists. Added to a live app on its own, effort depends on how many systems already send, whether a preference center is in scope, and how much attribution you want, which usually keeps the work inside a few weeks. Teams that need ongoing capacity can use the monthly plans from $2,699.

Proof

Voteme is a cross-platform Xamarin social app with photo voting, credits, chat, and push-style notifications. What it proves here: engagement messages can carry a social product's activity loop when the pipeline lets people reduce what they receive.

Wish Manifestation turned a founder's manifestation methodology into a guided iOS and Android app around the Yamatech tool. What it proves here: in a wellness product a reminder has to sound like the practice it belongs to, and a nudge written like a retail promotion erodes the trust the app was built on.

Walking Cure is a WordPress site for a California clinic explaining a walking-based health method, with a blog and a contact form. What it proves here: health audiences read wording closely, so appointment reminders carry no clinical detail and never appear on a lock screen as marketing.

Related services

Mobile app development for the app itself, from MVP scoping to native delivery
Social and community app development where feeds, chat, and notification frequency are designed together
Mobile backend and cloud infrastructure for the APIs and event storage the pipeline reads from
AI lead qualification and automation when a notification reply should trigger a follow-up

Next step

Bring us the app, the events you care about, and one message you would not want to send. We will say what the pipeline needs.