iPhone SDK restrictions "troubling" to some

a Copy and Paste implementation?

AIM has already created a client so who cares, as long as we have one IM client

This is what anyone who had been paying attention would have expected.

The fact that only one application runs at a time is, I believe, the case even with Apple's applications. With the built-in applications, I believe the only multi-tasking is to allow the iPod and phone functions to overlap with some other applications.

The reasons to limit multi-tasking seem simple. First, this isn't a laptop with unlimited resources, it's a small embedded device. Second, security is still an issue, and Apple wouldn't want any surprises with applications messing with calls, etc.

For most of these problems, the work around is to do what Apple has been doing. Have your applications transparently save their state when they quit, and restore when you re-launch them. (Play around, and I think you will agree this is how Safari, etc. work now.)

This is a shame in the case of Instant Messaging. I really hope Apple comes up with a solution to this-- and I suspect exceptions will be made, if possible, for major functions and major partners.

sometimes it comes at the expense of some freedom. Rather that then some virus riddled portable brick. :)

I'm not so sure about this. Unless the 2.0 software makes some dramatic changes to the fundamental architecture of the iPhone OS, there should be a way to launch a daemon. After all, I have a webserver running on my iPhone all the time, and running daemons is arguably what *nix does best. It's possible that Apple will not allow signed apps to daemonize themselves (or parts of themselves), but if so, I suspect that will be one of the first things to be hacked. DRM doesn't last, period.

As for limited resources being the reason for disallowing background apps - I don't think that's the case. Running a simple daemon like a chat client or web server takes up almost no resources, especially if it's not managing an interface. The interface portion can quit and reload, while the daemon part sits happily in the background, occasionally checking for incoming info. This is what the mail app currently does. This type of application uses very very little in the way of resources, to the point where you can now buy a watch with an embedded webserver. What it does do, however, is dramatically increase the insecurity of the phone. Once you have a daemon constantly running and communicating, you dramatically increase the possibility of being hacked.

I'm not sure what the right trade-off is: no matter what you decide, some folks will be upset. But it clearly shows that jailbreaking ain't going away anytime soon. And I don't believe that requiring signed apps will do anything.

One daemon...no problem. But if every developer is allowed to install and run one in the background, soon you could have dozens running. It's probably one of those things where if you could trust everyone to play nicely and be reasonable in how they implement their apps it would be no problem.

It will be interesting how this evolves over time. Is Apple just being cautious and overprotective? Or are there other motives for the limitations? I'm guess the former.

Well, I will count myself among the "bummed out if no daemons" group - many of the things I want to and can imagine doing require them.

But I've also been trying to look at it from Apple's perspective. I don't think they really see this as a phone. I think they see this as the first step in developing a platform, achieving the promise of what the Newton and Information Navigator once had, way back when (yes I know I'm dating myself by mentioning the information navigator concept). I think they feel the choices they make now will set the standard for the mobile computing industry as a whole. And they desperately want to avoid the horrible problems that have plagued the Windows-dominated computing world. While some of those have come from an utter lack of good taste, the vast majority can be traced back to poor security practices embedded in the core of the OS at a time when noone took the internet seriously. I think Apple takes this stuff seriously, and whether you think it arrogant of them or not, they do want to make money on this for a long time to come, and selling subpar products isn't how Apple makes money.

To bring it full circle, I think this is some of the reasoning behind not allowing daemons, and by extension not allowing access to some parts of the iPhone OS.

The iPhones (and iPod Touches in Wifi mode) are communication devices. Most of what people will want to do with these devices involves, well, ..., communication !!! There must be a way to register listeners within an SDK, or communication apps will be impossible to write. Would it make sense to have a geo-aware social networking application that can only notify you that your friends are nearby when the app is on-screen? How about a VOIP or IM app that can only ring you when the app is being displayed?

This restriction results in a scenario where the only apps that can be "legitimately" written will be games or toys. Nothing serious can exist on a communication device without the ability to respond to outside events.

That being said, it seems to me that Apple could, if they so desired, provide an API that would allow you to indicate a port, a set of responses and an app and allow the OS to handle the actual task of daemonizing the listeners for security purposes. In such a scenario, you could inform an API to allow the phone to "ring" in some way when a particular port is contacted, and depending on the user response, invoke a particular app. Maybe something like this is already present or in the works? It's still a bit early and this will evolve.

"... it clearly shows that jailbreaking ain't going away anytime soon..."

Perhaps. I'm pretty sure that Apple know just how each of the "jailbreak" solutions works, and how to stop them. It may suit them to tolerate the process at the moment, but it could well be that the second an official solution is available...

dogzilla says: "...many of the things I want to and can imagine doing require them..." Then you clearly are neither thinking outside the box enough, nor are displaying the necessary innovative creativity to deal with reasonably imposed limitations.

OS X, now, has the ability to sandbox apps, meaning that if you deploy your app, it is very limited in terms of what it can do outside of the sandbox allocated to it -- that's why Apple provides an extensive API. Launching daemons? Not likely if you're a signed app. Trying to work around it? Better deal with getting your license revoked.

As you pointed out in your follow-up post - there are very reasonable reasons why Apple has set the limitations it did, and I have absolutely no problem with them, as I prefer a stable, and reliable iPhone, versus a rice'd out piece of crap (i.e. Symbian or Windows Mobile phones). Yeah, it may bum out a few devs, but overall, you may find out that there are plenty of ways to achieve your goals, within the limitations set.

Again, most people live under the false impression that iPhone is a small Mac OS X computer, and thus feeling a sense of entitlement that Apple owes them to provide what they want. Well, it ain't so - iPhone is what Apple states it is, not what you want it to be.

Limitations encourage people to innovate -- lack of limitations makes people lazy. I mean, let's take a look back (since you're dating yourself, dogzilla) what developers were able to do within the confines of 64 and 128 KILObytes back on the Apple //e.

Now, compare that to some of the crap that passes for 'games' these days... 'nuff said.