A Tale from the Trenches: porting (or not) a Windows Phone app to Windows 8

I began to work last month on Stacks, my Windows 8 app. It’s a client for Instapaper, the leading iOS app for reader junkies. I already developed a Windows Phone 7 version of the app, so I know the API, but I was not entirely satisfied with the result. It was my first Windows Phone app, my first mobile app and my first public app — that’s a lot of firsts! One of the weak points was the reading experience. It’s based on a WebView control and it’s a pain to communicate between the native code and the control. Apart from this, the rest of the code could benefit from a refactoring (to fully support the offline mode for example).

Back in September I began to port my Windows Phone code to the Windows 8 Developer Preview. On top of the rough experience due to the alpha phase of the release (COM exceptions all over the place!), it was not an easy task. WinRT benefits from C# 5 await/async features and so a lot of API have been updated to support the Task-Based Asynchronous Pattern.

Along the way it appeared that Microsoft was porting the Windows NT Kernel for Windows Phone (read this great analysis by Hal Berenson). The confirmation came in June at the Developer Summit where Microsoft announced the technical details of Windows 8. If I want to invest in the future of Stacks, a complete rewrite for Windows 8 (and Windows Phone 8) is the way to go. It’s not a complete rewrite, since I can use a lot of code, but still it’s a lot of work. Finally I find a way to use the native controls for Document and so to paginate etc. properly.

We don’t have yet the level of compatibility between the runtime found on Windows and the one on Windows Phone. From the SDK leaked last week it seems only XAML and native code is supported but even the XAML seems to be more the one from the Windows Phone (managed) that the native flavor of Windows 8.

I will post in the coming weeks about my experience in developing Stacks.