| This blogger has moved! |
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
There has been a lot of huffing and puffing over limitations to iPhone 3rd party apps. Especially the "one app at a time" and "no background processes" rules. A lot of people claims that these particular restrictions does not apply to the native iPhone apps or to preferred partners that Apple lets under the tent. I would like to argue that this assumption is not correct.
Some even speculate that the reason is Steve Jobs' paranoia. I'm not privy to the mans mental state, but there is no need to search for psychologic explanations. There are real reasons for these limitations. Some hope for relief over the course of the beta period but it is unlikely that they will go away. At least on the current iPhone hardware.
Why no background processes?
The iPhone, as most smartphones, has a multi-chip architecture. OK, this is going to be oversimplified, but hang on. The iPhone has many CPU's and they are connected with and controlled by the central scrutinizer, the ARM 11 CPU that runs OS X. Each CPU has its own "OS", runs fairly independently and is optimized for very specific tasks. The baseband processor runs the signaling stack, the stuff that handles the communication to the cellular network. The audio codec handles the audio stream. The Wi-Fi transceiver deals with all the mechanics related to operating the Wi-Fi port. Etc, etc.
All high-priority real-time tasks run on dedicated CPUs. When needed, the main processor asks the other parts of the system to do their dance. When the music starts (!), the audio circuitry does all the hard work, and it does it much more efficiently than the general purpose ARM processor can.
When you are, say, calling, the main CPU doesn't really do much. After you have entered the number, it can pretty much idle until you hang up. (The chances of a 3rd party applications messing with the basic calling functions should be approximately zero unless they were allowed to initiate a new call or hang up in the midst of the current call.)
The system slows down, idle or shut down whatever CPUs that are not currently needed. The iPhones impressive battery life if achieved by carefully managing and slow-clocking the system. The internal hardware design philosophy in the iPhone is that the main CPU does as little work as possible and delegates tasks to specialized circuitry. If a 3rd party background process could run the main CPU constantly, this would drain battery in no time. Of course, a modern OS like OS X can deal with resources on a very detailed level, but the iPhone OS X is apparently not set up to police 3rd party apps.
Why only one app at a time?
Having several apps running at the same time would break the interaction paradigm of the iPhone. There is no way for people to handle multiple windows on the iPhone. iPhone apps does not have an Exit button. The way to exit an app is to press the home button which brings you to the home screen. This is the behavior that people expect and there simply is no mechanism to close an app and have the the previous app come to the foreground. The iPhone does not use the WIMP paradigm that desktop OS'es does. There are no Windows, no Menus, no Pointers. You can even argue that there are no Icons either (icons in the classic sense as "visual representation of objects you can manipulate"). This may be a bit strange for people new to mobile development.
Application silos
You can try the following experiments:
1. Send an SMS with a URL to the iPhone. In the SMS app, you can click the URL to open the browser, but the SMS application closes when you do. The only way to get back from the browser to the SMS app is to go to the home screen and open the SMS app again.
(Btw, Back is very rudimentary on the iPhone and there is no global history stack. See here for more about backstepping on mobile phones.)
2. If you open the Maps app from Contacts, the Contact list closes. In the Maps app, you can add to the contacts, but the Contact application is not really open, the Maps app has simply duplicated the Contact "view". The contact list view is recreated inside the Maps application. Maps can read and write data to the contact store, but Maps and Contacts are never open at the same time.
3. When you answer an incoming call, any app currently open is closed. When the call terminates, the app is brought back to the foreground but it has to reload any content. You can try this with Maps or the Safari browser.
If you pay close attention you can see that the native iPhone apps follows the same rules that are laid down for 3rd party apps.
I think its a bit unfortunate that the iPhone seem to have a strict "application silo" approach, but this architecture is probably the result of an overriding design goal of maximizing battery life. It is something 3rd party developers just have to live with. There is not really much multitasking going on on the iPhone. "One app at a time" is here to stay.
"The same API's as we use internally"
Any application running on a mobile phone should be prepared for immediate shutdown at any time. Best-case is you get a notification when it happens, but your app can be force-quit by the OS or by the user at any time. This is true for Symbian, Android, runtimes like Java ME, FlashLite, or WebKit. Windows Mobile may be an exception to this, I don't know WinMob too well.
If you want to create an IM application you need to store any incoming traffic on a server and any outgoing traffic on the phone. I guess we will see if my claims here are bogus when the AOL IM client ships.
It would be helpful if there was a way to request the iPhone to update the bullet for your application icon on the springboard (the home screen) with some regularity. There is obviously background processes running for receiving SMS and push mail notifications. (That does not mean that the Mail or SMS apps are running.) This notification mechanism ought to be available to 3rd parties also.
When Apple says that "it's the same API as we use internally to build iPhone applications" - this is almost correct :-) These limitations are based on hardware and software design choices and are not likely to go away during the beta period.
PS: Why not run everything on a single processor?
Apple could have chosen a different architecture where everything runs on the same processor. This is the architecture that Intel has been advocating for years (without much success). The advantage is lower chip count and lower BoM, but the main processor would have to run at a higher speed and the system would be less power efficient. Symbian has recently changed its architecture to allow single core designs and some low-end smartphones from Nokia now runs what is basically two operating systems on the same CPU.
DS
On the 2.0 OS Apple has the iPod and Safari apps allowed to keep running in the background. For example, the iPod app keeps playing music while I run any app store app. However, If i'm listening to music on the AOL Radio app, I can't use any other apps while listing...
Then with Safari, can tell it does not terminate because you can go to a complex web page, open up another app, then go back to safari and the page is instantly there. There is no way, even with caching, Safari could launch and render the page that quickly, therefore Safari is still running in the background and keeping your open tabs rendered in memory.
While only two Apple apps get to run in the background...it still gives apple an unfair advantage.
Posted by: Fred | September 05, 2008 at 21:14
I beg to differ (slightly :-)):
You can happily use the Clock application to set a timer, then move on to other applications.. and the timer will still go off. As well as the alarms (otherwise it would be quite useless).
Now, third party developers COULD NOT program a timer or an alarm clock.
Other then that, this is a really interesting and well written article..
Posted by: Senseo | August 19, 2008 at 07:17
... in any 3rd Party Application.
Posted by: Aatif | June 13, 2008 at 07:32
Dear Author,
You mean that a user cannot send/receive a phone call or an SMS?
Posted by: Aatif | June 13, 2008 at 07:31