Ever since the “push” became the buzz word for iPhone 3.0 OS, I was curious to find out how the push notifications worked with iPhone. My initial thought was that, iPhone needed a dedicated push server visible within the operator network, just like Blackberry, but then how did iTouch used the same apps and still used the push notifications for the Wi-Fi. I began investigating and found a cool technique that Apple implemented for it’s push notifications, but I also found out a few things that I really didn’t like.
Why Push?
There is an inherent problem with the iPhone OS and the problem is that there is no “backgrounding” on iPhone, which means unlike other smart phones, the apps don’t run in background on iPhone when you exit them. This effected applications for iPhone which needed constant polling with a publication server. E.g. a RSS reader application won’t be able to poll the feeds for the new updates from the phone. To read the feeds, the user will have to open the application and manually fetch the feeds. To address the issue Apple came up with a smarter approach. They implemented push mechanism for iPhone.
Poll vs Push
An application constantly running in the background of your phone and polling for feeds or updates causes battery consumption. So if you have multiple applications doing the polling from your mobile device, your battery might get drained pretty quickly than you expect. Push however doesn’t implement the poll mechanism and you get updates as it happens.
So how does the “push” work in iPhone?
Okay, consider this, you have an application on iPhone which enables to have the push mail experience for your Gmail or AOL or any of your home grown IMAP email server. Here is a representation of how “push” mechanism would work with iPhone.
Apple implements an intermediate server (under their own control and not under operators control or visibility) called as the Push Notification Server (PNS). The device (iPhone) maintains a constant TCP/IP connection with this server. The application developers server (or the 3rd Party Server) maintains a session with the mail server. When a new mail arrives an alert will be sent from the application developer’s server to the PNS which then pushes it to the iPhone 3.0 through the open TCP/IP socket connection. So if you had a RSS reader application, to have notifications sent to you automatically as update on a feed is available, the application developer will need to constantly monitor the feeds and notify the PNS as anything happens.
Essentially what Apple has done is moved the polling or processing need from iPhone to an intermediate level called the “App Developers Server”.
Sure this approach works for the battery benefits where background applications can claim as much as 80% of battery drain as compared to 20% on Push notifications using Apple’s technique. However the way I see it, there are some issues.
So what are the issues?
The first issue that I see from an application developer stand point is that, if I had to write a RSS reader type of application then I would have to deploy my own backend server which would monitor the feeds for the end users and notify PNS to have notifications on updates. Basically not all applications really need a backend service, but with this technique that additional layer has to be implemented. So if the number of users for my applications grow, I’ll need to setup a server farm and to recover the cost I’ll need to increase the cost of my application or charge the user a service fee which is not good either for me nor for the user.
The second and most concerning issue that bothers me is, privacy issue. Well if a third party application developer needed to constantly monitor your inbox or IM or even the RSS feeds, then it would need your credentials to establish and maintain a session with the actual mail server/chat server or should know exact feed URLs so that it can monitor them incase of RSS. How many people would really feel comfortable to know that their email usernames and passwords are being stored on a 3rd party server probably unencrypted and probably anyone managing the server would have visibility to it? To me this is the biggest issue with this approach.
Rakesh's Code Cafe 