Free push notification writer with iOS and Android length checks

Use the push notification writer

What does this tool actually do?

This writes push notification variants and measures each one separately against iOS and Android, because the two platforms cut text in different places: Android truncates a collapsed body at roughly 65 characters while iOS shows about two lines collapsed and four expanded. It also models the permission cost of your send frequency, since a user who disables notifications has no in-app route back and the system prompt will not appear again, which makes push the only channel where a single message can permanently remove someone from your reach..

It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.

Two permission gates, and no way back through either of them

Push is the only marketing channel with a hard permission gate at the operating system level, and as of recent Android versions there are now two of them. iOS has always required an explicit authorisation prompt before an app can send anything. Android used to grant notification access on install, which is why comparative opt-in figures from before 2022 are meaningless: Android 13 introduced a runtime notification permission, so apps targeting it now face the same prompt-and-refuse dynamic that iOS developers have always managed.

What makes this different from an email unsubscribe is the absence of a recovery path. When a user denies the system prompt, the operating system will not present it again. When a user switches notifications off in Settings, your only remaining option is to deep link them back to the Settings screen from inside the app, which requires them to open the app they have stopped opening. At any meaningful scale, a disabled notification permission is permanent, and it takes with it every future message of every type: the shipping updates, the security alerts, the thing they would genuinely have wanted.

This is why the pre-permission prompt matters more than the copy of any individual notification. Asking for permission during the install flow, before the user has any reason to want your notifications, spends the single request you get on the worst possible moment. Ask it after a first success, attached to a specific value ("we will tell you when your reconciliation finishes"), and use a soft in-app screen first so that a "not now" costs you nothing and leaves the real system prompt unspent.

iOS also offers provisional authorisation, which is genuinely useful and almost nobody uses. It lets an app deliver quietly to the Notification Center without prompting at all, and the user is then offered the choice to keep or turn off notifications after they have seen a few. It trades immediate banner visibility for a much larger addressable base and a decision made on evidence rather than on a dialogue box during onboarding.

Where the text actually gets cut, and why it differs by platform

A push notification is not one format. On iOS a banner shows the app name, an optional subtitle, a title on one line, and roughly two lines of body while collapsed, expanding to around four lines when the user pulls it down or long-presses. On Android, a heads-up notification shows the app name, a single-line title and a single line of body, commonly cutting around 65 characters, and expands only if the developer attached an expanded style. The same message therefore reads as two different messages depending on the handset.

The practical consequence is that the collapsed Android body is the binding constraint on almost every campaign, and it is far tighter than most people writing push copy assume. If the reason to tap is not inside the first 65 characters, a large part of your audience never sees it. iOS is more forgiving collapsed and considerably more forgiving expanded, which is why a message written and previewed on an iPhone routinely ships broken to Android.

Both platforms prepend the app name, which means your title is never the first text on the row, and both are affected by the user's accessibility text size, which can cut these figures substantially. So the numbers this tool checks against are working approximations rather than specifications, and the discipline they enforce, front-loading the specific noun and the reason to act, is what survives whatever the real cut turns out to be on any given device.

One structural point that no character count catches: the tap destination. A notification describing a specific event that opens the app home screen forces the user to go and find the thing you just told them about, on a phone, having already been interrupted once. Deep link to the exact screen, and if you cannot, reconsider whether the notification should exist.

The permission ledger: what your send frequency actually costs

Every notification carries a small probability that the recipient turns notifications off, and because that decision is effectively irreversible, the losses compound rather than reset. Treat it as a ledger. If each message disables notifications for one percent of the people who receive it, then after a hundred messages roughly a third of the original cohort is unreachable, and no campaign can win them back, because winning them back would require a notification.

This tool runs that arithmetic across a plausible range rather than a single figure, because the real per-message disable rate is not published anywhere useful and varies by app category, by how the permission was obtained, and by whether the message was expected. The output shows the reachable share of the cohort after twelve weeks at your stated frequency, and the number of messages it takes to lose half of them, at both a low and a high assumed rate. It is a model. Its value is that it converts "we should not over-notify" into a number that changes when the frequency input changes.

Read it alongside the mix of what you are sending. A message someone is waiting for, a delivery arriving or a colleague replying, sits near the bottom of that range. A broadcast promotion to everybody sits near the top, and it is also the message most likely to be sent weekly because it is the easiest to produce. That combination is how apps quietly lose their notification permission base over a year while every individual campaign reports a respectable click rate.

Android offers the one partial mitigation that exists, and it is heavily underused: notification channels. Splitting your notifications into named categories lets a user disable your promotions while keeping your order updates, instead of making a single all-or-nothing decision about your app. Every category you separate is a chance for the user to turn off part of you rather than all of you.

Timing, and measuring push without flattering the campaign

Send time in push is not a best-practice window, it is a function of the event. A status change should be sent when the status changes, because the entire justification for interrupting someone is that the information is new. A re-engagement message has no natural moment at all, which is precisely why it should be anchored to something observable in the user's own history, usually the hour of day they have previously used the app. And nothing that is not genuinely urgent should be sent overnight in the recipient's local timezone, which requires storing their timezone rather than yours.

The measurement most push dashboards lead with is direct open rate, the share of recipients who tapped the notification itself. It understates the channel, because some people see the message, do not tap, and open the app later, which is an influenced open. It also flatters the channel in a more dangerous way, by reporting only the upside. A campaign with an excellent tap rate that also cost you two percent of your reachable audience was not a good campaign.

So report three numbers per send, not one: taps, the change in your reachable audience, and uninstalls in the following days. The second is the one that is usually missing, and it is the one that determines whether you still have a channel next year. Uninstall is worth tracking separately because it is the most extreme response available to the user and it takes your app with it, not just your notifications.

Finally, be sceptical of comparisons between apps. Push performance is dominated by category and by what the user signed up expecting: a messaging app and a retail app are not competing for the same permission in the same way, and a benchmark that averages them describes neither. Your own history at your own frequency is the only comparison that means anything, which is another argument for keeping a record of the reachable base over time rather than only the campaign reports.

Numbers worth knowing

Mistakes that quietly cost you results

Requesting notification permission during onboarding

You spend the one system prompt you get at the moment the user has the least reason to say yes, and a denial is close to permanent because the operating system will not ask again. Prompt after a first success, tied to a specific thing you will tell them about.

Writing and previewing push copy on an iPhone only

iOS shows about two lines collapsed; Android commonly cuts the body around 65 characters. A message that reads perfectly in your own hand ships truncated mid-sentence to a large share of your audience, and nothing in the campaign report will tell you.

Sending every notification through one undifferentiated stream

Android notification channels let a user switch off your promotions while keeping order updates. Without them, every promotional message is asking the user to make an all-or-nothing decision about your app, and eventually somebody makes it.

Opening the app home screen from a notification about a specific event

You have interrupted someone and then asked them to go and find the thing you interrupted them about, on a phone. Deep link to the exact screen, and if the message cannot be deep linked, question whether it justifies a notification at all.

Judging a campaign on tap rate alone

Tap rate reports only the upside. Record the change in your reachable audience and uninstalls in the days after each send, because a campaign that taps well and costs two percent of your permission base has borrowed from every future campaign to pay for itself.

What does the output look like?

This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.

Frequently asked questions

Related free tools

• Win-Back Email Writer Lifecycle
• Newsletter Subject Line Tester Lifecycle
• SMS Marketing Copywriter Lifecycle
• AI B2B Headline Copywriter for healthcare tech Copywriting
• AI B2B Headline Copywriter for cybersecurity Copywriting

Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.