Push Notifications overview
Our Push Notifications system is currently in beta. This means you may experience errors, and the APIs may change. We would love to hear your feedback, so please get in touch!
Pusher’s Mobile Push Notifications API lets you send push notifications to native iOS and Android apps even when they are not open on the device. You can combine push notifications with our WebSocket system to deliver data to users whether they are connected or not. You can send a push notification with a single HTTP request, or with a single call in one of our official libraries.
Just like the Pusher WebSocket API, the Push Notifications API uses a Publish/Subscribe model based on subscriptions to interests. These subscriptions allow you to filter and control how people receive your messages. You subscribe your iOS and Android apps to interests, and your servers can then publish notifications to those interests, which get delivered to all subscribed apps.
The Push Notifications API supports all of the features of the latest iOS and Android platforms. This includes iOS 10 support and the ability to send push notifications via Firebase Cloud Messaging (FCM).
Push notifications are messages sent to iOS and Android apps over Apple Push Notification Service (APNs) and Google Cloud Messaging (GCM). Push notifications can be displayed by the device on the lock screen, and the user can launch the app directly from the displayed notification. Push notifications can be used to alert users about valuable information, such as a driver arriving to pick up a passenger or a friend sending a message. Pusher’s Mobile Push Notifications API makes it easy to send push notifications to both iOS and Android devices with just one request.
Push notifications are different from WebSocket messages. Pusher’s WebSocket and Push Notifications APIs are complementary. This table summarizes the trade-offs between the technologies:
|Deliverable to closed application||No||Yes|
Pusher’s WebSocket and Push Notifications APIs are separate, but designed to be used together. A sensible approach is to use WebSockets for a realtime experience while a native application is open, and then to fall back to push notifications when the application is closed. For example, a chat app might use Pusher’s WebSocket API while the app is open, using the WebSocket connection to deliver user messages, read receipts, presence updates, and “typing” indicators. While the app is closed on the device, the chat server could use our Push Notifications API to send chat messages as push notifications.
Our Push Notifications API is a Publish/Subscribe system: native clients “subscribe” to interests, and servers publish to them. Consider the following diagram, where a chat application is using Pusher to deliver chat messages.
+----------+ | | | Chat app | | server | | | +----+-----+ | | "hello" | | +--PUSHER-------------------------------------------|---------------+ | | | | +-INTEREST-+ +-INTEREST-+ +-INTEREST--v-----------+ | | | | | | | | | | | donuts | | jim_1987 | | convo_jim_1987_ben123 | | | | | | | | | | | +-----+----+ +----+-----+ +------+----------+-----+ | | | | | | | +---------|----------------|-------------------|----------|---------+ | | | | | | | | | +-----+ +--"hello"--+ "hello" | | | | | | | | +---------v---------+ +--------v-v--------+ +---------v---------+ | Chat app on Eve's | | Chat app on Jim's | | Chat app on Ben's | | iOS phone | | Android phone | | iOS phone | +-------------------+ +-------------------+ +-------------------+
In this diagram, users Jim and Ben are in a conversation. This conversation is represented on Pusher with the interest named
convo_jim_1987_ben123. Both Jim and Ben’s phones are subscribed to this interest, meaning they will receive all notifications pushed to it. When the chat app server pushes the message
"hello" to the interest
convo_jim_1987_ben123, Jim and Ben’s phones both receive the push notification
This sounds just like our WebSocket system, so what’s the difference? The most important difference is that, using push notifications, the applications do not have to be “open” on their phones at the time. In this example, this means that Jim can send a message to Ben even when Ben’s phone is locked and his chat app is closed. Ben’s phone will wake up and he will be immediately notified of receiving a new message.
Whereas our WebSocket system delivers messages over WebSockets, our Push Notifications system delivers messages via the devices’ native notification platforms. For iOS devices, messages are delivered via Apple’s APNs system, and for Android devices, messages are delivered via Google’s GCM or FCM system. In the above example, the message
"hello" was delivered to Jim’s Android phone via GCM, and to Ben’s iOS phone via APNs.
“Interests” in our Push Notifications system are the equivalent of “channels” in our WebSocket system. However, they are not the same things: subscribing to the WebSocket channel called
donuts is different to subscribing to the Push Notifications interest called
donuts. This allows the app to segment its subscriptions more accurately. In order to receive both, the app can subscribe to the
donuts WebSocket channel as well as the
donuts Push Notifications interest.
Our Push Notifications API supports iOS and Android. The platforms differ a little in the details, but the general steps are:
- Get an account with the notification platform (GCM/FCM for Android, and APNs for iOS).
- Add a few lines of code to your native application.
- Use our server libraries or our HTTP API to send a push notification to your native application.
You can use both platforms together: the same interest can be subscribed to by iOS and Android devices. When sending a push notification, you specify how it should be displayed on iOS and on Android, allowing you to tune the user’s experience to their specific platform.
Our Push Notifications system is free to use, and does not impose a limit on the number of push notifications you can send.
For more technical details of our Push Notifications system, we have a complete reference guide. This details the Push Notifications system architecture - how our system interacts with your servers, your native applications, and with APNs and GCM/FCM. The guide also details both of our HTTP APIs: the server API for sending push notifications, and the client API for subscribing to interests. You probably don’t need this level of detail if you’re just getting started - instead, try our iOS guide or our Android guide.