Unitasking in a sandbox: Windows Phone 7 Series' philosophy

Windows Mobile 6.x can multitask, and it can run applications written in native code. Windows Phone 7 Series can do neither of these things. The reasons are not philosophical, however: Microsoft has no problem with either concept per se. They’re practical.

The hardware is powerful enough. The underlying operating system, Windows CE 6, can multitask just fine. The built-in applications also have multitasking capabilities—mobile IE will, for example, continue to download pages in the background, and the Zune application will play music in the background. Where multitasking is absent is with third-party software. Though this has been expected for weeks, it’s only with the release of the development documentation that positive official confirmation has arrived: any time the Start hardware button is pressed (which returns the phone to the Start screen), the current third-party application is suspended (and liable to be terminated if the OS deems it necessary).

Microsoft recognizes that this is not ideal, and that it makes certain kinds of application (streaming music, for example) essentially impossible to write. The problem with multitasking is a human interaction one. It’s commonplace, Microsoft said, for Android users to have to install memory monitoring/task management type applications, and Microsoft thinks that this kind of user experience is unacceptable for a consumer device: the thing should just work. Without a good multitasking user interface, Windows Phone won’t get multitasking. Redmond won’t implement the feature until it can do it right.

This may be a risky gamble; other platforms are using the ability to multitask as a key selling point. iPhone OS 4 is widely expected to support multitasking in some capacity, and this time around the rumours might just be right. If Windows Phone comes to market as the sole phone platform that can’t multitask, Microsoft might well be better off taking the pragmatic option and allowing multitasking even if the UI isn’t perfect.

The story is similar with native code. The lack of native code is for some applications inconvenient (Adobe Reader, for example, is written in native code, and though it doesn’t do anything that particularly requires native code; it’s a large codebase that Adobe would surely prefer not to have to rewrite). For other apps it will be downright problematic (it might well prove difficult to get acceptable performance from Adobe Flash, given that Flash already defines its own virtual machine and interpreted bytecode; layering it on a second VM is unlikely to be a high performance solution). The problem here is not one of user interface, but of sandboxing. Using managed code allows Microsoft to securely lock down third-party applications to make it impossible for them to do things that they shouldn’t.

Though some kind of sandboxing would be possible for native code, it would take development effort that Redmond has thus far been unable to expend. The company recognizes that for some types of application, writing them in native code is highly desirable: it just doesn’t want to allow the option until, again, it can be done correctly.

Again, though, market forces might intervene. iPhone development is all native code, and Android development at least allows the option of native development if required. A killer native application (one contender being Flash, of course) offered for another platform might well pressure Microsoft to change its policy sooner rather than later.