[tazzben]

In my case it's a very good thing because we write CRM (customer relationship management) software. To wait until the iPhone was docked would miss the point. As others users use the CRM for the company the iPhone user(s) would need to know of changes as they are out in the field.

But even that isn't the point. Let's say you aren't writing a CRM, or any sort of collaborative app. You can still use a bonjour (or other network) connection to communicate between the iPhone and the desktop. AND it means that you aren't limited by when the user may connect their device. Also, as you are in complete control of the sync process, you can do very efficient incremental sync.

Again this comes back to the constraints. If apple had some some pre packaged sync, lots of people would use it; when now because they are forced to rethink it, they can create vastly better sync systems that fit better with what the application is designed to do.

[tazzben]

Oh.. I might add, writing a sync system given all the network tools apple gives you isn't, you know, hard. We aren't talking about a lot of work

[bslayerw]

You're making a lot of sense, there's huge potential for apps that behave this way. However now that I think of it (total guess here), because your data is sandboxed to your application (all in the same folder/package) you'll probably get data synch for free if iTunes backs up/synchs your iPhone apps if that's all you need.

Anyways, getting off topic and probably more appropriate for another forum.

[griffman]

"....and please check your facts. Since 2004 (eons in internet age) you have had the option to not be logged of when closing an AIM client. Come on Rob....research!"

Great, you can not be logged off. So explain to me how that helps someone chat with me when I've "quit" the chat app by checking my email? Sure, when I log in again, I'll get the messages they sent me. That is not the same thing as running in the background and being informed that you have a new message waiting.

Push vs. pull. Real time vs. launch app. Night vs. day.

-rob.

[griffman]

" Why don't you wait for that clarification from Apple before you spread panic about it? I know Apple can be a pain in the butt about clarifying such things, but until we know for sure exactly how literally we're supposed to take the Interface Guidelines, it's a little premature to assume that apps won't BE ABLE to run in the background."

As others have pointed out, the SDK provides crystal clear clarity. Rule #1: Apps must abide by the HIG. The HIG says 'no background apps.' Ergo, no open question.

The reason I chose to talk about this now is so that, on the off chance anyone from Apple reads such things, they understand that this rule will impact the functionality of the software they're hoping I'm going to purchase in a few months. There's still time to change it, though, which is why I bring it up now.

-rob.

[hypermark]

It will be interesting to see whether these limitations are trial balloons or not.

I hope that they are, and that Apple continues to iterate their SDK strategy until they hit the sweet spot required to decisively win the hearts and minds of the developer community.

Applea??s history with the developer community gives some reason for pause, something that I recently blogged about in, a??The Scorpion, the Frog and the iPhone SDK.a??

Check it out if interested:

http://thenetworkgar...corpion-th.html

Cheers,

Mark

[Lonestar1]

"The reason I chose to talk about this now is so that, on the off chance anyone from Apple reads such things, they understand that this rule will impact the functionality of the software they're hoping I'm going to purchase in a few months."

So, given the choice between

1) filing a bug report/feature request with Apple

and

2) complaining on a random blog and hoping "on the off chance anyone from Apple reads such things,"

you chose 2) as the method more likely to get results?

Not the choice I would have made.

[bslayerw]

Lonestar1 said:

"The reason I chose to talk about this now is so that, on the off chance anyone from Apple reads such things, they understand that this rule will impact the functionality of the software they're hoping I'm going to purchase in a few months."

So, given the choice between

1) filing a bug report/feature request with Apple

and

2) complaining on a random blog and hoping "on the off chance anyone from Apple reads such things,"

you chose 2) as the method more likely to get results?

Not the choice I would have made.

I'd hardly call Macworld a random blog. Many have already filed bugs for these type of things (I know because mine get closed as duplicates). So yeah method 2 is more likely to get better results because instead of a bug report we have a thorough discussion about the topic in a public forum where instead of an Apple Engineer closing filed bugs we have Apple PR possibly accessing the situation.

[griffman]

