Comments on Why does everything suck?: Apple’s iPhone SDK Prohibits Real Mobile Innovatio...

Your overlooking one very important issue. If appl...

2008-07-21T00:23:00.000-04:00

Your overlooking one very important issue. If apple allowed background processes, the developers would take full advantage of this, and not all developers realize their impact. If everyone took advantage of background tasks then the battery of the phone would be almost useless.

The goal is to have a phone that functions as it should and allow developers to take advantage of the platform without taking away from the core phone.

Great Post hank. Yes, totally agree. i am in the p...

2008-07-20T22:42:00.000-04:00

Great Post hank. Yes, totally agree. i am in the process of downloading the SDK. We have built applications for Symbion and Microsoft phones, however, we are keen to delve into the IPhone space. Unfortunately, if it is as you say, not much point.

Great article,

Stephen Morton
TechOn.com.au

i agree with the author! there is no innovation wi...

2008-07-10T19:06:00.000-04:00

i agree with the author! there is no innovation without experimenting.apple is too bossy.every apple fanboy is defending steve jobs!its just a company for godssake,you spend the cash for the iphone so demand more !i have one and i want more functional apps so should you.if u are concerned about background apps running down batteries dont use.people like me we would use them.

I have a much simpler reason for Apple's omission ...

2008-07-03T00:07:00.000-04:00

I have a much simpler reason for Apple's omission of notifications- $M$.
SMS is a cash cow. The iPhone is an incredible dichotomy of cheap massive 3G connectivity (3G) and incredibly expensive and limited communication (SMS).
There is no technical reason behind this. There is one very big business reason behind the lobotomizing of the iPhone SDK.

Hank makes some cogent points (and it is mindless ...

2008-06-20T02:39:00.000-04:00

Hank makes some cogent points (and it is mindless to criticize those points simply because he isn't doing development on the phone; e.g. somebody familiar with electricity doesn't need to touch two terminals with a 2,000 volt/high amperage potential to understand that it would be a Bad Thing to do.)

Here are some additional ideas that would solve this supposed huge problem without crippling the phone's battery power etc.:

1) Let the *user* decide to permit background processing to occur, either globally or on a task-specific basis. This could be in an "Advanced" setting. The default would be "no", and the program would tell the user it needs that capability when trying to run it, if disabled, then let the user decide at that point (if yes, enable it for him.)

2) Allocate an OS enforced budget for background processing that must be shared among all background processing tasks and let it be user controlled, defaulted at say 5% (of time-slice, of battery consumption rate, etc.) and maxed at some low number. And when they pick it, make sure to do a realtime calculation estimating battery life effects.

3) Rather than emulating Microsoft's stupid task manager, have a nice GUI app that lets the user rapidly see which applications have consumed the most battery power - and that should be possible at the O.S. level, right? Like highlighting power hogs by coloring the application icon a shade of red, the more power, the redder it gets.

4) Let the *user* explicitly decide to pre-allocate the maximum level of resources (% time-slice, rate of battery consumption. etc.) a particular background-taskable program can use.

5) Make it easy to kill all background processing programs.

So rather than sneering at users for being too stupid to figure any of this out, focus on making it easy for them to handle the supposed problems while permitting the possibilities of realtime background programs.

Hi Hank,I am extremely interested to hear your tho...

2008-06-10T03:06:00.000-04:00

Hi Hank,

I am extremely interested to hear your thoughts on this topic now that Apple has made an announcement about the notification piece in today's WWDC keynote.

For the record, Twinkle, a jailbroken app on the i...

2008-06-08T04:50:00.000-04:00

For the record, Twinkle, a jailbroken app on the iPhone and iPod touch, works perfectly with no worries about "communication protocol" issues (OMG, HTTP! ONOES!). It is even location-aware and can take photographs.

Having worked in the mobile industry for nearly a ...

2008-03-30T14:19:00.000-04:00

Having worked in the mobile industry for nearly a decade, the app review and no-background tasks was almost certainly a demand of the carrier. Historically the carriers have been tyrants that aggressively defend their networks, so it's amazing that Apple got as many concessions as it has. I'm sure a large part of the app review process is a carrier blessing.

Regarding resource control. Have you ever used rlimits? They are practically useless except for memory limitations. A "nice" setting of 20 would be somewhat useful for scheduling, but would not stop a process from dragging down the whole phone's performance.

This belief of unix as having perfect security is bunk. Security is only as good as the weakest link. A single buffer overflow in an app could allow a hijacking of the iPhone. Now your phone becomes a mass emailing/sms zombie.

