John Gruber, Mac blogger extraordinaire, has a post today about what I consider to be the most glaring problem with the iPhone SDK. I don't know John, but I rarely disagree with him on matters related to Apple, but although I think he makes good points about WHY Apple chose to put this limitation on the SDK, I disagree that Apple should be the one making this choice. If a user wants to put a program on their iPhone that will reduce their battery life, that should be their choice. Apple is requiring all apps to be reviewed, so in theory, an app that went overboard or impacted the network would be stopped by them in their role as App Store gatekeeper.
There are many, many potential killer apps for the iPhone that simply can't be created without some way of running code in the background. If they can't allow this, then there should be some alternative available. Maybe there is, and it's buried in the SDK somewhere, but I haven't found it, and I've been looking pretty hard since last Thursday.
Apple obviously recognizes the need for this, since they do it themselves in Mail. It seems pretty obnoxious to say "yeah, we need to do this, but you can't. Ever." Yeah, I know it's their phone, and they can pretty much do anything because they wrote the software that runs it, but I think this limitation is potentially devastating in terms of the iPhone reaching its full potential as a "mobile platform", especially one that Apple seems to be positioning for a push into the Enterprise market.
It seems there must be a way to address their concerns, and yet make it possible for apps to do things when they are not being run.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment