A deeper dive into the Universal Windows Platform

Hello from day 2 of Build 2015 in San Francisco. David Treadwell and I just gave the audience a peek at many of the new capabilities the new Universal Window Platform will enable, along with the associated tools and services. We also provided more insight into the Universal Windows Platform Bridges announced by Terry Myerson on day 1. If you haven’t already, I recommend taking a look at David’s blog that provides more insight into the announcements from day 1 and what they mean for the community.

While we highlighted four bridges today, these are not the only paths to building great experiences on the Universal Windows platform. Windows is about choice and enablement and these are just the latest installments of this developer promise.

Before I share with you details on the Windows 10 platform enhancements, I want to emphasize that the Universal Windows Platform is just an evolution of the same modern platform you’ve been using on phones since Windows Phone 8.1 and PCs since Windows 8. This means your code and your apps just WORK. You can continue to write apps for the Windows platform in your language and using the framework of your choice, whether that’s C/C++, C#, Visual Basic, JavaScript, XAML or Silverlight. With the addition of bridges, you now have a starting point on your journey to build a Windows app that can be submitted to the Windows Store. You can reuse significant portions of your existing code with minimal effort and then focus your time enhancing your app experience with the unique features of Windows 10.

Now I want to take a moment here to share a few Universal Windows Platform highlights with you.

DesignThe UX of the Universal Windows Platform is designed to work great across the Microsoft device family. There’s now one design language and one control set across devices. That means predictable, consistent building blocks for you to create your experience, however you choose to adapt and tailor it per device. To learn more about our design principles and how we are applying them to our “in-box apps,” check out our Windows Head of Design, Albert Shum’s blog post on the topic.

We recognize that developers using the native controls and layouts will build complex views and many times those views need to adapt based on device family. Similar to what developers are accustomed to on the web today, we’ve found that responsive design techniques are a great way to adapt an app to a diverse device family. Since we expect many developers to use responsive techniques, we’ve added a set of features to the platform to make it easier for developers to build a responsive view (e.g. visual triggers, relative panel).

The one design language and control set make it easier to adapt your app experience for common scenarios. Things every app designer needs to handle – like window size and input type – are often handled by the platform for you. For example, menus appear with mouse-optimized or touch-optimized presentation depending on how they are invoked by the user… but you can write the code just once. Controls work across all screen sizes with mouse, touch, keyboard, pen, and now even a game controller… right out of the box.

In cases where the designer wants even more control over how the UX adapts, we have added two new features – RelativePanel and Adaptive Triggers. Together, these can be used to create simple rules that automatically trigger visual state changes in response to an app event such as a window size change… all in markup.

Adaptive Triggers can also be extended to create Custom Triggers for more complex scenarios. For example, developers can create a control size trigger that could be used to trigger UI changes for the control based on its height and/or width.

Beyond just size, you can tailor based on input, orientation, availability of sensors, app services, or pretty much any other change you can detect. You can even create a totally custom XAML view for each device, all sharing common code.

DevelopWindows 10 makes it easier to develop apps for the Universal Windows Platform with just one API and one package to reach all Windows 10 devices – PC, tablet, phone and more.

We added over 2,500 new classes to the Universal Windows Platform API set for a total of over 8,600 new APIs, a 60% increase from Windows 8.1. With Windows 10 we also increased the .NET API set by 26% and the Win32 and COMs API set by 48%. There are tons of NEW things that the Universal Windows Platform supports, with new capabilities including DirectX12, Holographic, Active Pen and Windows Hello.

Universal Windows App ModelWhen writing an app for Windows it is easy to concentrate on which APIs you can call or how the app UI should adapt. These are all vital to writing an app but it is important to think about what defines what an app can or cannot do. Historically there has never been a concrete definition of what an app is on Windows. It started with an .exe but you have to consider things like:

How do you install it?

How do you store state?

How long does the app run for?

What’s the versioning story?

How do you integrate with the OS?

How do you integrate with other apps?

What can your app do?

The Universal Windows App Model provides a system that answers these question and does so in a way that scales from the smallest IoT device to the highest-end PC.

