iPhone 4.0 hope: background tools via launchd
A lot of people want to run apps in the background on the iPhone, but I believe that Apple has some very legitimate concerns about the feasibility of doing so, at least on the current hardware platforms. However, I believe that there is a perfectly valid way of accommodating most developers’ background-execution needs. This system is called ‘launchd’, and I believe it would provide a very good means of allowing certain tasks to run in the background under the control of various system policies enforced by Apple.
In Snow Leopard, there are some new APIs designed to allow general purpose applications to install background tools used for privilege elevation; these APIs make use of code signing rules to verify that the installing application and the privilege tool match one another (i.e. they must both securely authenticate against one another). The details of this API are in the ServiceManagement framework in 10.6: look at ServiceManagement/ServiceManagement.h, specifically the SMJobBless() function.
This functionality could be used on the iPhone to provide authorized installation and management of user-based (NOT privileged!) background tools, which could be run under a specific launchd instance designed to keep these tasks under control. The launchd environment could also be limited in the functionality it provides: rather than allowing background processes to always run, or to launch and stay alive, it could allow only for launch-on-demand semantics with the requirement that a process keep checking in as it processes data in order to be kept alive beyond a certain threshold. This launchd instance could also throttle the number of such processes running at any one time, or coalesce received data to avoid launching background processes too often (process creation is a lot of work, after all).
This way we could write applications which can perform some small amount of networking on a timed basis (such as pinging a Basecamp server once per hour to check whether updates are required), or could handle Push Notifications in the background, storing received data in a temporary file ready for the real application to handle upon its launch. This last could be useful for twitter-type applications, for example: direct messages could result in a prompt, while @mentions could be dumped quietly to disk so the foreground application can pick them up without waiting for a network connection when it is launched.
Lastly, due to the use of code signing to pair the two processes together, an additional level of security/control is gained by the system, since any attempt to modify either the foreground or background application would result in its code signature becoming invalid. This can then be used as a flag by the system not to allow background processing either way: if either foreground or background signature is invalid, the background process will NOT be launched, EVER.
Pairing this technique with the app store approvals process should guarantee that abuses are kept to a minimum whilst providing developers with some very useful functionality.