Push Notification Development and Strategy

Treat push as a product feature, not a megaphone

Push notifications are the only part of your app that reaches people when the app is closed, which makes them powerful and easy to abuse. Since Android 13, both major platforms require users to opt in, and either platform lets them switch notifications off in a couple of taps. Tepia designs push around one question: would this person be glad to get this message right now?

In practice notifications fall into three families. Transactional messages confirm or update something the user did: an order is ready, a technician is ten minutes away, a card was declined. Engagement messages bring someone back: a saved item is back in stock, a streak is about to end. Operational messages serve staff apps: a new job assigned, a shift swap approved.

Each family gets its own rules for timing, frequency and wording. Tepia keeps them separate in both code and settings, so a user can mute promotions without missing a delivery update, and your marketing team cannot accidentally send a campaign through the channel reserved for urgent alerts.

How push notifications work under the hood

• Delivery services: iOS notifications travel through Apple Push Notification service and Android notifications through Firebase Cloud Messaging. Tepia often routes both through FCM, or through a provider such as OneSignal or Braze when your marketing team needs a campaign tool.
• Device tokens: each install has a token that can change. The backend stores tokens per user and device, refreshes them on launch and prunes the ones the services report as invalid.
• Permissions: iOS supports provisional authorization, which delivers quietly to Notification Center so people can try notifications before deciding. Android 13 and later require a runtime prompt.
• Android channels: since Android 8, every notification belongs to a channel such as Orders or Promotions that users can control individually.
• Rich content: a notification service extension on iOS adds images and can decrypt sensitive payloads, and action buttons let users confirm or reply without opening the app.
• Live updates: Live Activities on iOS show delivery or ride progress on the Lock Screen, refreshed through push.

Tepia’s backend and cloud development engineers build the sending service with queues and retries, so a spike of order updates on a busy evening does not drop messages.

Notification types Tepia plans for

Writing this table early forces the decisions that are hard to retrofit: which messages a user can mute, which ones break through Focus as time sensitive, and how many promotional sends a person can receive in a week. Tepia turns it into backend configuration rather than hard coded logic, so your team can tune caps without shipping a new release.

How Tepia approaches push notification development

1. Discovery: interviews about which events users care about, a review of your CRM or marketing tools, and a system investigation of where events originate. Deliverables are the Investigation Summary, Interview Summary and User Stories such as a customer choosing to hear about deliveries but not promotions.
2. Design: the permission explainer screen, notification preferences, copy guidelines and wireframes for every screen a notification opens.
3. Development and Testing: token management, the sending service, deep links and analytics, with test plans covering closed app states, logged out users, time zones and devices in Focus or Do Not Disturb.
4. Training: sessions for marketing and operations staff on sending campaigns, reading results and respecting caps.
5. Launch: migration of existing tokens and preferences from an old provider where needed, and a careful first campaign.
6. Support: monitoring delivery failures, OS changes to permission rules and new message types as requests come in.

Push is often part of a larger app build that follows Tepia’s typical timeline of 1 to 3 months for Discovery, 2 to 6 months for development and QA, and about a month for launch. Adding a full notification system to an existing app is a smaller project. See our process.

Measuring whether notifications help or hurt

Open rate alone flatters push. Tepia instruments the full path so you can see what a message actually changed:

• Opt in rate by prompt placement, so you know whether the explainer screen works.
• Downstream actions such as reorders, bookings or completed jobs within a set window after the message.
• Holdout groups that do not receive a campaign, which show whether people would have come back anyway.
• Negative signals including opt outs, channel mutes and uninstalls after a send.

Those numbers feed back into caps and timing. During the first months of Support, Tepia reviews results with your team after each campaign, and a message type that drives opt outs without lifting any downstream action gets rewritten or retired. Tepia treats notifications as one part of a wider retention plan, described on our app retention engineering page, and the event tracking itself is covered under app analytics implementation. To plan notifications for your app, talk to Tepia or review our work.

Frequently asked questions