Windows Phone 7 introduces app version issues in Mango update

In its first significant update, Microsoft's Windows Phone 7 platform is introducing a new layer of app version complexity for developers and users that offers a glimpse of how both it and Windows 8 will differ from Apple's existing iOS and Mac App Stores.

Windows Phone "Mango" 7.5 introduces new features for Microsoft's smartphone platform, but developers won't be able to simply offer an update to their apps to take advantage what's new in the same model that Apple's iOS app developers have over the past four versions of Apple's mobile OS.

Instead, Microsoft asks developers to distribute two different versions of their apps: the existing 7.0 version for existing phones, and a second 7.5 version for new phones and devices that can install the update once it becomes available through mobile carriers. Developers are encouraged to upload a 7.5 version by the end of October.

"Knowing that on average people update their apps every three to four months," the Windows Phone Developer Blog states, "this October timeframe provides assurance that you that you can submit 7.5 apps today and still have access to your 7.0 app well before the next update is required."

Once a 7.5 version app is published in the App Hub market, developers won't be able to fix bugs or add features to their existing 7.0 version. However, existing phone users also won't be able to run the new 7.5 version, as each major build of Windows Phone is tied to a matching app version. The WP7 market will display a list of app types for the users to select between, and users upgrading to 7.5 Mango will get updates telling them to download the new version of each app as it becomes available.

Under iOS, while Apple encourages developers to quickly support new features in the latest version of iOS soon after it is released, the newest versions of those apps can continue to run on existing phones that haven't yet updated to the latest iOS; iOS developers simply target multiple OS releases when they build their apps, and the resulting package can run, not just on multiple versions of iOS, but also across different devices from the iPhone to the larger screen of the iPad.

Most of Apple's iOS users also update their apps far more often than "every three to four months," thanks to the design of the iOS App Store, which encourages frequent app updates by making the deployment and installation of apps simple for both developers and end users.

Apple's Universal Binaries

Apple has long allowed developers to package together different code types in Universal Binaries, greatly simplifying the distribution of apps and installation issues for users. On Mac OS X, Apple used Universal Binaries to allow developers to deliver both PowerPC and Intel code in the same "app," freeing users from having to sort out which app they'd need to install on the type of hardware they had.

A similarly smooth transition was enabled by Universal Binaries in the move from 32-bit to 64-bit Intel apps. Windows users haven't been so lucky. Taking full advantage of a 64-bit PC requires installing a separate 64-bit edition of Windows and requires the installation of 64-bit apps.

On a Mac, a single hard drive partition can boot a 32-bit system or a 64-bit system, and Universal Binary apps will automatically take advantage of 64-bit features if they exist in hardware. Similarly, a single iOS app can run on iOS 3, iOS 4 or iOS 5, and can also adapt to running on an iPhone or take full advantage of iPad features, if the developer chooses to add an iPad optimized binary to the package.

This design has enabled developers to rapidly distribute apps that "just work" on whatever device they're copied to via the App Store. The basis for iOS and Mac OS X's Universal Binaries stems from a combination of NeXT's platform agnostic design as well as the fat binary technology that Apple devised to allow developers to smoothly migrate from the Macintosh's original 68k processor to PowerPC in the early 90s, affording users a comfortable period of backwards compatibility.

Understand your WP7 device

Microsoft expects users to select the correct app version for their device, noting that the only angle it seeks to improve for developers in the near future is to eventually allow them to keep updating both their 7.0 and 7.5 edition apps in parallel within the WP7 store.

The lack of support for Universal Binaries on WP7 is not surprising, because the desktop version of Windows has also never managed different types of executables for users automatically. Even when Microsoft supported multiple CPU types under Windows NT in the late 90s, users still had to obtain the correct binary type for their hardware.

In many cases, this extra layer of complication and effort prevented developers from making their apps available on different CPU types, with even Microsoft opting not to support alternative Windows NT CPU editions in its own Office or Exchange Server software.

The lack of an "app package" architecture in Windows also means Microsoft has also never offered the same simple install features Mac users are familiar with, instead choosing to construct a Start Menu of procedurally installed apps that carries forward the Program Manager functionality of Windows 3.0. Windows 8 carries forward the Start Menu, redesigned with streamlined options and a Metro touch-centric look and feel. Apps will still need to be installed and uninstalled, however.

Apple recommends that developers use its simple drag and drop installation where app packages are simply copied to the Applications folder, or the new Mac App Store model where purchased apps are copied automatically and also appear in Mac OS X Lion's new Launch Pad screen, similar to the iOS home page. Similarly, there's no work required to install apps on iOS devices. Users just select the app they want and the App Store makes it available, with no device type or OS version matching required.

Similar app fragmentation for Windows 8

Windows 8 carries forward the existing Windows 7 model of installing desktop apps through an install process involving the Registry, where each app must be paired to the CPU and 32/64-bit architecture of the hardware.

However, its new Metro runtime packages apps that can run on multiple architectures, because like a web page being rendered in a browser, they don't necessarily need to provide CPU native functionality. This will require developers to rebuild their apps from scratch to take advantage of Metro, something even Microsoft is still uncertain about doing for its own Office suite.

Meanwhile, the desktop apps users expect to run on Windows, ranging from Photoshop to Word to iTunes to Firefox, will still need to be delivered in a series of specific executable types, ranging from today's 32 or 64-bit Intel apps to the potential of new ARM desktop apps that only run on tablets or other highly mobile devices.

Because these new ARM apps will only run on Windows 8 hardware that doesn't yet exist on the market, developers will likely take a wait and see approach before doing the work to port their apps, whether as ARM desktop apps or as full Metro-style apps. This will create a catch-22 problem for new buyers of Windows 8 tablets.

Similar wait and see problems existed for WP7 smartphone users and app developers, and the same issue dogged the development of Zune games, which similarly never materialized despite the potential for such a market given Microsoft's Xbox 360 presence and shared XNA development tools.