Part Apple's making-software-simple philosophy is that APIs are written for specific cases - you write apps for a single resolution in iOS, you call system services instead of multitasking etc.
The advantage is that making things simpler allows them to concentrate and spend more time making them better, while the disadvantage is that it leaves lot of developers unable to meet their users' needs.
The alternative approach (Android) where APIs are pretty general allows far more developer power, then downside there being that it makes a lot of things harder/more time-consuming.
I like Marco's proposed solution, because polling is an easily abstracted or generalized operation. Pooling app polling would save a tremendous amount of setup and teardown time.
I also like his idea of iOS only allowing polling when signal is above a threshold. Data requests while in marginal coverage chew battery at an extraordinary rate. Changing my Fetch frequency on 3 mail accounts from 15 mins to 60 mins more than doubled battery life.
ReMail approached this by setting a timer to remind the user to launch the app and download mail to index. The data load for checking mail with arbitrary attachment sizes is considerably more than what Marco's talking about. I'd bet the data transfer problem is something Apple considered.
Even for small data sets, using data continually adds up. After getting their first data bill, users might prefer to be manually in charge of their data usage.
Well, Marco has no solution - he has to lobby Apple to include APIs he needs for his app. His lobbying isn't going to improve his users' experience. I also can't port my app to the iPhone, as it would require me to lobby Apple to include APIs I need.
I'm trying to illustrate how there is no perfect ideal approach.
Most of Apple's APIs are wonderfully general (e.g., look at their full 3d-aware Core Animation capabilities that are better than any desktop system (other than Mac OS X, which shares the same capabilities).
They specialize APIs when it would be harmful to generalize.
They're fighting at every turn for battery life (I'm at WWDC this week, and have seen that mantra (optimize for battery life) at nearly every talk), which is tough on developers but great for end users.
The advantage is that making things simpler allows them to concentrate and spend more time making them better, while the disadvantage is that it leaves lot of developers unable to meet their users' needs.
The alternative approach (Android) where APIs are pretty general allows far more developer power, then downside there being that it makes a lot of things harder/more time-consuming.