The Universal Windows App Model begins (and ends) with the deployment system, AppX, which provides a trustworthy installation mechanism that is designed to ensure apps can be deployed and updated seamlessly. In Windows 10 we have enabled AppX to support all of the Windows Platform devices and also extended it to support the increased demands of today’s app ecosystem. Apps on devices such as Xbox and PC are increasingly delivering significant amounts of content and code resulting in very large app downloads. AppX for Windows 10 now supports packages in excess of 150Gb. On the other end of the spectrum, AppX also supports installation onto removable storage (such as SD cards) to enable devices with limited built-in storage to install more apps.

The Universal Windows App Model is designed to provide a scalable execution environment to enable your app to do amazing things across a family of devices. The app model scales to take into account memory size and battery life by providing a resource management system that will allow your app to use the appropriate amount of memory & CPU based on the system that you are running on.

While apps started out in silos, increasingly users want more integrated experiences. We listened and designed a system that allows your apps to integrate not only with the operating system but also with other apps. We looked at what made the web great: URL-based activation. We built on this concept to enable apps to integrate using custom schemes, introducing the ability to get a return result from the app you just called. This enables apps running in the foreground to launch apps that will also run in the foreground. But what about seamless background integration? As I demoed today, we are also introducing app services which allow you to publish a task which other apps can call in the background, so that the calling app can remain in focus.

Universal Windows Platform Bridge for Classic Windows ApplicationsWindows has a huge ecosystem of Win32, WPF and .NET apps spanning from productivity to the most amazing games. Today we talked about a bridge which will allow an existing Classic Windows application to be converted to a Universal Windows app and made available in the Windows Store, Project Centennial. These apps will not only have the same install and update user experience that the Store provides today, they will also be able to call the vast majority of the Universal Windows Platform APIs and new platform capabilities like Action Center, Actionable Notifications, and enhanced Live Tiles.

We also want to make sure that customers feel confident installing these apps from the Store and that they will not cause their device to slow down or introduce malware or other issues. If customers don’t like the app, then they can simply uninstall it and Windows ensures that the app is completely cleaned up. We achieve this by isolating registry and app data access for the app. So when your app thinks it is writing to the registry, it’s actually being stored in a per app hive, which can be easily removed. This is all done without you having to make major changes to your code. Just convert your existing installer into AppX using our tools, available later this year.

Universal Windows Platform Bridge for Web AppsFinally, I’d like to go into a little depth about hosted web apps, a Universal Windows Platform scenario allowing developers to leverage the power of existing web workflows and continuous deployment in order publish a responsive web app to the Windows Store. Developers may start with a preexisting web site URL, place it in a manifest and create an app targeting the Universal Windows Platform.

Full access to the platform is possible including calling APIs directly from scripts hosted on a server, leveraging Cortana integration and authentication. Hybrid apps are also supported as developers can include local code to be called from the hosted script in the app package and manage app navigation from remote to local pages. For support of Universal Windows Platform API access from a hosted application, the AppX manifest is required where there are two things that need to be set: the application’s desired start page URL and a set of desired URLs that are part of the app.

Web developers are able to directly call platform APIs through JavaScript hosted on their server when their hosted content is running as an application on Windows. To enable this an attribute (WindowsRuntimeAccess=”<level>”) needs to be specified in the ACURs.

Join the conversation

Hi Kevin, could you (or anyone) answer this question from a CONSUMER point of view:

1) Can a new “UWA” (what many are calling “Windows 10 apps”) run on a Windows 8.1 PC or Windows Phone 8.1 device?
2) Further, can they run on Windows RT (all those Surface devices out there), or are they all paperweights now along with Windows Phone 8.1 devices that carriers won’t update to Windows 10? Basically is ARM on any device (tablet or phone) dead for Modern apps in the stores?
3) Can developers lock down their apps to “Windows 10” devices only, or is that not a concern since they should work with Windows 8.1 also. For example, a developer adds in new “Windows 10” features….will that app still work in Windows/Windows Phone 8.1 but just not have those additional features?

Or is everyone out of luck, and the store of 500,000 apps goes abandoned? Reading your blog post, this doesn’t seem the case, and reinforced my belief that a Modern app is a Modern app and not “Windows” specific. Just now with “UWA”, these “Windows Apps” can now have one single code base, instead of a “Universal App” from Windows 8.1 days. However, you quickly say that developers can then incorporate new Windows 10 features into their apps. Let’s say they do so…does that “optimized for Windows 10” UWA now become unusable in Windows/Windows Phone 8.1?

