Mobile phone application developers who arrive early on a platform have a much better chance of getting attention for their products than if they arrive later, when the platform is already crowded with other developers' apps. And those developers with the best chance of arriving early are those who bring their apps over from another platform rather than build apps from scratch. That's true now in the race to market Windows Phone 7 applications.
Winners will either be experts in the relevant porting issues or they will quickly team with partners like ICS who are experts.
A Windows Phone 7 Port Is More than a Port
Moving an existing app saves time because you don't have to reimagine the application itself. The app's basic concept is already known. So too usually are the major architectural features — although even some of these may have to be reinterpreted; for example, to support the tile user interface unique to Windows Phone 7. Where things really get tricky is in the implementation phase, especially where the frameworks, class sets and libraries associated with different platforms offer different "out of the box" resources.
In particular, building blocks available on one platform may or may not have equivalents available on the other. Where an equivalent building block is missing it may need to be created, or otherwise you might have to re-architect the entire app. So it's not just a matter of knowing how to use the development tools — Visual Studio Designer, for example. It is also knowing which pieces existing code must and can be re-implemented using whatever resources are available in the new environment.
Here's just one example: Suppose you were porting to Windows Phone 7 a graphically interactive game developed using the QML framework on Symbian. XNA is the set of classes used to create, transform and animate graphical items (rendered as sprites) on Windows Phone 7. In QML visual elements are self-displaying. XNA objects are not self-displaying but must be drawn by the XNA game object — which means the developer must create an XNA game object himself.
Two Demonstration Ports
The solution to this particular QML-to-XNA porting issue is just one of several that ICS demonstrates in its port to Windows Phone 7 of a game called QmlBounce. This is an animated interactive version of the Russian fable, "Kolobok," which is about a ball of dough that grandma is preparing for baking bread that comes to live and leads grandma and grandpa in a game of cat and mouse across the countryside. In the ICS version, the Kolobok will move or bounce around the game board and avoid obstacles that can bock its way or diminish its health. To make the game fit a small screen, Kolobok, is allowed to bounce vertically in addition to moving across the screen. The vertical direction is divided into four or five levels with each containing obstacles such as walls, cacti, or fire. To make the game visually appealing the fire is animated to give it a burning effect. You can see the game in its QML form at Nokia Developer: QML Bounce. For a play-by-play discussion of the port, check out the ICS blog. Below is a screenshot of what the game looks like on Windows Phone 7.
Besides XNA, Silverlight is the other major Windows Phone 7 development environment — suited for more traditional touch-based, data-oriented applications. ICS also ported one of these from QML. It's a Twitter app that lets the user get all her tweets, tracks who she is following and gets all their tweets, and tracks who is following her and also gets all her followers' tweets as well. You can download the original QML code here and the Silverlight code here.
Both these ports demonstrate that the time-to-market advantage of not designing from scratch is only leveraged if developers don't implement from scratch — i.e., they know how to translate design concepts from one platform to another. Knowing each platform's limitations is key. And so is knowing your own limitations in time to ask for help.