Short answer. An app does not “send SMS” any more than it “sends push”: it emits events, order shipped, payment received, courier on the way, and a notification service decides for each one, according to the customer and their preferences, which channel, at what time, in which language, and whether to send at all. Google and Apple push comes first because it costs nothing per message and arrives in seconds; the in-app inbox always gets a copy, it is the only one that loses nothing; WhatsApp takes over when the push is not acknowledged within the written delay; SMS stays for the critical message to a phone with neither the app nor WhatsApp. Every send is logged with its channel, cost, receipt and failure reason, because a push fails silently in six different ways: permission denied, token expired, manufacturer killing the app, phone without Google services. Eight weeks, the first with no send at all.
This guide is for the founder settled in France whose app must notify customers in Algeria, the manager of a delivery platform, a clinic or a school who pays for SMS for everything, and anyone comparing quotes where “notifications” is one word. It does not cover the login code by SMS or WhatsApp, described in the OTP guide, nor the agent that answers customers on WhatsApp, described in the dedicated guide; it describes what gets built between the event and the customer’s phone.
What the figures say
Push is no longer granted by default. Since Android 13, released in 2022, a newly installed app’s notifications are off until the user grants a permission, requested by the app at the moment it chooses; the Android documentation recommends waiting for a gesture that gives the request meaning, “the user submits an order for food delivery” is its example, rather than showing it on the first screen. On iOS, the permission has always been requested. What this imposes: an app that asks for the permission on launch, before showing what it is for, loses part of its customers for good, and an app that does not read the permission state before sending believes it has notified.
Push arrives when the phone is willing. The documentation of Firebase Cloud Messaging, Google’s push service used by most Android apps, distinguishes two priorities: at normal priority, “delivery may be delayed to conserve battery until the device exits doze”; at high priority, delivery is attempted immediately and can wake the device, but if high-priority messages do not display a visible notification, “your messages may be deprioritized to normal priority”, a decision taken per app on seven days of behaviour. The Don’t Kill My App site, maintained by developers, ranks manufacturers by how aggressively their battery saving treats background apps: Huawei, Xiaomi, OnePlus and Samsung at the top level, Oppo just behind, realme and Tecno in the middle; it is a developers’ ranking, not a measurement, but it matches what we see in pilots.
Your customers’ phones are not your team’s. According to StatCounter for October 2026, the six leading brands in Algeria are Samsung (24 %), Apple (16 %), Xiaomi (15 %), Oppo (13 %), realme (8 %) and Infinix (8 %); it is a web-traffic measure, not a census, and it serves one purpose: an acceptance test on three team phones says nothing about what customers receive. Phones sold without Google services exist, and on those the Google push will never leave. On cost, Algerian operators’ price lists for business SMS are not public; the reseller sheets we read put SMS at twenty to thirty times the price of a WhatsApp utility message, and Meta bills WhatsApp per delivered message since July 2025, with per-region rates not repeated here because they change. What does not change: push costs nothing per message, and that is the reason for everything else.
The life of a notification, in six moments
A notification is not described by its channel but by what happens to an event, from the shipped order to the log line that will say which way it went.
The event is emitted by the app with its customer and context: order shipped, payment received, appointment tomorrow, courier on the way; the app never says “send an SMS”, it says what happened. The rule decides, for this event and this customer: which channel, at what time, in which language, with what priority, and whether to send at all; this is where the customer’s preferences, quiet hours, daily cap and deduplication live. The rendering takes a versioned template per channel and language, right-to-left Arabic included; the same event gives a two-line push, a WhatsApp message approved by Meta, an SMS that fits in 160 characters.
Send and fallback: the in-app inbox always gets a copy, before any send; the push leaves first; if nothing is acknowledged within the delay written for this message type, WhatsApp; if WhatsApp fails and the message is critical, SMS; otherwise nothing more. The receipt says delivered, opened, clicked, or failed with the reason: expired token, denied permission, invalid number, rejected template; it decides the fallback and the bill. The log writes every send with its channel, cost, receipt and delay; it is what lets you answer “the notification left at 14:02 by push, not acknowledged, resent at 14:12 on WhatsApp, read at 14:13” to the customer who says they got nothing, and feeds the owner’s screen described in the dashboard guide.
An app’s notifications, in five layers
Behind the six moments, five layers, and the middle one is the only one that belongs to us.
The application shows the in-app inbox, asks for the permission at the right moment with the explanation, and lets the customer set preferences per message type; it is what the customer sees. The notification service is the real deliverable: rules per event, preferences, quiet hours, caps, deduplication, receipt delays, fallback from one channel to the next, templates; it is the only layer that knows what must leave, and it is yours, in your repository. The channels are interchangeable behind it: Google and Apple push, manufacturer push when the phone lacks Google services, WhatsApp Business, SMS through an aggregator, email, voice call; each has its cost, delay and form of receipt, and switching SMS aggregator is a setting.
The data holds device tokens per customer, preferences, the log of sends and receipts, versioned templates; an expired token or a denied permission shows here before the customer calls. Operations reads every week the delivery rate per channel and per manufacturer, the cost per send, the share that went to fallback, complaints and opt-outs, with an alert when one drifts. An app that calls an SMS aggregator’s API from every screen has none of these layers: no rule, no preference, no fallback, no log, and an SMS bill as its only indicator.
«The app never says “send an SMS”; it says what happened, and the service decides the channel, the time and the language.»
A worked example
An example on volume assumptions, with mechanics that are not assumptions: a delivery platform, 3,000 orders a day, one month.
12,000 notifications a day: four events per order, confirmed, prepared, courier on the way, delivered; that is our volume assumption, measured in the pilot. 0 DA per push at Google and Apple: no per-message cost; the cost is in the service built once and the receipt read. A ratio of twenty between an SMS and a WhatsApp utility message according to reseller sheets, to be checked on your quotes since Algerian operator tariffs are not public; what does not depend on the price list is that a platform sending its 12,000 events by SMS pays every day for what a push would have done for free for the large majority of customers, while a platform that sends by SMS only the delivery code of customers without the app or WhatsApp sends a few hundred.
One hundred per cent of sends logged with channel, cost, receipt and delay, and zero message sent without a rule, a checked preference and a write to the in-app inbox: that is mechanics, not an assumption. The assumptions to check at home: how many events truly deserve a message, what share of your customers has the app installed with permission granted, what share has WhatsApp, and what receipt delay your manager accepts before resending; the project’s first week answers them, and the delivery platform guide says what the couriers themselves must receive.
Six channels, and which message each is made for
Six channels, and none is “the right one”: each is made for a type of message, and each fails in its own way.
Push carries everything useful right now and free: order status, message received, reminder; at high priority only when the customer must act, because high priority without a visible notification ends up deprioritised. It fails by denied permission, expired token, manufacturer killing the app, phone without Google services. The in-app inbox receives everything, always: it is the copy the customer finds on opening the app even if no channel got through; it fails only when it is an afterthought, added after the channels. WhatsApp Business carries the message that must be read and may call for a reply, courier on the way, appointment, invoice, as push fallback; it fails by unapproved template or unregistered number, and costs per message outside the 24-hour window described in the WhatsApp agent guide.
SMS stays for the critical message to a phone with neither the app nor WhatsApp: delivery code, appointment reminder; it costs on every send, fits 160 characters, half that in Arabic, and has no read receipt. Email carries the document, invoice, receipt, weekly summary, never the urgent; part of the customers in Algeria have no checked address. The voice call is the written last resort, order to confirm before cut-off, blocked delivery, triggered by a rule and never by hand. The general rule: push and in-app inbox for everything, WhatsApp for what must be read, SMS for what is critical and cannot pass otherwise, and every step from one channel to the next written in advance, per message type, with its delay.
Six reasons the notification does not arrive
Six failures we see on the apps we take over, and what the architecture does against each.
Permission denied: on Android 13 and later, notifications are off by default, the request shown on the first screen is denied and does not come back; request made at the useful moment, after an order, with the explanation, permission state read before every send, WhatsApp fallback if denied. Manufacturer killing the app: on some phones, battery saving closes the app and delays or blocks the push; high priority reserved for messages that call for an action, visible notification on every push to avoid deprioritisation, help screen per manufacturer, fallback if nothing is acknowledged. Phone without Google services: the token does not exist and the Google push will never leave; detection at install, manufacturer push when it exists, otherwise WhatsApp and in-app inbox from the start.
Expired token: the customer reinstalls, changes phone or stops opening the app, and the token dies silently; token refreshed at every open, error response read and token deleted, fallback to the next channel, log. Normal priority in sleep: the push leaves at normal priority, the sleeping phone keeps it for later, and the courier has already been; high priority for the message that awaits an action, normal for the rest, written receipt delay then WhatsApp. Too many messages: four promotions a day, and the customer turns everything off, including their order status; cap per customer per day, quiet hours, deduplication, preferences per type, opt-outs counted and read every week. The first three are found in the pilot if you test on real customers’ phones; the last three, three months later, in the opt-outs.
«The team’s phones always receive everything; acceptance is done on twenty customers’ phones.»
Seen elsewhere: Android 13, Firebase, Don’t Kill My App, and what transposes
Three sources say the essentials. The Android documentation says the notification permission is denied by default since Android 13 and must be requested when it makes sense; what transposes is that the request is a product screen, designed in week two, not a dialog at launch. The Firebase documentation says normal priority waits for the device to leave sleep, high priority can wake it, and high priority without a visible notification is deprioritised after seven days; what transposes is a priority per message type, written in the rule, and a receipt read to know whether the push got through.
Don’t Kill My App says the manufacturers most sold in Algeria are among those that most readily close background apps; what transposes is an acceptance test on customers’ phones of varied brands and a fallback that does not depend on push. What these sources do not say: which events in your business deserve a message, what share of your customers has WhatsApp, and what delay your manager accepts before resending; the project’s first week answers that.
The rules of a notification that arrives
Six rules, written in the first week and reread at every new message type. An event, not a message: the app says what happened, the service decides. The in-app inbox first: every notification is written there before any send; it is the only guaranteed copy. Free push first, paid channels as fallback: WhatsApp if the push is not acknowledged within the written delay, SMS for the critical only. Permission requested at the useful moment, with the explanation, and read before every send. A cap, quiet hours and preferences per type, because a customer who turns everything off no longer gets their order status. A full log, channel, cost, receipt, delay, failure reason, read every week per manufacturer.
A seventh rule concerns the quote: “push and SMS notifications” is not a requirement, it is a sentence; the requirement reads “notification service with rules per event, preferences per type, in-app inbox, push with receipt, WhatsApp fallback after X minutes for types A and B, SMS for type C only, log per send, delivery rate per manufacturer measured on twenty customers’ phones at acceptance, cost per send displayed”, and it is checked as the specification guide recommends. A quote that prices “the SMS” has priced a monthly bill, not a service.
Six apps, and the message built first
Six apps we often build, and for each the first message type chosen in the first week, with its channel and fallback.
- The delivery platform, described in the dedicated guide. “Courier on the way” as high-priority push, WhatsApp after ten minutes without receipt, delivery code by SMS for the customer without the app.
- The dental or medical practice, described in the practice guide. Appointment reminder the day before by push, WhatsApp the same morning if not acknowledged; never medical content in the channel, only the invitation to open the app.
- The private school. Day’s absence by push to parents, report card and invoice in the in-app inbox and by email; strict quiet hours, daily cap.
- The pre-sellers’ field app, described in the dedicated guide. Order validated or refused by push, synchronised with the offline queue described in the offline guide; no SMS.
- The event hall booked from France, described in the dedicated guide. Deposit received and date confirmed by push and email to the customer in France, WhatsApp to the manager in Algeria.
- The owner’s space for a rented flat, described in the dedicated guide. Rent received and receipt by push and email to the owner in France, due-date reminder by WhatsApp to the tenant in Algeria.
The 2027 calendar
The calendar is that of a complete notification service in eight weeks, the first with no send at all and one of acceptance on real phones.
Week 0 to 1 takes the message inventory: every event that deserves a message, for whom, in which language, with what urgency, and what will never be sent; signed. Week 1 to 2 designs preferences and permission: the preferences screen per type, the moment of the request, quiet hours, caps, and the in-app inbox. Weeks 2 to 4 build the service, push and in-app inbox: rules, templates, tokens, receipts, log, Google and Apple push, every send written to the inbox before leaving. Week 4 to 5 adds WhatsApp and SMS as fallback: templates approved by Meta, receipt delay per type, written fallback, cost per send read.
Week 5 to 6 is acceptance on twenty customers’ phones, of varied brands, with denied permission, airplane mode, reinstall, and a delivery rate per manufacturer; the team’s phones do not count, they always receive everything. Week 6 to 7 is the pilot on part of the customers, delivery and receipts read every day, complaints and opt-outs counted. Week 7 to 8 installs weekly supervision, rate per channel and manufacturer, cost, share in fallback, and adjusts the rules. Every two-week batch is demoed and accepted as the delivery guide describes, and the running cost joins the yearly budget described in the guide on keeping an app alive.
What makes notifications fail
The notification services we take over almost always failed for one of these reasons.
- SMS for everything. The bill is the only indicator, and nobody knows who read what.
- Permission requested at launch. Denied before the app has shown what it is for; it does not come back.
- No in-app inbox. The channel fails, and there is no copy the customer can find.
- Acceptance on the team’s phones. Three phones that receive everything; customers on other brands, nothing.
- No receipt read. The service believes it has notified; the token had been dead for two months.
- High priority everywhere. Deprioritised after seven days without a visible notification, and the urgent message waits for the device to wake.
- No cap. Promotions turn off service notifications; the customer no longer gets their order status.
Frequently asked questions
The questions we receive from founders settled in France, managers in Algeria and teams comparing quotes.
- Why do my customers not receive the notifications?
- For one of six reasons, and the log must say which: permission denied, frequent since Android 13 where it is denied by default; token expired after a reinstall; manufacturer closing the app in the background; phone without Google services; push at normal priority held during sleep; or a customer who turned everything off after too many messages. A service that reads the receipt and falls back to WhatsApp handles the first five; a cap and preferences handle the sixth.
- Push, SMS or WhatsApp: which to choose?
- All three, each for its message: push, free and immediate, for everything useful right now; WhatsApp, billed per message, for what must be read and may call for a reply, as push fallback; SMS, the most expensive and without read receipt, for the critical message to a phone with neither the app nor WhatsApp. The in-app inbox receives everything, always, and the step from one channel to the next is written in advance per message type.
- How much does a notification cost?
- Nothing per message for push at Google and Apple; per delivered message on WhatsApp, at per-region rates published by Meta; per send for SMS, at operator tariffs that are not public in Algeria, reseller sheets putting SMS at twenty to thirty times the WhatsApp message. What weighs is not the unit price but the share of messages that go out paid; a service that falls back only on what is not acknowledged keeps it low, and the cost per send is read every week.
- What if the customer has a phone without Google services?
- The Google push will never leave, and the service must know it at install: phone detection, manufacturer push when it exists, otherwise WhatsApp and in-app inbox from the start for that customer. Phones of this kind exist in Algeria; the acceptance test on twenty customers’ phones includes at least one.
- When to ask for the notification permission?
- At the moment it makes sense to the customer, and with the explanation: after their first order, when enabling tracking of a file, when tapping a bell; that is the Android documentation’s recommendation, and what we design in week two. Never on the first screen: on Android 13 and later, a denial at that point is a denial for a long time, and the service must read the permission state before every send.
- How long to build the notifications?
- Eight weeks for a complete service: one of message inventory with no send, one for preferences and permission, two for the service, push and in-app inbox, one for WhatsApp and SMS as fallback, one of acceptance on twenty customers’ phones, one of pilot, one of supervision. Every two-week batch is demoed and accepted.