Q:

On mobile is there a reason why processes are often short lived and must persist their state explicitly?

Most mobile platforms (such as Android, iOS, Windows phone 7 and I believe the new WinRT) can kill inactive application processes under memory pressure. To prevent this from affecting the user experience applications are expected to save and restore their state as their process is killed and restarted.
Having application processes killed in this way makes the developers job harder.
On various occasions I've seen a mobile app that would:

Return to the welcome screen each time I switch back to it.
Crash when I switch back to it (possibly accessing some state that no longer exists after the process was killed)
Misbehave when I switch back to it (sometimes requiring a restart or tasks killer to fix)
Otherwise misbehave in some hard to reproduce way (e.g. android service killed and restarted at the wrong time)

I don't really understand why these mobile operating systems are designed to kill tasks in this way especially since it makes application development more difficult and error prone.
Desktop operating systems don't kill processes like that. They swap out unused pages of memory to mass storage. Is there a reason why the same approach isn't used on mobile? Mobile hardware is only a few years behind PC hardware in term of performance.
I'm sure there are very good reasons why mobile operating systems are designed this way. If you can point me to a paper or blog post that explain these reasons or can give me some insight I'd very much appreciate it.

A:

For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails. The designers of a smart phone OS must ensure that no application can interfere with these primary functions.
The other constraint of mobile is battery life, any app which "spins" in the background it will consume current and shorten battery life. The designers of a smart phone OS must ensure that any applications not being currently used are put to sleep so battery life can be extended.

A:

Battery life - many applications running in the background will drain your battery really fast.
Available memory
Processor 
Small screen
Did I mention Battery life? :)

Here is an article about this feature on the Windows Phone Platform. It starts by explaining the reason why this it is a "necessary evil": 
Mobile Matters - Windows Phone 7 Tombstoning

A good mobile platform should acknowledge the hardware constraints that mobility imposes on the device. Compared to desktops, mobile devices have less memory, less processing power, limited screen real-estate and limited battery life. Add up these constraints and you should conclude that, on a non-dedicated device where many applications will run, applications will eventually be closed or shut down to make resources available to other applications...

A:

It's not an easy task to completely hibernate and awaken a process even on desktop OS. Apart from memory pages, processes need other resources to operate correctly -- network connections, local files, locks, semaphores etc. -- all kinds of kernel/user space objects that you need to consider. And the list is growing. I thinks this answers why the apps are required to handle the dump&restore issue themselves.
Hibernate a process in Linux question from StackOverflow

