Sep 26, 2012 12:11 pm by Kip Kniskern | 20 comments
Microsoft has been taking a very interesting route in launching Windows Phone 8, locking down the SDK and refusing to allow journalists to play with the new interface, something that has been common in the past. It’s becoming more clear that Microsoft’s reasoning for locking down the SDK, so that new unannounced features wouldn’t be revealed, doesn’t seem to be holding much water. Recently, in an editorial, one Windows Phone enthusiast and blogger, “Sheeds” from WPDownUnder.com, is postulating that backwards “app-compat” may be a reason for the secrecy, and the delay in getting the OS out in public.
Sheeds noticed a change in tone from Microsoft’s initial statements on compatibility. Microsoft first announced Windows Phone 8 in June, and even before that, in April, Microsoft said that Windows Phone 7 apps would run in Windows Phone 8 (emphasis in original):
With regard to existing applications: today’s Windows Phone applications and games will run on the next major version of Windows Phone. Driving application compatibility is a function of Microsoft’s commitment to its developers. Regardless of what we release in terms of new developer features and functionality, we have made a large investment in protecting your existing investments.
But as Sheeds notes, the messaging isn’t quite so confident as we get closer to launch. On September 7th, on the Windows Phone Developer blog, Andrew Whitechapel wrote a whole long blog post answering the question “How do you ensure that an app built for an earlier release of Windows Phone continues to work great on Windows Phone 8?”:
Even though almost everything is different, our app platform maintains a high degree of backward compatibility. So, from the perspective of the platform APIs, you generally don’t have to do anything – your app should just continue to work, without any changes. Where this becomes a little less cut-and-dried is if you’re doing anything unusual or unsupported in your app (more below).
Then, in the nomination form for gaining early entry into the Windows Phone 8 program, Sheeds points out further indications that all may not be well in migrating Windows Phone 7 apps to Windows Phone 8:
‘Do you agree to download the WP SDK 8.0 Preview and to promptly test your WP7 application’ and ‘Do you agree to promptly report any issues you find while running your WP7 application on WP8?’ The NDA questions follow immediately after this.
… and notes that in a podcast, Windows Phone Product Manager Cliff Simpkins again brings up app compat:
WP8 was designed to run all WP7 Apps…and where we saw that Apps that were designed for 7 could use some tweaking, whether there was performance [issues] or you know [starts to say compatibility then moves to] App and binary code compatibility might go a little bit wonky in some cases – but you get that with any release.
Sheeds goes on to say:
Regardless of how or why code may need to be “fixed” or “optimised” one thing appears certain – and that is that it the reality of the situation right now, 6 weeks from an unofficial WP8 launch, is that Developers may not be where Microsoft had hoped back in June of 2012, with “…..existing apps [to] launch and run faster on Windows Phone 8 without changing a single line of code.”
Certainly something seems to be holding up the process. Even if it is all just grandstanding to gain “buzz” for the launch, does that even make sense when the cost involves pissing developers off and delaying a new stream of Windows Phone 8 apps? It might be something just short of a miracle if all Windows Phone 7 apps worked flawlessly with Windows Phone 8, but yet that’s pretty much what Microsoft promised. That they’re working hard to come close to that goal is commendable, but is it holding up getting the SDK out in public?