Two companies have now announced their Windows Phone 8 hardware. Samsung was first out of the blocks, showing off its ATIV S at IFA last month. With much fanfare, Nokia revealed its first pair of Windows Phone 8 handsets, the Lumia 820 and Lumia 920. But in spite of gathering journalists from all over the world, a few things were missing from Nokia's press conference.

Some things weren't entirely surprising. Nokia didn't announce any availability information—pricing, dates, carrier partnerships, all were left unspoken. While one always has to wonder about the value of this kind of paper launch—it may create excitement, but there's no way of converting that excitement into revenue if nobody can actually place an order—it's an unfortunate industry standard practice.

But what was a little surprising is that there were no handsets for the press to play with. There were some demonstration units carefully attended by PR personnel, and while we were able to get kind of close to them, the general rule was "you can look but you can't touch." This isn't unprecedented, but it's a little unusual for such a high-priority smartphone launch. Touching the phones, seeing how they feel in the hand, checking that their UI is nice and fast, these are all important parts of a smartphone launch.

The problem Nokia has appears to be not so much its hardware; it's the software. Windows Phone 8 isn't done yet. Not only is Windows Phone 8 not done, it's not even public yet. If Nokia let the assembled members of the fourth estate use its shiny new phones, they'd end up learning about Windows Phone 8's unrevealed features—features that Microsoft hasn't yet talked about.

All we officially know about Windows Phone 8 was announced in San Francisco in June. This event was originally billed as a "Windows Phone Developer Summit," and according to the first set of invitations that were sent out, it was originally due to last two days. It's unconfirmed, but widely believed that Microsoft was planning to ship the Windows Phone 8 SDK at the same time.

Whatever the cause of the delays—whether they're because Microsoft has bitten off more than it can chew with the kernel transition, or due to some other reason—the situation is now growing critical.

That didn't happen, though, because the SDK wasn't ready. So instead of cancelling, Microsoft put on a much smaller event, announcing just a handful of new features—turn-by-turn navigation, VoIP integration, an NFC Wallet, a more flexible Start screen, greater enterprise support, and underlying it all, a version of the Windows NT kernel—and promising that an SDK would arrive at some point in the summer.

With the end of summer fast approaching (I may be old-fashioned, but the equinox marks the end of the season), with the occasional leak excepted, the SDK is still nowhere in sight.

Apparently aware that time is running out, Microsoft has at long last spoken. Next week, the company will release a beta SDK... to a few people. Calling it a limited "Preview" release, some number of developers with existing, published Windows Phone 7 applications will be able to use the new SDK. This is in addition to an existing private beta program already running, that's giving OEMs and special software partners access to the software.

A full SDK will come, but not until the company properly unveils the operating system—which is currently rumored to happen on October 29th. Presuming Windows Phone 8 devices ship this year—and Microsoft is certainly talking as if they will—that leaves developers little time to update their applications and get ready for the new platform.

Needless to say, developers are unhappy. They had months of SDK access prior to Windows Phone's initial release. The same was true of the major Mango update; Microsoft gave developers beta firmware, so that they could test it on real devices, and an updated SDK months before the software was actually delivered. iPhone developers similarly have ample access to new SDKs and firmwares; the iOS 6 SDK was first made available on June 11th. With iPhone 5 likely to materialize next week, that will be three months of SDK access to prepare for the new platform. This compares to a handful of weeks for Windows Phone 8 developers.

And getting that SDK is important, given just how disruptive it's going to be. The development model on Windows Phone 7 was pretty straightforward; normal programs used C# and XAML (Microsoft's language for developing user interfaces), 3D programs used C# and XNA (Microsoft's cross-platform 3D API built on top of Direct3D), and, with the release of Windows Phone 7.5, programs that needed both could mix and match both.

Windows Phone 8 is more complicated. Although it will continue to run Windows Phone 7 applications as is (whether XAML, XNA, or both), any applications that use new, Windows Phone 8-specific features, will have to fit a new development model. 3D programming will have to be C++, using Direct3D directly. XAML programs will continue to use C#. Mixing 3D with XAML will be possible, but will require a mix of C# for the XAML parts and C++ for the 3D parts. Certain Windows 8 APIs will also be available to new programs, with a mix of both C++-accessible Win32 APIs, and C++ and C#-accessible WinRT APIs.

Among other things, this means that any developer wanting to add new Windows Phone 8 support to an existing Windows Phone 7 program will have to rewrite all the 3D parts from scratch. That's a big deal.

Talking to some of those who have been using the beta SDKs, the reason becomes clear. The documentation is still very incomplete, and the platform as a whole still has more than its fair share of bugs. The software just isn't ready. It won't be ready next week, either, which is probably why Microsoft is limiting its distribution: in controlling who can use the SDK, Redmond can control who looks at the new features and who talks about the state of the SDK.

This all paints a troubling picture for Windows Phone 8. Microsoft's position in the smartphone market is tenuous, Nokia's is downright perilous, and a strong Windows Phone 8 release is the bare minimum needed to have a chance of turning that around.

As for what's making it take so long, it's hard to be certain, but we can speculate. None of end-user features—either officially announced, in June, or leaked via SDK emulators or other means—do much to justify the delays. The features are certainly desirable and valuable platform additions, but they don't appear to be especially complex or at any real risk of delaying the platform.

This would tend to point the finger at the architectural work Microsoft is performing. The switch to the NT kernel, along with the new mishmash of an API, with its mix of programming language requirements, was in all likelihood a major undertaking, as was ensuring that the NT kernel fulfilled the power and memory efficiency demands placed on a smartphone operating system. There was also plenty of ancillary work: the new Windows Phone 8 emulator, used for testing and development, requires the use of Hyper-V and Windows 8 (and as a result requires a processor that supports SLAT). The old emulator, meanwhile, had much less specific hardware demands, due to its use of Virtual PC as the underlying virtualization technology.

This work does have some value for developers, especially those wanting to use Direct3D, but it is not a pure win even for them—the inability to use XNA and new features in the same application is a bitter pill to swallow.

Whatever the cause of the delays—whether they're because Microsoft has bitten off more than it can chew with the kernel transition, or due to some other reason—the situation is now growing critical. It's not just that it's annoying developers; the delays are undoubtedly hurting Redmond's hardware partners. They need to be delivering the important information like prices and dates, and they need to be putting phones into the hands of press and public alike, without the fear that they'll see something they're not supposed to.