If you’ve ever developed an application for Windows 8 and Windows RT, you enjoyed a development experience that was seamless across a range of device types, from ARM tablets to x86 tablets to desktop PCs. You didn’t have two projects for ARM and x86, or between tablets and desktop PCs. You write one application, with one project file, one binary per cpu type, and one code base written against a single API. There were no “shared code” projects or #ifdefs or platform-specific code paths – your application just runs everywhere, responsive to the screen size, pixel density, and snap state that its being run in.
But Windows Phone never played well in this ecosystem. Back in the Windows Phone 7 days, we were stuck with multiple solutions or multiple projects in a solution, and shared code had to be linked in both projects from the same location on disk, with #ifdefs surrounding platform specific code (of which there was plenty).
It was such a hassle and so difficult to get right that I didn’t even bother with my Windows Phone 7/Windows 8 application Telnet. Much of the code was shared between the WinRT and WP7 applications, but any changes in one I just manually merged into the other using a code diff tool (WinMerge, if you’re curious). Believe it or not, that was faster, easier, and less prone to error than trying to actually share code files between the two apps.
Then came Windows Phone 8, the Windows Phone Runtime API, and Universal Apps. These were a big step in the right direction, reducing (but not eliminating) the biggest obstacle to shared code: two very different sets of APIs and UI stacks. However, Universal Apps are still nowhere near as good an experience as developing an application cross-platform between Windows RT and Windows 8. And, fundamentally, it’s still the same two-project solution we had before. All we’ve done is moved the shared code and resources into a separate ‘shared code’ project. I’m not even convinced that’s an improvement over just including shared code directly in each project – at least then I can see all the files that go into the project in one project tree.
As an experienced web developer, I’ve been writing responsive web applications for years with frameworks like Bootstrap and custom CSS and JS based frameworks before that. One thing that experience has taught me is that it really shouldn’t be that difficult to write responsive applications that can scale from phone all the way to retina displays, WITH the right tools and frameworks.
Which is why I have to ask: why is it necessary for Windows Phone and Windows 8/10 to have their own projects, their own application binaries, their own slightly different sets of APIs? Why on earth do I need so much ceremony to create a less-than-5MB craft organizer application that runs on windows 8 and windows phone, and just adapts the UI to the phone or the tablet? I’m already writing the windows 8 app to be responsive to different snapped states, different screen sizes and pixel densities. In Windows 10 I’ll need it to be responsive to any number of window sizes when the app is running on a desktop PC. What is Windows Phone but just ONE more context I need to support?
And there’s another, VERY compelling reason why we should get rid of separate apps for windows phone and windows for tablets and desktops. What if you could take any Windows 10 phone, phablet, or tablet, plug it into a dock on your desktop (or connect it via miracast or mini-hdmi), and run all your Windows Store apps in desktop mode – including, the touch-friendly Office applications? Even in Windows 10, this would not be possible, because the way Universal Apps work today forces them to be two physically different applications. It doesn’t have to be this way. “Responsive” universal apps could just switch to desktop mode and back depending on whether you have it docked, just like any other hybrid device.
Low-end devices might not support the desktop mode, even if docked and connected to a desktop monitor, but might still run universal apps full-screen like they do when you enable tablet mode on a desktop PC. And games, which might have an SD and HD set of resources, could download the right set of resources after install (or bundle the SD versions and ask to optionally download the HD versions), possibly after asking the user which they’d prefer given their device’s storage limitations.