Can server-to-client messaging rely on APNS?

Question

I'm working on a messaging app and I have a dilemma about how to send data from server to client.

I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients. So clients use a timer and query the server every 2 seconds to see if new data is waiting for them.

The problem with this approach is that polling the server every 2 second seem to kill the battery very fast, so I thought maybe instead of clients polling the server, to use APNS* so when the server has some new information ** for the client, the server will send a push notification *** to the client, then the client will fetch the data from the server.

* use APNS - if client allows it, client can of course disable this option. So I will check if push allowed every time the app enter foreground and if not I'll return to the polling approach.

** New information can be anything from text messages to server admin messages. (and there are a lot of admin messages...)
For example, in my app users can see their friends status (online/offline), so if user1 and user2 are friends, and user2 just change his status from online to offline, then server needs to send this new info (admin message = user2_offline) to user1.

*** The push notifications server sends are empty (with no data/sound), it's just a trigger for the client to fetch the new info, so if a push was sent to the client and the client app was close, he will not notice anything. (if the app is running, then it will fetched the new info from server)

Will this approach work with a massive messaging app requiring massive push notification uses?

To be clearer my main concerns are:
1. Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
2. Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?

Answer 1

Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?

NO. Just for the sake of being complete let me iterate over the reasons.

1. Apple itself disclaims the reliability read the Programming Guide
2. Also, APNS, has a QoS component which may increase the reliability at the cost of being realtime (For Eg. I can ask APNS to deliver the notification anytime within 4 weeks and retry if devices are not reachable) which is not useful in your case.

3. As per your requirement, if you send a silent push (a push with no user visible message), it can not be sent as a HIGH priority push which decreases the reliability even further. Here is a relevant quote

   "Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour."

Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?

Generally, APNS will not have any issues with this in terms of load, but it has throttling in place and they might throttle your notifications, see point 3 above

IMHO, you should look at XMPP as this protocol is designed just use-cases like yours and they have wide community support on all platforms. I will suggest you look at something like https://github.com/robbiehanson/XMPPFramework and setup an XMPP server at your backend which will handle the messaging and presence messages as well as admin messages.

If you have already evaluated XMPP and do not want to go with it, I would suggest you need to put together an intelligent system in iOS App which employs different strategies based on App State, something like following, you can have following strategies

1. A Realtime Socket based approach -> Establish a permanant socket connection and keep the data in sync as much as possible (This is when your app is running into foreground or background)
2. The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
3. Use APNS with user visible messaging + custom data, when your server detects that the device does not have active socket and also have not polled for a very long time