Perhaps a buggy application starts blasting the network. A popular and buggy app running 24/7 would effectively take the EDGE network down. That would elicit a terrible blacklash from the carrier.

Granted, all of these problems are issues for a foreground application as well. The difference is that the bad behavior stops when the user chooses to exit the application! Again, the scope of the damage is decreased from 24/7 to some short interval of time.

Allowing all of these potential issues in the background opens a technical support nightmare for Apple. All of the iPhone owners are not uber-techies. They will blame Apple, not the invisible background task, when the phone performs poorly.

One can make the red herring argument that all of these issues are problems for the desktop as well. That's true, but I don't want to play sysadmin with my phone!! Damnit, I want my phone to "just work".

Apple knows that the limitation is vastly unpopular. It's a tough problem that needs a well thought out solution. Let Apple figure out how to create a global background daemon allows applications to register for notifications. I'd be surprised if they aren't already working on the problem.

I have a touch and I am a gamer. Done be so hard ...

2008-03-26T00:52:00.000-04:00

I have a touch and I am a gamer. Done be so hard on apple maybe after they see how AIM does with background and pressence then they will give more developers this freedom. Besides they never. Are too risky these days. They like to test the waters first. Pluss for games I don't care. And they have mail for the background and they have alarms and stopwatches and u can listen to music/control ur music while on safari

„Background Processing is the Key to Mobile Innova...

2008-03-19T03:05:00.000-04:00

„Background Processing is the Key to Mobile Innovation“
I just don’t get it. What’s the big deal about this? Programers don’t want to escape the paradigm paralysis and businessmen want to quench out the last cent in my pocket. Location based services which bombards me while I’m in a mall with the latest discounts and other needless information (for the customers because discounts are only used to get the consumer spend more money [mostly for things he also doesn’t even need]).
The smarter way would be to offer the consumers a convenient way to browse the catalogue (with the discounts) on demand while standing in front or near the shop. You get the idea, we have this already THE INTERNET, so only the convenient way has to be solved.

Another always mentioned case: I want to be notified if any of my friends or contacts in my address book are nearby. Ridiculous to implement this as an always polling service. If I want to know it I push a button and then get the info. The carrier already knows where I am, it is necessary to receive calls.
Hell, why do I want to get everything in every situation at once? If I’m in need for a particular info then it is at a fingertip and not besides hundreds of other useless information.

The argument for an IM app that it’s desperately in need for running a background processes is stupid, or more gently not well thought out. As some already mentioned it in comments before mine. You can read a more detailed description in solving this at this post (iPhone creativity – Third party background processes)
http://miki.samborsky.de/iphone-creativity-%e2%80%93-third-party-background-processes/33/.

Finally, I think the main problem is the paradigm paralysis. It has to be the old way or it won’t work. The old way was to squander CPU cycles and other resources; code inefficiently. Think about that.

What interests me about the lack of support for ba...

2008-03-17T14:38:00.000-04:00

What interests me about the lack of support for background routines is how it affects systems that want to push information to applications on the iPhone.

During the SDK launch, Chuck Dietrich from Salesforce.com talked about the ability of his sample app. to use Salesforce.com's "advanced workflow triggers" to push new information down to the iPhone. He even showed an example of more information arriving during the demo.

BUT this information arrived while the Salesforce.com application was OPEN in the iPhone. In other words, it wasn't so much a "push" as a "pull" by the running application.

If the SDK doesn't support background threads how can applications like Salesforce.com really work? How can the iPhone alert the user when new information is available from an external site unless the user keeps opening the specific application at regular intervals to check?

Surely this impacts the potential of the iPhone to support a whole class of applications that monitor external events in some way - e.g. RSS feed readers, SNMP clients, etc. ??

Thanks for all of your comments. While I cannot re...

2008-03-17T10:58:00.000-04:00

Thanks for all of your comments. While I cannot respond to all of your comments, I have responded to some of them in my summary post here.

Where and when did someone say AIM was running in ...

2008-03-16T21:00:00.000-04:00

Where and when did someone say AIM was running in the background at the SDK rollout?

What AIM showed is what they were capable of building in two weeks with the SDK they had. No where did they say they built a complete application, nor did they say that it's running in the background.

You may find an AIM application that only runs when it's in the foreground useless, but that is a separate issue from whether the SDK launch was a "lie" because AIM is doing something no one else is doing.

What basis to suggest the launch was a lie?

anonymous hit the nail on the head with the AIM de...

