I don't understand that page at all. It doesn't explain why the app was rejected or why they can't use the native iOS pushing. In fact, I'm quite unsure of what is unique about their use-case for push notifications that is different than... any other similar task in iOS.
The iOS push notification service works by having a remote server determine when a push notification needs to be displayed to the user. The only way for Sparrow to do this would be to store the gmail credentials of every user who uses their application on a server (instead of each individual users iPhone). This would obviously introduce a lot of security considerations that Sparrow don't want to have to deal with.
Alternatively, Apple provide an API that certain apps may use to regular check for updates by running code on the iPhone, but Apple are not allowing Sparrow to use this API.
When Apple announced the various background task "modes" available (push, call placing, audio recording/playing, task completion) I immediately noticed that one use case was missing, and that's something like cron/at. Just like Apple allows tasks to run for a few moments for completion, they could allow tasks to run at scheduled times or intervals for a very limited time span, and maybe limit the number of apps/triggers allowed.
This would cover many use cases, such as alarm clocks, calendar notifications, and various poll-based background checking like new email count, maybe even headers fetching, while retaining control of watt usage.
In the meantime, I suppose Sparrow could integrate with Prowl.
The point is not that it can't be done securely, it's that they don't want the hassle of being responsible for a large amount of sensitive information. By not storing the information in the first place they can guarantee that they won't be hacked and have their customers data stolen.
