Microsoft has made the WP8 SDK available to everyone. The only question is why was it held back for so long? On a first look there seems to be nothing that needed to be kept secret and nothing to be ashamed of. SO why the wait? It's a mystery.

Holding back the WP8 SDK has put more than just a little dampener on the enthusiasm of many programmers for Windows Phone. After all, the new phone is not backward compatible with WP7, and so who wants to continue to develop apps for WP7 when you know WP8 is just a few months away?

The reason given for not issuing the SDK, i.e. that there were new features that were going to be announced at the launch and releasing the SDK would let the cat out of the bag, is just silly. There were no amazing features announced at the launch, mostly more of what everyone had heard already with a few nice extras. Now that the SDK is here you can look at it quite hard and still you won't see anything to shout about.

Even the alternative suggestion, that the SDK was so flaky that it had to be worked on some more, doesn't now seem highly likely - the SDK as delivered looks to be fairly stable and reasonably complete. So unless there has been an unreported miracle, not impossible but unlikely, it can't have been so bad a few months ago.

The reason for the holding back on the public release of the SDK may remain a mystery, but the damage that it has done is real enough.

You can now download the Express development environment, or the add on to Visual Studio 2012, complete with the WP8 SDK and start creating apps.

There are some problems in store, but overall it all looks surprisingly good.

You can only run the development system on a 64-bit Windows 8 Pro machine. You can use a virtual machine but you won't be able to run the WP8 emulator because it needs a machine that supports Second Level Address Translation, i.e. a machine that runs HyperV. Even if you can't run the emulator, you can still develop apps for WP8 but you will need a real phone to try them out.

First the bad news - XNA projects are no longer supported and there is no support for JavaScript apps. The lack of XNA support will be a big problem, but for relatively few programmers. Existing XNA apps will run but you can't develop them any further. Some XNA assemblies are supported but the situation is complicated.

The lack of JavaScript app support is more of a problem because this is one of the three ways to create a Windows 8 WinRT app. If you have spent a lot of time working on a JavaScript app for Windows 8 you might well have expected that it would also work on WP8 - it won't.

The good news is that porting your WP7 Silverlight apps is easier than expected. Although Silverlight isn't supported under WP8, all of the XAML and all of the framework classes that you use to create a WP7 Silverlight app are supported. What this means is that you have to import existing WP7 projects and have them converted to WP8 apps. I've tried this on a number of simple projects and it all worked - the few problems were minor and easily fixed. More importantly the code changes were virtually zero. Everything looks the same and I can continue working with the new project as if it was the old one, but without the word "Silverlight" being used.

The bad news is that there is no covering up the fact that this is a new start. The import and conversion process is one-way and one-time. Your new project cannot now target WP7. The solutions are to basically keep two versions of your code base and develop in parallel. Or, of course, you could just leave your app frozen on WP7 and make progress only under WP8. If WP8 starts to sell well this seems to be a good option - WP7 really is a dead end.

There are also a number of new ways to create apps for WP8. You can choose now to work in C++ and create fast native apps, but of course this would be a new project as WP7 didn't support C++. The ability to use DirectX with XAML for the UI looks attractive but it will take more time to evaluate. 

What is encouraging is that while C++/DirectX is a more difficult environment to work in, the original C# XAML environment which was so easy to work with has been maintained. What this means is that you can start a C# WP8 project very quickly and have something working in no time at all. You still have the Pivot and Panorama controls, for example, and databinding works in the same way. In addition you also have a choice of some new project types including C# XAML and DirectX.

What all of this means is that not only has the new system made it possible to create more powerful apps, it has managed to retain the simplicity of the original Silverlight approach and this lowers the bar for getting started with WP8.

In fact you could argue that WP8 is now the easiest mobile phone to develop for and this might be the advantage it needs.

To encourage you to take up the challenge, Microsoft is offering $8 registration at the Dev Center instead of the usual $99 for the next eight days.

Given that WP8 is a new start, it is a risky platform to place your apps on, but which comes first the apps or the users?