Case study
Why some of your app's notifications never reach anyone
A morning summary that never arrived, and a customer who heard nothing at all. Two gaps in our own app, both caused by a message with nowhere to land, and what we changed.
Key takeaways
- A message that was sent is not the same as a message that arrived; check where it landed, not only that it left.
- Apple and Google refuse a notification over 4 KB whole, so an oversized message is never quietly trimmed for you.
- Every notification needs a fallback for people who have not installed the app and have never written in.
- A failure that repeats on one day of the week points at whatever is different about that day.
- Count notification size in bytes rather than letters if you write in Arabic or another non-Latin script.
App notifications not arriving is one of the hardest problems to see, because a message that never landed looks exactly like a quiet morning. Nobody complains about a message they never knew was sent. We met two gaps of that kind in our own app on the same day, and both had the same shape: a message with nowhere to land.
A message that vanishes looks like a quiet day
A notification that never arrives leaves no trace in the day it was meant for. For a team, a missing morning summary means starting the day without the overview somebody relied on. For a customer, something worse: a request sits waiting on their answer while they believe nothing is happening, and the business looks slow when it is not. In both cases the system did what it was asked. It sent.
What our engineers found
Our own app sends our team a short summary on their phones every morning, and one morning it did not arrive on any of them. The engineer looked at what was different about that day's summary. It carried an extra weekly section, so it was longer than on the other days. The answer from Apple's notification service for that message said it plainly: the message was too large.
Apple and Google each accept a notification of up to 4 KB, counted in bytes, and refuse anything over that whole. The message is not cut, not shortened, not delivered in part: it is not delivered. On the other days the summary was shorter and fitted, which is why the gap appeared on one day of the week only.
The second gap was quieter. A customer who had never written to us anywhere and had not installed the app could have a request logged for them, a confirmation asked of them, and hear nothing at all. The update appeared in a list on the web portal, which they had no reason to open. Following a request through the rules that decide where a message goes explained it: by default a message goes to the channel the customer last wrote to us on, and email replaces a push only for someone who does not have the app. A customer with no app and no conversation anywhere had no last channel, so there was nowhere to send.
Why this happens to businesses like yours
One reason is that notifications are sent in full, however long they turn out to be, and the phone services do not ask before refusing. A push notification too long for the limit is refused whole, and the only trace may be a line in a service's answer that nobody reads: notification not delivered, no error anyone sees. A second reason is that the rule choosing a customer's channel usually assumes there is a last channel to fall back on, which is true for everyone who has ever written in and false for a new customer. And the push notification size limit is counted in bytes rather than letters, so Arabic and other non-Latin text reaches it sooner than English does, and a message that looks short on screen may not be short at all.
A failure that happens on one day of the week is worth treating as a clue rather than bad luck. Something about that day differs, and here it was the extra section.
What we changed
Every notification is now fitted to the limit before it goes, so the size question is settled before Apple or Google sees it. If a message is too long, the body is shortened at a word and ends with an ellipsis; the title gives way only if the body alone cannot make enough room. The size is counted in bytes the way the two services count it, so Arabic and other non-Latin text is measured correctly and never cut in the middle of a letter. A lock screen shows only a few lines of a notification anyway, and the email and the message inside the app keep every word of it.
For a customer who has no app notifications to receive at all, a message meant for a chat that was never started now goes by email instead. It does so unless they do have that chat, have the app on a phone, have switched email off for that kind of message, or already get that message by email. That closes the case where a customer never got a confirmation email because none was ever addressed to them.
Where it stands now
Both changes are live on our platform, and they went in on the same day the two gaps were found. The longer weekly summary reaches the phones again: shortened on the lock screen, complete in the app and in the email. A customer who has not yet written to us or installed the app now hears by email when a request is logged for them or a confirmation is waiting on them. That is one route that exists where there was none, not a number we can point at.
What you can check yourself
- Send yourself the longest notification your app can produce and see whether it arrives. If a short test message works and a long one does not, size is the thing to look at.
- Ask whoever looks after your app what happens to a notification that goes over the limit: is it shortened, or dropped without anyone being told?
- Work out how a customer who has never installed the app and never written in would hear about an update. If the answer is a list on a portal, there is no route.
- Find out whether a failed message leaves a record anywhere, and whether anybody reads it.
- Note whether a failure repeats on a particular day or after a particular kind of message. The pattern usually names the cause.
What to do next
List every way your app can reach a person, then list what happens when the usual way is missing. That second list is often shorter, and it is where messages quietly go missing. Making sure every message has somewhere to land is the kind of work our engineers do for clients and on our own products.
Questions people ask
Why did my app's notification not arrive even though it was sent?
Sent only means the message left your system. Apple's service for iPhones and Google's for Android can still refuse it, and that refusal often shows up nowhere a business owner looks. The common reasons are a message over the size limit, which is refused whole, and a recipient who has no route set up to receive it.
How long can a push notification be before Apple or Google refuses it?
Both services accept a notification of up to 4 KB, counted in bytes, and refuse anything larger in one piece rather than trimming it. 4 KB is smaller than it sounds once a title, a body and any extra data are counted together. If you write in Arabic or another non-Latin script, remember that the same words take more bytes than in English.
How do I reach a customer who has not installed my app?
Email is the usual route, and it needs to be decided for that person rather than assumed from the last time they were in touch. It also has to respect someone who has switched email off for that kind of message, or who already receives it that way. Otherwise you are sending to a list on a portal that the customer has no reason to open.
Does a failed notification show up as an error anywhere?
Sometimes the notification service's answer states the reason, as it did in our case, but nothing appears on the phone and no one complains about a message they never knew about. That is why it pays to test the longest message your app can produce rather than only short samples. A quiet day and a dropped message look the same from the outside.
Does Arabic text in a notification hit the size limit sooner?
Yes. The limit is counted in bytes, not letters, and non-Latin characters generally take more bytes each than Latin ones. A message that fits comfortably in English can therefore be over the limit in Arabic. Anything that checks the size has to count bytes the same way the phone services do, or it will pass messages that are then refused.