I’m asking this question because I’ve asked my developers (some large) of apps I love about their Windows/Windows Phone apps. They have said “we will discontinue our Windows 8 app” and only focus on “Windows 10”. Further they say that “Windows 10 apps won’t be compatible with Windows 8”. Either they are just not informed about what a Modern app is, or they have more information than the rest of us. Which is it? There is even a new article about the U.S. banking apps that left, and the evangelist over at Microsoft says he is in touch with the banks and they removed their Windows Phone 8 apps because they want to focus on “Windows 10” apps. Bottom line: is everyone confused on what’s going on? Looks like it. If their Windows Phone 8 apps would work in Windows 10…sounds like that was an unnecessary move. Unless a UWA has something super special that breaks this.

I’ve never seen Microsoft make things not backwards compatible. Heck, I’m using an old app from 1999 on my Windows 8.1 PC and it works perfectly. So this would be a shock if that half a billion app Windows store is now gone overnight in the hopes that everyone will make “Windows 10 apps”.

Sorry for the long post, but nobody is telling the consumers what’s up (and nobody at Microsoft seems to be talking about this). Thank you for helping to clear the air on if we are all suddenly abandoned, or if developers are not understanding that

UWA apps may, and I would dare to say should, be Windows 10 and above only. Everyone can upgrade to Windows 10, except very few miserable Windows RT users. This will not break backward compatibility since Windows 10 will continue to run old Win 32 apps with all their benefits, namely, security nightmare, system degradation, and uninstall problems.

UWP answers the main question: Why should I bother with that which nobody uses? No wonder your developers go Windows 10 – it is the first chance in 20 years to make the experience of their users better. A no brainer even if Windows RT users are dumped.

Hi Andrey. Respectfully, I think you missed what I was trying to communicate. The developers are saying they are not making a Windows 10 “x86” app, but a Windows Store app (now called “Windows apps”). The Windows Store….regardless if it is Windows Phone or Windows…has apps built on the “Modern” app platform. Meaning, they are not “x86” style desktop apps, but apps built on lots of modern tech (and some old ones) like XAML, JS, C+, C++, etc.

Thus, a Modern app (Windows app) should work in ANY version of Windows 8, 8.1, or 10 regardless of processor type. Windows RT is a great example of this as it can only run Modern apps since it is on an ARM platform. Windows Phone is also another great example as it is NOT an x86 processor computer, and runs Modern apps (thus, basically, Windows RT and Windows Phone are one in the same in this example). So, you focused only on Windows RT in your reply…but millions of Windows Phone users are also in this mix (80+ million) who can’t upgrade if their cellular phone carrier won’t let them (and that’s going to be the case for lots of people).

But this should all be meaningless based on this blog post….if “Windows 10 apps” (remember, NOT an x86 app…but a Windows store app) are built on the same Modern app infrastructure as Windows 8/8.1/RT8.1 and Windows Phone 8/8.1, then why can’t they run on Windows 10? That’s not really answered here for the normal consumer. Further, developers are often *assuming* that a UWA won’t run on any 8/8.1/RT8.1 device. I don’t believe that to be the case, and am asking for clarification.

UWP is a way for a single code base to be responsive based on the device size (etc). That, as this blog post shows, shouldn’t impact any other devices with an 8[.x] operating system. But that needs to be said, or said it will not work.

It would also be insane for Microsoft to *not* allow any UWP (which are just basically, once again, Modern Windows apps that have a single code base, instead of a dev having to…with the same type of programming code…upload two different packages based on device size) to run on 8[.x]. That would mean that over 380 MILLION people won’t be able to use them.

So, to respond to your main question rhetorically: why should any developer bother to build UWP apps when nobody even has Windows 10 at this point, and further why even build them at all when those with phones…which of many cannot be updated to Windows 10 but can still run Modern apps. The whole purpose of UWA’s is for both PC, tablet, and phone. If you can’t target phones…why even bother (tablets are akin to PC’s anyways, so that’s a “meh” for developers as we have seen with tablets in general beyond Microsoft’s ecosystem).

Still awaiting an official Microsoft response from Kevin Gallo: can any 8[.x] device also run UWA’s to include phones and Windows RT? The answer should be yes based on this blog post.

