I have a design question. Let us say you were tasked with building a chat application, specifically for iOS (iOS Chat Application). For simplicity let us say you can only chat with one person at a time (no group chat functionality).

How then can you achieve sending a message directly to an end user from phone A to phone B?

Obviously there is a web service layer with some API calls. One of the API calls available will be startChat(). After starting a chat, when you send a message, you make another async call, let us call it sendMessage() and pass in a string with your message. Once it goes to the web service layer, the message gets stored in a database.

Here is where I am currently stuck. After the message gets sent to the web service layer, how do we then achieve sending/relaying the message over to the end user? Should the web server send out a message to the end user and notify them, or should each client call a receiveMessage() method periodically, and if the server side has some info for them it can then respond with that info?

Finally, how can we handle the case in which the user you are trying to send a message to is offline? How can we make sure the end user gets the packet when he moves back to an area with signal?

4 Answers 4


Other users have suggested APNS but you should be aware that if you late r decide to port your application to Android and/or Windows Phone, this will be harder to achieve if you are tied to a platform-specific push API. There are several alternatives that are suitable for use on all 3 platforms listed in this stack overflow question: https://stackoverflow.com/questions/9801720/push-notifications-on-all-3-platforms-android-ios-windows-phone


I´m assuming there is some sort of client ID involved in this solution. Then it´s simple, Client A sends a messages to the server with Client B´s ID, the server stores the Messages (perhaps a flag indicating that it hasn´t been read). Whenever Client B connects it asks the server if there is any unread messages, and if so, polls them.

In the case that Client B is connected whilst Client A sends a message then the server should directly distribute the message to Client B.

Best of luck


I've done something similar. iOS --(Sends request with message and id of recipient)--> Server --- Sends message over to recipient --> iOS

However I used notifications to do the final delivery. This means the server has the tokens for the devices stored, once it determines who is who it sends a request to APNS.

  • yeah i looked into APNS and its great. Basicly does queuing and sending of packets for you. Kinda like a TCP/IP for message delivery
    – AyBayBay
    Feb 6, 2014 at 22:09
  • Im sure its just built on top of the UDP protocol, and is a fancier version of it
    – AyBayBay
    Feb 6, 2014 at 22:10
  • As far as i can tell, it's basically a Queue Manager similar to IBM MQ
    – Lemonade
    Nov 2, 2014 at 7:47

APNS is the most obvious way to do this. It does mean you will need a central server, and it also means there will be some maintenance, as you are expected to clean up expired tokens. There's also registration with Apple when it comes to doing your certificates, but nothing too stressful. One thing to take note of is the relatively low character limit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.