What are push notifications?

Push notifications are the small messages that appear on your phone screen — even when the app isn't open — alerting you to something that needs your attention. A new message. A booking reminder. A delivery update. An invoice that's been paid.

On iOS, they appear as banners at the top of the screen with a sound. On Android, they stack in the notification shade. Both platforms require the user to grant permission before your app can send them.

They're one of the highest-ROI features in mobile apps — re-engaging users who've left the app, delivering time-sensitive information, and prompting action. For apps that compete for attention, push notifications are often the difference between daily active use and "that app I downloaded once."

When does your app need them?

• You need to alert users to events that happen while they're not in the app (new message, booking confirmed, order shipped)
• You send time-sensitive reminders (appointment in 1 hour, quote expiring today)
• You want to re-engage inactive users ("You have 3 unread messages")
• Your app is in the field services, logistics, healthcare, or retail space where real-time updates matter
• You want to reduce email open rate dependency — push notifications typically have 3–5× higher open rates than email

How much does it cost?

Adding push notifications typically adds 5–11 hours of development — roughly $1,000–$2,000 AUD.

This covers setting up the notification infrastructure, integrating the platform-specific services, and building the logic that decides what gets sent and when.

Cost increases when:

• Notifications are personalised based on user behaviour or segment
• You need a notification preference centre (users choose what they receive)
• Notifications are scheduled rather than triggered by real-time events
• You're sending rich notifications with images, action buttons, or deep links
• You need delivery and open rate analytics

How it's typically built

Push notifications on mobile require two platform-specific services:

• APNs (Apple Push Notification service) — for iOS devices. Requires an Apple Developer account and a certificate setup.
• FCM (Firebase Cloud Messaging) — for Android devices. Free, handled via Google.

Most apps use a notification service that wraps both — OneSignal, Firebase Cloud Messaging directly, or Expo's notification service for React Native apps. This simplifies sending to both platforms via a single API call.

The typical flow: something happens in your app (booking confirmed, new message) → your backend calls the notification service API → the service routes to APNs or FCM → the notification appears on the device.

For React Native apps built with Expo, expo-notifications handles most of the complexity. For native apps, the platform SDKs are used directly.

Questions to ask your developer

• How do you handle notification permissions? iOS requires an explicit permission prompt — if declined, you can't send push notifications to that device. The timing and wording of this prompt matters a lot for opt-in rates.
• How do notifications link back into the app? A notification about a new message should open that specific conversation, not just the app's home screen. This "deep linking" needs to be built explicitly.
• Are notification preferences managed by the user? For apps with multiple notification types, letting users choose what they receive reduces unsubscribes and improves engagement.
• What's the deliverability rate? Providers differ. Some are better at ensuring delivery, especially to Android devices with aggressive battery management.
• How do you handle notification fatigue? Sending too many notifications trains users to ignore them or uninstall the app. Define the right triggers and frequency before building.

---

See also: In-app messaging / chat · Transactional email · SMS notifications · App cost calculator