Imagine it another way for Modern Windows apps (Windows Store apps, and NOT older style x86 applications): if it is locked down to Windows 10 only, then will ever version of Windows need “new” apps made and you must upgrade to that? (crazy) Would any of the apps you BOUGHT now be worthless and you need to buy new ones for each new version of Windows that comes out? (disastrous)

What kind of store will Microsoft have if they keep making apps dependent on the operating system version? You rarely, if ever, see this with Google or Apple. I can still use an app I got on my iPhone 3 with my iPhone 6 (the app hasn’t been updated in years…no retina graphics, old style UI, but it works perfectly). Thus, why would Microsoft suddenly not allow this?

Modern Windows apps (to include “UWA”) are built on C/C++, NET languages, JavaScript and HTML5. All of that works in Windows RT, Windows Phone, and x86 traditional PC’s. There is no reason Windows 10 can’t support that unless Microsoft is purposely doing some restrictions.

An app built for Win 8.x will continue to run on Win 8.x and will also run unchanged on Windows 10 for the device it was written for (phone, desktop, tablet or Xbox). Thus, our existing catalogue of Win 8.x apps to still work as expected on Windows 10. Developers can chose to build a Universal Windows 10 app to take advantage of the many new features and APIs available on the Universal Windows 10 Platform. Such a Universal Windows 10 App will not be able to run on Win 8.x.

Thank you for the reply Kevin. Can Microsoft please just release an update to Windows RT…and we are all fine with not getting “full” Windows 10…so we can at least run these Windows Store Apps? If mobile devices (such as phones) are not even running x86 processors and can still run these apps…why not just release that feature as well to Windows RT devices?

I think Microsoft has suddenly forgotten that for many years the majority of downloads from the Windows Store was made by Windows RT 8/8.1 users, with almost none by Windows 8/8.1 users. We also all have very expensive devices sold by Microsoft (Surface RT, Surface 2) and Nokia (Lumia 2520).

As much as you’d like to not look back at Windows RT…we are customers, loyal, who believed in your “experiment” and now left with pricey paperweights come later this year. But, that could all be very easily fixed if you just allow that tweak to allow us to run universal apps on our tablets as well. If you can do it for phones, why not WinRT?

Show that Microsoft supports those who supported them when they asked us to.

I strongly believe Microsoft will not make Windows 10 apps compatible Windows RT. Remember when Windows Phone 7.8 did not support Windows Phone 8 apps? The update that Microsoft is going to release for Windows RT is going to be something like Windows Phone 7.8 . This is Microsoft, who keeps on screwing their customers who supported them.

During Build 2015, it was mentioned that Android apps can be easily ported to Windows 10 Phones. Can Android apps also be ported to Windows PC in the same way? If not, I won’t upgade my PC to Windows 10 and I will be sticking with Windows 7.

That’s what they were showing at BUILD….to make “Windows [Store] apps” from an Android or iOS code base. Windows 7 can only run traditional “x86” desktop apps (which most developers don’t make anymore except for business users) and can’t run any Windows store apps, which only 8, 8.1, and now 10 (and above when that comes) can access through the Store.

Side note: Windows 8 and 8.1 are built from the same Windows 7 code, but made bloat free. Too many people focus heavily on the Start Screen for W8, but it’s exactly the same at 7 minus the bloat (my old Win 7 computer became super fast with Win 8). So, Windows 10 will be like 7 in many ways and is a worthwhile (and free for the first year) upgrade. Win 7 will be out of support period in the next couple of years.

What I am asking is, will Windows 10 PC support those ported Android apps, or are they just for Windows 10 Phones? It does not make sense when it is ‘Universal Windows Platform’ but Microsoft keeps saying that Android apps can be ported to ‘Windows 10 Phones’ during Build. What is the point of upgrading my PC to Windows 10 if it cannot run those ported Android apps?

That’s an excellent question. Right, they said during BUILD that they are adding in the layers for iOS/Android ported apps. I don’t recall hearing anything about the non-phone version though. Although, Windows 10 is device agnostic (according to Microsoft), as there is no more “Windows Phone”, the underlying code base is supposed to be the same. Thus, it should work.

