From a developer's viewpoint, the main selling point of Windows 10 is its new Universal* Windows Platform (UWP).

* Where "Universal" really means "universal to all devices that run Windows 10", and not "universal to devices that run not only Windows 10, but also Windows 8.1 and maybe Windows 7". So if you're building a UWP app, you're really just building a "Windows 10 app". UWP apps will not run even on Windows 8.1 and Windows Phone 8.1 devices, i.e. they're not backward-compatible at all.

As of Q3 2015, Windows 10 is available for PCs and IoT devices. It'll be at least another few months before Windows 10 Mobile is released to the public, but probably no more than a year. This means that Windows Phone 8.1 will remain around for a while yet.


I'm about to start developing a Windows Phone app, and I plan to publish it within the next month or so as it's a fairly simple app. Since Windows 10 Mobile won't be arriving anytime soon, let alone devices the world over getting upgraded, I have to target Windows Phone 8.1 for now. However, since it won't be that long before Windows 10 Mobile rolls out, I'm wondering if it'd be wise to prepare my solution for deployment to Windows 10 UWP as well as Windows Phone 8.1 (which will also allow me to continue supporting 8.1 for as long as I need).

I see that I can group a UWP project and an 8.1 project in the same solution, and share source files and assets via a Shared project as done with the Windows 8.1 Universal template in Visual Studio. Am I on the right track? If so, are there any additional guidelines I should follow to ensure everything (including XAML, as ideally I'd like to have the same or at least similar UI on both platforms) actually works correctly on both platforms accounting for any incongruities?

Alternatively, I could just not worry about Windows 10 Mobile for now and start with an 8.1 project, and migrate it to UWP later on, but I'd still have to maintain both versions of my app since I don't plan on ditching 8.1 users immediately. I'd still have to worry about feature/XAML parity in this case.

  • 3
    Just as an update, I went ahead and created a solution consisting of a Shared project, a UWP project and a WP8.1 project. I'll detail it in an answer later once I'm sure I know what I'm doing...
    – BoltClock
    Aug 19, 2015 at 5:41
  • Any updates you want to share about your discoveries on this particular subject? I'm really interested in knowing how is this approach working for you. Nov 10, 2015 at 8:48
  • 3
    @Nelson Reis: I'm working on shipping my app for WP8.1 (which is great!), so I haven't begun work on the UWP app yet. But I will soon. So far, things are working pretty well on the WP8.1 side.
    – BoltClock
    Nov 10, 2015 at 10:16
  • I am just interested in the update. How did the development of WP8.1 and UWP go? (I have less then 50 points, so I cannot comment) The reason for this is that I am starting to develop a cross-platform app, and I am currently deciding what technologies to use. (programmers.stackexchange.com/questions/314850/…)
    – makons
    Apr 5, 2016 at 22:52
  • 2
    Hey there, I'm sorry this is taking so long. Development on my UWP app has been coming along so I'll have something to share within the next couple of weeks.
    – BoltClock
    Apr 6, 2016 at 5:16

3 Answers 3


As you say in one of your comments the best way to go about this is by using a shared project and adding several heads to it. In your case a windows phone 8.1 head and a uwp head. This position was also expressed in an MVA by Jerry Nixon and Andy Wigley (I think this is it, but it has been updated since), in the section about porting 8.1 apps to uwp.

In your shared project you may have to use conditional compilation directives to differentiate between code that runs in uwp and phone 8.1. (Like when creating universal windows 8.1/phone 8.1 apps)


Depending on how Windows feature specific your app needs to be, you could go with a platform like Xamarin which would allow you to write not only for Windows, but also iOS and Android in the same codebase.


As from my experience: it's worth to place some helpers/logic/etc into PCL libraries. Then you can create two projects (for UWP and WP8 respectively) that can utilize PCL with zero changes. Also, you can share services, view models and models (with very few #if conditional compilation lines).

The only thing that is NOT worth to share is UI-related staff as too many things have to be switched/conditioned (so it's much easier to prepare separate layouts for each of the UWP and WP8 even if they're practically the same).

P.S. I did that for UWP and WP8.1 Silverlight

Not the answer you're looking for? Browse other questions tagged or ask your own question.