2008-03-16T17:39:00.000-04:00

anonymous hit the nail on the head with the AIM demo. There was nothing in the demo to indicate that they were using background processing, because they never exited the program to show you what would happen. It's entirely possible that the AIM client that AOL created in that two weeks required you to be in the app to receive messages and be online.

The thing is though, minor changes to the AIM protocol could even allow for more. Because the iPhone has no concept of multitasking except in a few rare cases (phone, iPod, iCal), there's no concept of being "inactive" in a chat. In the iPhone, the only concepts available to the user are active or offline. So if AOL changed the protocol so that you could send messages to offline contacts (which you may actually be able to do already), then the AIM client would just need to fetch and display all the messages when it starts up. The user wouldn't care whether or not they were booted offline or not.

The author here is thinking in desktop UI terms, which are not applicable to the iPhone UI. There's only one possible app that can be onscreen at anytime, so whether or not the user goes offline when the app is quit is irrelevant. The user won't know any difference.

Bottom line is, background processing is completely unnecessary for an AIM client.

It's not generally constructive to look back, espe...

2008-03-16T14:22:00.000-04:00

It's not generally constructive to look back, especially in anger, but from the history of self-serving and mercenary treachery of the developer community towards a company and hardware platform that arguably gave them their first meaningful opportunities to cut their teeth on truly groundbreaking usability applications, if I put myself in Apple's place for a mere instant I would swear an oath never to concede even an inch of control in software development outside of Cupertino.

To those come-lately developers who were probably still sloshing around merrily in their fathers gonads when the events I allude to were going down, I will not even bother to expatiate on this history other than to tell them to go read it up and wise up (www.roughlydrafted.com is a good port of call to get the "big picture").

Those that fail to heed the lessons of history (including Apple Inc) are doomed to repeat it endlessly. Apple would be twice damned if they allowed the ignoble events of the 80s and 90s to pan out again by losing sight of the big picture and getting lost in less significant detail of the wants and desires of individuals and a knowledgeable but philistine minority rather than the needs of the whole and the "greater good".

I think there is more to the iPhone than the anima...

2008-03-16T01:25:00.000-04:00

I think there is more to the iPhone than the animated and shrink UI features you mention. You as a developer may care about the lack of this feature in the sdk at this time but I highly doubt that the majority of the customers for this device do. We want it simply to work without having to trouble shoot which of the new apps are suddenly draining all the resources from our device.

I absolutely agree with this, and am frankly disap...

2008-03-15T18:44:00.000-04:00

I absolutely agree with this, and am frankly disappointed that Apple seems to have decided that Freedom Zero is not worth considering in the mobile space. How long have developers, in particular, lauded the fact that Apple offered not only the best toolkit, but the most UNIX-like mainstream OS, and made it easy for 3rd-party apps to have the same degree of functionality and polish as Apple's own.

Now, between the crippled iPhone SDK (and the apparent waiting list/vetting process needed to even get a developer cert) Apple is showing that they basically think that they can do better than the independent developers that have made the Mac their home for so many years and kept it a viable platform.

iPhone apps written with the current SDK will be pretty, but shallow.

For those who think that resource limits on background processes are so tough: what exactly is different about foreground processes, then? It would be easy enough for a graphical app with focus to peg the CPU and GPU for several minutes, and cost you a huge chunk of battery and/or bandwidth; where, then, is the outcry about how developers can't be trusted with such precious resources, and even foreground apps should be severely constrained?

Once you start down the path of declaring 3rd-party apps to be "second-class citizens," you enter a world no different from Microsoft's.

Personally, while I love Apple's hardware, I will not spend one damn cent in the future to support their DRM-laden software stack. After 15 years buying Macs, my current Apple machine will sadly be my last, unless they cease treating their users and developers like precocious children.

"Our application would not be easily possible on a...

2008-03-15T15:20:00.000-04:00

"Our application would not be easily possible on any platform other than Android."

Any? What about platforms other than Android or iPhone? Would it be harder on OpenMoko, for example?

Actually, the AIM example was perfectly valid. You...

2008-03-15T14:59:00.000-04:00

Actually, the AIM example was perfectly valid. You can use AIM for chatting when your want to chat. If you exit the app, sure now your chat client is no longer running. But nothing in the demo or in the discussion implied that it would--only you assumed that it had to be real-time, constantly on, and behave identically to a desktop equivalent. But it doesn't have to, and for many, if not most, users, the ability to use AIM for quick chats is a huge win even if the live notification is not present.