Beyond that, if that’s the only reason you won’t upgrade from 7 to 10 please reconsider. I remember being hesitant about upgrading from 7 to 8 because of what I heard on the internet. Largely unfounded as my slow Win7 computer was fantastic under 8. Remember it IS the Win7 code that is less bloated and cleaned up…you can still run everything the same. Windows 10 is free the first year…so, why not upgrade?? Windows 7 just seems like it’s all that, but the newer version(s) of Windows have much better code in them and features (especially for power users).

I already found the answer for my question elsewhere on the internet: the ported Android apps will only run on Windows 10 Mobile but not Windows 10 PC because only Windows 10 Mobile contains the Android runtime. This shows that the so called “Universal” Windows Platform is just a lie. But it does not matter anymore now, because soon I will be trading in my Windows laptop for a new Chromebook. Google Chrome OS now supports running Android apps natively. I will never use Windows 10!

This seems like a nice evolution of the Windows Store packaging system that surfaced with Windows Phone 7 and Windows 8, but I’ve got a fairly straightforward question.

I want to be able to sell my applications where my customers are at. My customers aren’t necessarily in the Windows Store. For example, if you want to sell a video game on the PC, nowadays, you sell it through Steam, GOG.com, or Humble Bundle.

Can I use AppX where my customers are, or is this only available through the walled garden of the Windows Store?

Code is already being written outside the walled garden. I’m trying to see if the benefits of going AppX/bringing code inside the walled garden outweigh what I give up.

In an ideal world, an AppX package on a file share or a website would be the perfect replacement for XCOPY deployment on Windows 10 and above. Registry hive redirection helps with proper cleanup, etc. It’s a signed envelope saying “I made this and it hasn’t been tampered with.”

However, there are still questions.

Can I just send a customer an AppX package I create without uploading it to the store? Sounds like if I can, they’d have to turn on developer mode to sideload in the package at a minimum. That just adds extra friction to the process.

There’s a lot of new APIs being listed above as Universal Windows Platform APIs. If I don’t opt into the Windows Store experience, am I blocked from using these APIs?

You should be able to use those API’s still…but I’m not the right one to ask about that 😉

However, while this may all be not “very developer friendly” as you’ve mentioned, it’s the world we now live in. Apple and Google both do it, and it’s what consumers expect. They are, rightfully so, scared to download an app outside of a Store due to malware, viruses, and other nasty stuff. Not saying that can’t happen in a Store (e.g., Google Play), but consumers want it to be “friendly” for them, thus a Store.

The idea of having a store is for Microsoft to stop users from downloading and installing “untrusted” applications, so if the app is distributed through the store it’ll have quality and security guarantee. This has been the case since Windows 8.

What you are trying to do seems to be swimming against the tide.

Have you considered wrapping your core code in one place, and have separate iOS/Android/PC/Windows Store projects that all link to your core project?
That way you could develop the main mechanism once, and deploy them to each platform individually.

Considering the Windows Store reaches PC, Phones and XBox, it may be worth creating a separate build for the store, on top of distributing through Steam

Enterprises can distribute their apps outside the Windows Store. We have made this process simpler for them in Windows 10. To support side loading, devices can be unlocked by pushing an MDM policy or through an on-device setting and the device does not require an MSA sign-in (or internet connectivity). Enterprise can sign their apps across Mobile and Desktop with a Symantec certificate or their own enterprise provided certificate. Here’s a great talk if you want to learn more about it: http://channel9.msdn.com/Events/Ignite/2015/BRK3306

I was Attendee of the BUILD and wanted to ask, if you provide the Code, you have shown in several Sessions? Im looking for some good examples for scalable UIs with the RelativePanel, Triggers and some more and of course: Best practices!
Is there a way, to get the Code?

What is the best way to learn this platform at this time? Will it be a waste of time to use a Windows 8 App book? Like let’s say Charles Petzold’s “Programming Windows, 6th Edition: Writing Windows 8 Apps with C# and XAML” (https://www.microsoftpressstore.com/store/programming-windows-9780735671768)? I understand it takes time to come out with resources like this, but in this in between time, where does one start? (Let’s say someone who used to do WPF, so is not lost in XAML, but still it’s been a while). Do most Win 8.1 XAML principles apply in the UWP? I know of course packaging details are going to be quite a bit different, and there are going to be a lot of capabilities that won’t be in it, including of course reflexive layouts. But in addition to XAML, it sounds like you guys were saying there’s been a ton of new underlying capabilities as vendors required them that you guys have brought into the system.