There is a very recent hint that Microsoft might be planning to allow Windows Phone 7 apps to run unmodified on Windows 8. To date Microsoft has focused on encouraging developers to port their Windows Phone apps to Windows 8 by modifying the UI to conform to Windows 8 Metro design guidelines and changing Silverlight .NET Framework API calls to Windows Runtime calls. This is no doubt the preferred way to go as the ideal user interface on a 10.1″ tablet screen is quite different from a 3.7″ phone screen. However, like Android and IOS before it Microsoft may find that many phone developers will take their time creating tablet-specific versions of apps. And with Windows Phone likely to have in excess of 100,000 apps in its Marketplace by the time Windows 8 ships, Microsoft could immediately make Windows 8 more attractive to consumers by allowing those apps to run on Windows 8 tablets. At least that is the conventional wisdom. So recent hints that Windows Phone apps are being tested on Windows 8, despite being in conflict with everything we’ve heard since the BUILD conference, might indicate this is another Shoe Microsoft is planning to drop.
Allowing Windows Phone apps to run on Windows 8 is trivial from an engineering standpoint. Windows Phone apps are simply Silverlight .NET apps that use a few Windows Phone-specific libraries. The former already work on Windows, the latter could be ported to Windows by an Intern. The real work is in having the Windows Store make them available, support installation of Windows Phone 7 packages on Windows 8, etc. To be honest I’d always expected Microsoft to support Windows Phone 7 apps on Windows 8, and was rather surprised when they didn’t announce this at BUILD.
Despite Microsoft’s desire to have a pure Metro/WinRT world, and put everything else in the Desktop legacy category, there are exceptions. Building an alternate browser? Microsoft will let you break the rules and create a Metro browser that uses more than just the WinRT APIs. Basically this is a compromise that maintains the status quo around browsers from its antitrust settlements. Office 15 is a hybrid as well. Making an exception to Metro/WinRT for Windows Phone apps wouldn’t be setting a new precedent. So why not do it?
There are two reasons I can see for not supporting Windows Phone 7 apps on Windows 8. The first is not wanting to bring a legacy to Windows 8 that won’t be of that much benefit to users. Take a key difference between Microsoft’s situation and Apple’s. When Apple introduced the iPad the iPhone was already a run-away success. So when a customer bought an iPad they already knew they wanted to run “Kissing Toadstools” and most of their other favorite iPhone apps on it. Windows Phone won’t have enough penetration at Windows 8 RTM for this dynamic to really play out. Microsoft can work to make sure the most popular Windows Phone apps have native Windows 8 versions at or near launch, and the “long tail” of other Windows Phone apps isn’t going to drive sales or customer satifaction the way it did for Apple.
But the second reason Microsoft might not want to allow Windows Phone apps to run on Windows 8 is the Android experience. Android tablets had, and still have, very few native applications. Nearly the entire application library consists of Android phone apps that you run on the tablet. Basically Android has allowed the chicken and egg question to live on way too long, with software developers waiting for Android tablets to take off before they create tablet-specific versions of their apps. And one of the reasons the tablets haven’t taken off (Kindle Fire aside) is that there are so few tablet apps for them. By not giving developers the easy out of running their Windows Phone apps on Windows 8 Microsoft would hope to break the cycle and force developers to create Windows 8 apps if they want to play in that world at all. It is a gamble with lots of upside and little downside risk.
There is one more possibility that I think really tells the story. When Microsoft announces the Windows Phone 8 SDK they will announce a way to write apps that can run on both Windows Phone 8 and Windows 8. While existing Windows Phone 7 apps will run on Windows Phone 8, developers are likely to move quickly to port their apps to this new standard in order to have a great Windows Phone 8 version available at or near RTM. Thus they will simultaneously make their app available to (if still not tuned specifically for) Windows 8 tablets. This is the Shoe I really expect Microsoft to drop.
So, will existing Windows Phone 7 apps be supported on Windows 8? The jury is still out. At this point I think it would be more marketing stunt (“Windows Store has more than 100,000 apps at launch”) than of practical benefit. But for users the value is low, so skipping support of Windows Phone 7 apps isn’t much of a lost opportunity.
Hal's (Im)Perfect Vision 
What about all the developers who bought into building an app for Phone 7? The platform really hasn’t penetrated the market enough for them to get payback on their investment in time and energy. It would seem Microsoft has a vested interest in giving them a boost. And by the bye from what I’ve seen of Android tablets a Windows 8 tablet is going to be hard pressed to compete.
Developers won’t get back their Windows Phone 7 investment by having their app run unchanged, and thus sub-par, on Windows 8. The best thing Microsoft can do to support developers who invested in Windows Phone is to make Windows Phone succeed!
Another difficulty that I think most people haven’t quite grasped is that UI conventions on WP7 and Win8, despite sharing a similar visual aesthetic, are actually rather different. The most obvious problem is that WP7 apps are heavily dependent on the universal hardware Back button, which doesn’t exist on Win8 (there is a system Back gesture which goes back to the last app, but not back within an app); there are other problems like the two-dimensional navigation used by phone apps (Pivots and Panoramas) being both incompatible with the Win8 touch language (swipe-to-select and drag-and-drop) and not working well with mouse.
Of course there are ways around these problems, but in a situation where people are already worried about the coexistence of the desktop and Metro style apps being somewhat awkward and confusing, this would add still more awkwardness and confusion.
It’s interesting to ponder on this, I would have hoped there would be more of an official statement on this by now. I guess talk of WP8 has been blocked until at least the Lumia 900 launch has passed.
Anyway, if you connect the dots you can assume that WP7 apps will work on Win8:
Microsoft have said that Windows Phone 7 apps will work on WP8.
The leak about Win8 has almost officially confirm that WP8 will use WinRT under the hood. This will bring much needed HTML based apps and alignment with Win8.
Given the above, we can assume that there’s a bridge between current WP7.5 Silverlight apps and WinRT. This will include porting the common controls over to WinRT – at least for the .NET side.
If WinRT is going to be the new API for WP8, then it doesn’t take much to imagine support for a unified application model and single binary. Maybe even a single app store with one submission process.
It’s true there are hardware differences, but there are rumors that these differences will disappear for the next gen phones (new chassis specs removing the need for buttons and replacing them with gestures like the new Nokia N9). At least, for Silverlight, the different screen resolutions are less of a problem. Definitely less of an issue compared to Apple, which uses a more bitmap approach.
Talk about WP8 appears to have been blocked by a desire to not give Google and Apple as much time between the reveal and shipment to clone new WP8 features. Microsoft would like at least a few months to market the exclusivity of new ideas before they are copied!
From a technical standpoint the relationship between the existing WP7 app model and a new WinRT app model doesn’t require a “bridge”. WP8 will continue to support Win32 as well as WinRT and thus the stacks just live side-by-side. You are right that they will need to have a third copy of all the controls (currently they have both native and Silverlight versions).
But is Win32 still the common layer underneath? From what I understand, WinRT is the lowest layer for some calls. I guess I was thinking that Silverlight WP7 Phone Apps would be enabled purely in the managed stack, rather than two parallel stacks. This would give these WP7 applications the ability to start consuming WinRT APIs gradually rather than an all or nothing proposition.
They are side by side.
If I were a product manager for an ISV with Windows applications, I’m faced with needing to rewrite my company’s applications to support aspects of Windows 8. If I have to invest in that, I’d want to do it in a way that gives me non-Windows options, ideally so my applications can run on iOS and Android as well. If enough people start thinking like this, technology will appear to satisfy this need.
Three levels of “if” – but technologies that enable .Net and C# apps to run on iOS and Android exist today.
Now to see if the dots connect…
How many serious apps use those technologies?
I’m not sure what you mean by serious. Are you familiar with Mono from Xamarin?