Push notifications for mobile apps: user retention without spam - Zephyra Studio

What push notifications are and who they are for

Push notifications are short messages delivered by the operating system (iOS via APNs, Android via FCM) to a device, triggered by your app or by a server. Unlike email or SMS, they do not depend on the user opening anything: they land on the lock screen, in the notification tray, or as a badge on the app icon. Technically, the app registers a device token, that token is stored on your backend, and your backend decides who gets which message and when.

They make sense for any mobile app with a reason to bring users back: booking and reservation apps (appointment reminders), e-commerce (order status, back-in-stock, cart recovery), content and media apps (new episode, new article in a followed topic), and service apps (maintenance due, document expiring). If your app is opened once and then forgotten, push notifications are the feature that decides whether the second session ever happens. They are not a replacement for in-app messaging or email: they are the layer that gets the user to open the app in the first place.

Advantages of push notifications compared to alternatives

Compared to email, push is seen faster and read far more often, but it is also more fragile: the user can turn it off in two taps and often does. Compared to in-app messages or banners, push reaches the user when the app is closed, which is most of the time, but it cannot carry much content and cannot be ignored quietly. Compared to SMS, it is free per message and does not need a phone number, but it requires an installed app and a granted permission. The real trade-off is not reach, it is permission: every unwanted push costs you a slice of your audience permanently. That is why the engineering here is less about sending and more about deciding what not to send.

The alternative most teams fall into by default is the broadcast: same message to every device, sent on a schedule. It is easy to set up and it is exactly what produces the uninstall spike. A segmented approach, by contrast, sends a booking reminder only to users with a booking tomorrow, and a discount only to people who added an item to the cart and did not check out. Same tool, different outcome. Localisation matters here too: the same campaign sent in the wrong language or at 3 a.m. local time reads as noise, and noise is what gets apps deleted.

How we work with push notifications

We start with the permission moment, not the campaign: an in-app prompt shown after the user has done something meaningful, so the OS-level permission dialog is asked once and asked well. Then we wire the delivery layer: APNs and FCM through a provider that handles scheduling, retries and delivery reporting, with device tokens tied to your user records so segments are real people, not anonymous installs. From there we define a small set of notification types with owners: transactional (booking confirmed, order shipped) sent immediately and always; behavioural (cart abandoned, unused feature) sent on rules; promotional sent on a frequency cap, typically no more than one or two per week per user. We build the opt-out and topic preferences screen so users can mute one category without killing all of them, and we instrument opens, dismissals and uninstalls so the next review is based on numbers. Our team is remote and small, two rounds of design revision are included, and smaller projects typically go live in 2-3 weeks.

Indicative price

Price depends on scope: how many notification types, how the segments are defined, whether your backend already has user events to trigger them, and whether we also build the in-app preferences screen. For that reason we do not publish a fixed figure. We scope it in a short conversation and through the calculator, then you get a written estimate before anything starts. Payment is 50% in advance and 50% on delivery, with no instalments.