I do get the gist of the argument--that allowing background processes would grant developers greater flexibility and could result in some truly amazing apps. But I don't buy your conclusion at all--it depends on agreement that your assessment of what makes a 3rd party application useful is the one and only definition. And quite frankly, it's not.

Luis: ''The "two week test" could be done under a ...

2008-03-15T11:35:00.000-04:00

Luis: ''The "two week test" could be done under a different contract.
I agree with you that "it is misleading" but how can you be so sure as to say it is a "lie"?''

So when Apple said "We are releasing the SDK. Here is an example of what can be done (AIM)", it is not a lie? If they had said that AOL had access to a special version of the SDK, then why didn't they say so?

There may be other ways of getting status updates ...

2008-03-15T11:12:00.000-04:00

There may be other ways of getting status updates and alerts, without needing to run apps in the background.

Would it not be better for one main background thread to do all the checking and polling at predefined (and maybe user-controlded) intervals? I'd much rather have a well-implemented pluripotential über daemon, than the inefficiencies of 1,000 developers kluding together their versions.

I suspect/hope that Apple are working on some kind of unified background notification service ("Core Notification"?). In fact, I shall be submitting a feature request for this...

Comparing Android, which is not actually available...

2008-03-15T10:26:00.000-04:00

Comparing Android, which is not actually available on any phone, to the iPhone SDK, which is a beta, seems a little odd to me. Who knows how Android will behave when available on an actual product.

I'd be surprised if Apple didn't eventually allow background processes, and I agree that it will be necessary to move the platform forward.

Hank,You claim that resource management problems f...

2008-03-15T09:02:00.000-04:00

Hank,

You claim that resource management problems for background third party apps have already been solved in real time systems. Frankly, I'm calling BS on that. I can not think of a single real time system that is open to background process third party apps (already a very rare beast), that has created a good solution to this. Indeed, the only example that I can think of (WinCE), is generally considered a textbook case of why this sort of programming is a bad idea for real time systems.

Of course, if you have any good examples, I'd love to hear about them.

Hank,I asked you: How lonely does it get?You haven...

2008-03-15T04:13:00.000-04:00

Hank,

I asked you: How lonely does it get?
You haven't answered yet.
But I hear you coughing in the tower of songs.

SCNR

This is a function of scale.Apple simply doesn't h...

2008-03-15T02:38:00.000-04:00

This is a function of scale.

Apple simply doesn't have the resources necessary to pore over what will undoubtably be millions of lines of code that are being written right now.

They do, however, have the resources to work with an extremely select group of partners; eg AOL, Cisco, EA, and other big-pocketed companies.

But let's assume that you had the ability to launch a background daemon.

Okay, we'll use your Unix resource limiting argument (which, if you've ever actually worked with ulimit, you would know that this is the dumbest idea ever and is only meant to stop runaway processes -- but I digress).

You fire off your background task, and you have a limited number of CPU seconds to use. Now, somewhere along the line, that background task will hit that limit, because people have this annoying habit of leaving their phones running 24/7, yeah, shocking, right? So your process hits the CPU seconds limit because it's either using Quartz, or it's doing SQLite work, or it's doing XML parsing, or whatever. When it hits that limit, the process gets terminated.

So now, you have a defunct background process, and if you're lucky, maybe, just maybe, the iPhone will be nice enough to send you a term signal that causes your background process to throw up a modal dialog that says "oh shit, guess what, we ran out of CPU juice, so we're stopping now".

Do you realize A) how absolutely stupid that is from a user experience perspective? or B) how maddening it is to have to deal with a background process that you can't rely upon? or C) that any sort of timely work is essentially impossible, given that your background process is guaranteed to be running at nice 19 (because let's face it, nobody puts iTunes in a corner)?

Apple has to draw the line somewhere. As a Mac developer, you get full blown access to loading frameworks, running background tasks, the whole shebang, because guess what, there is a honking big battery and a CPU that sits mostly idle inside your user's Macbook. That simply isn't the case with the iPhone. Adding resource and process limits isn't enough when thirty apps are all vying for CPU slices.

Yeah, I'm writing an app, and yeah, it would be a lot cooler if I had the capability to throw a thread in the background and forget about it, but guess what, I'm working around it. I'm implementing the equivalent of an offline queue, and then working on the queue when the app runs.

And by the way, Twitter _already_ _runs_ on the iPhone, because Twitter sends out notifications via SMS. AIM can work the same way (like it does with a lot of phones). I think there are a lot more options for application development than a lot of these knee-jerk reactions are thinking about.