Your choices are fairly binary:

1. Use push notification
2. Use Polling

With Push Notification:

• You control when you contact your users... Heavy Load means you can slow updates down to avoid taxing your infrastructure
• Contrariwise, you have to push to clients that may not even be there anymore (And thus may need some sort of register model), high load may mean that clients don t get immediate update
• You can leverage things like Amazon s EC2 to give you more processing power
• Unless you re out of capacity, users are almost certain to be receiving updates as they happen
• To pick up messages missed while offline, the SERVER needs to know what message was last successfully received, store older messages and forward many all at once

If you choose to use polling:

• You must have a stable address to be polled
• You need the ability to have lots of quick query connections checking for new data, then returning that data if required.
• If your application becomes popular enough you may find you don t have enough resources
• If your resources are taxed your application will go down, rather then just slow down
• You don t need to register clients and keep track of their on/offline state
• Parallelizing on the fly is a bit trickier
• To pick up older messages, the CLIENT needs to know when they last received a message and then request the server send any message since that time

Both can be fast, but they come with different bandwidth and processing profiles. I prefer push for everything that s real-time.

You only need push notification if you want the app to be able to receive new messages while closed.

Here s a rough description of one way to do this: Your app sends a message via HTTP Post to your server. Your server stores the message in a database, using the iPhones unique ID as an identifier. Your app connects to the server frequently, asking for new messages. If there are any new ones, the server hands the message to the app, which displays it.

This is approximately what twitter/iphone twitter apps do.

Might want to take a look at XMPP.

Twitter doesn t really push events out to the iPhone in realtime. It s more like polling by the various clients.

If you really want instantaneous for the last mile you ll want to use push.

Twitter uses lots of servers and raid arrays to handle the load of millions of people posting 140 character messages. Twitter clients log in and request a list of updates for all of the people the user is following within a certain time frame.

Push wouldn t be a good candidate for this because it does not persist the "tweets". It is simply a notification mechanism. There is a text messaging app on the App Store (called Ping!) that relies completely on push notification for sending text messages. This seems to work fine, but if the developers are keeping track of the messages, it is all done on their servers. In their case push makes sense as you want to alert the user of a new message. In the case of a twitter clone, however, it would probably just annoy users if they got a new notification every time someone tweeted.

In the end you re better off just implementing it server side and then developing an iPhone client that logs in and retrieves the latest tweets for the people the user is following.