Did I ever state whether I did or did not file a bug report? As noted above, it's been done (and Apple only keeps the first instance of a bug report open, and duplicate filers get no progress reports). But Apple has also shown they listen to public reaction (translucent menu bar, Stacks' functionality) as much or more than they listen to bug reports -- so both methods are important, but only one allows public discussion of an issue. And it's that public discussion that can help determine what Apple does or doesn't do. (Please don't interpret that as "my opinion is so important that it's the public discussion on Macworld.com that really counts." It means public discussion in general, regardless of the source. If others are blogging the same issue, regardless of their stance on it, that's a good thing. Discussing things in public gives Apple an eye into a larger population, as opposed to just those developers reporting bugs and feature requests.)

-rob.

[deasys]

"Of course, one reason Apple may have chosen to prohibit this feature has to do with security and stability: if each program can only run when ita??s frontmost, then therea??s no way it can cause another program to crash, or do bad things like capture key presses from another program, or drain the battery in a very short period of time."
Bingo!
Those seem like damn good reasons to me to limit backgrounding on the iPhone / iPod Touch.

[zensunni]

Macworld said:

Of course, one reason Apple may have chosen to prohibit this feature has to do with security and stability: if each program can only run when it’s frontmost, then there’s no way it can cause another program to crash, or do bad things like capture key presses from another program, or drain the battery in a very short period of time.

Of course. That's their rationalization behind every restriction on the iPhone. Though I find it ironic that security and stability aren't an issue on my MacBook Pro and iMac (at least, not for Apple. They are for me. And like others I've found Leopard itself to be less stable than prior versions of OS X). Apple hasn't restricted development on either of these, yet security and stability are just as important. Of course, no one would accept such silly restrictions on a personal computer, so are we accepting them on the iPhone?

Macworld said:

But whatever the reason, it’s vital that Apple consider allowing developers to take advantage of this feature, at least on a case-by-case basis. If Apple doesn’t want to allow everyone’s programs to run in the background, perhaps developers could submit their background-savvy programs for extra approvals. Or perhaps Apple could open up additional features, including the ability for programs to run in the background, for developers who pay to become registered iPhone developers at some higher tier than the current $99 barrier.

Oh my, this is yet another reason why this whole situation is unacceptable. You're suggesting privileged levels of access for developers based on either having to prove their worth to Apple or paying a higher fee? And in either case, Apple can remove the privilege any time they aren't happy with what you've done. Geez, man, Apple will certainly jump at the opportunity, but this is only furthering a horrible precedent (having to pay to develop distributable programs) to an even more unacceptable situation rather than rectifying it. Another thing the big commercial developers would love (small pence for them to pay), but a further kick in the ribs to independent, open source developers of free software.

[bslayerw]

deasys said:

"Of course, one reason Apple may have chosen to prohibit this feature has to do with security and stability: if each program can only run when ita??s frontmost, then therea??s no way it can cause another program to crash, or do bad things like capture key presses from another program, or drain the battery in a very short period of time."

Bingo!

Those seem like damn good reasons to me to limit backgrounding on the iPhone / iPod Touch.

foreground apps can crash the iPhone and kill your battery, no bingo for you.

[Lonestar1]

"I'd hardly call Macworld a random blog. Many have already filed bugs for these type of things (I know because mine get closed as duplicates)."

Every developer closes duplicate bugs. That's hardly shocking.

So you weren't really trying to get Apple's attention, since you already knew the request had been reported to Apple.

"So yeah method 2 is more likely to get better results because instead of a bug report we have a thorough discussion about the topic in a public forum where instead of an Apple Engineer closing filed bugs we have Apple PR possibly accessing the situation."

Sorry, but technical decisions are made by engineers, not PR people.

Exactly what kind of developer are you?

[Lonestar1]

"Of course. That's their rationalization behind every restriction on the iPhone. Though I find it ironic that security and stability aren't an issue on my MacBook Pro and iMac (at least, not for Apple. They are for me."

I find it ironic that people calling themselves iPhone developers don't understand the platform differences between the iPhone and a MacBook Pro.

In the real world, there are always technical limitations and tradeoffs. No one gets everything they want, all the time. If you think every tradeoff is a "rationalization" then you don't understand the constraints of the real world.

I know this is going to sound harsh, but if you can't even understand that there are real security, stability, and performance tradeoffs -- not "rationalizations" -- then your technical opinion is not worth very much.