Can we stop with the strawmen please? My post was talking about smartphone apps on smartphones, not J2ME apps on feature phones. If you're gonna use this tactic, go all the way and pretend I was talking about BREW on a phone from 2001 or something equality ridiculous. This is really one of the poorest ways to argue any point.
Onto background processing - the major consumers of battery on a phone are the screen, CPU and radio. A background app that doesn't require the screen, doesn't do heavy processing (ie video decoding) and makes only occasional use of the radio (ie max 1 second to make an HTTP call) will have a very small impact on battery life. A simple example for this is that before Jobs & co invented this justification about why they placed such limits on the SDK, no one ever complained that MS, RIM, Nokia etc gave developers this ability.
And of course, you completely ignored the lack of system integration. Say you were Xobni and wanted to write a mobile version - you could do it on a BlackBerry, you can do it on a desktop computer, but iPhone? Sorry, Jobs no - he knows better than both users and developers.
Marty, my point is not that you want to write BREW apps, it is that many people want to do many things that Apple does not want them to do because they are not in Apple's best interests.
So please pick your argument from column A or B:
A: What you want to do is in your best interests but not Apple's, but you want them to let you do it any ways, or;
B: What you want to do is not really a negative for Apple, but they misunderstand the situation and need to be enlightened.
If you think Mr. Jobs misunderstands that your app will have very little impact on an iPhone, by all means take the position that he misunderstands. I wager that he understands that you can write a background app that doesn't drain the battery, because the iPhone ships with several of them built in.
However, that doesn't mean that somebody, somewhere won't write a crappy app that will drain the battery, and right now Apple doesn't want to allow that.
And wrt you rpoint about System Integration. Speaking of Strawmen, I doubt Apple claims that they know better than you or I what we want, it's just that they know better than you or I what they want for their platform.
It's the same as Hacker News. HN is the platform, the articles we submit are the applications.
Paul and Co. know what they want for their site, and they enforce it. I might think that articles about SUVs and Prius' are not what I want, but that's too bad. I submit the articles I want to see, and if the ones I submit don't match what Paul wants to see on HN, his bots kill them.
We can argue what we want Paul to do, and we can talk about what we would do if we ran HN, but we don't run HN, we just play by the HN rules.
So back to an iPhone. Apple makes the rules that it perceives are in its best interests, not what you or I pereceive to be in our best interests. There is no claim that they know better than you or I what we want. There is a claim that they know better than you or I what product they want to make and what custoemrs they are trying to serve.
If you like to submit posts from englishrussia.com, you don't come to HN. If you want to write applications that do background processing, you don't write for the iPhone platform.
Onto background processing - the major consumers of battery on a phone are the screen, CPU and radio. A background app that doesn't require the screen, doesn't do heavy processing (ie video decoding) and makes only occasional use of the radio (ie max 1 second to make an HTTP call) will have a very small impact on battery life. A simple example for this is that before Jobs & co invented this justification about why they placed such limits on the SDK, no one ever complained that MS, RIM, Nokia etc gave developers this ability.
And of course, you completely ignored the lack of system integration. Say you were Xobni and wanted to write a mobile version - you could do it on a BlackBerry, you can do it on a desktop computer, but iPhone? Sorry, Jobs no - he knows better than both users and developers.