Discussion: Windows App SDK 1.0 Additional Windows form factors

[anup-das]

Discussion: Windows App SDK 1.0 Additional Windows form factors

Is this not same as WinUI 3 for UWP ? If not then does this imply that we would be able to target XBOX for e.g. with Win32 apps ?

Related Links

[StephenLPeters]

@MikeHillberg FYI

[shaheedmalik]

UWP doesn't support WinUI 3 yet.

[pjmlp]

@anup-das I guess the way forward is to deal with C++ and Win32 while adopting the newly released GDK.

https://github.com/microsoft/GDK

[ghost]

@anup-das I guess the way forward is to deal with C++ and Win32 while adopting the newly released GDK.

unasked input :

UWP apps and games are community-supported only;

I like this below bold and clear statement without hiding behind jargons

partners inside Xbox managed programs (Xbox, Xbox Game Pass, Xbox Game Streaming) should use Microsoft Win32 + GDK.

For Reference

[anup-das]

As far as I know GDK is meant for developing games. What I want to know is the future of apps that are not games for XBOX platform. I currently have a UWP app developed for PC and XBOX with WinUI 2.x but not yet published.

Will Windows App SDK 1.0 allow Win32 apps that are not games to target XBOX ? If so I will switch to Win32 now else will stick with UWP

[ghost]

Will Windows App SDK 1.0 allow Win32 apps that are not games to target XBOX ?

people have asked this question since the beginning of windowsappsdk
see 1. here & 2. here & 3. here

If so I will switch to Win32 now else will stick with UWP

running win32 apps on xbox will require the "AppContainer support for win32 apps". just like UWP apps runs in appContainer today. so they will have to bring AppContainer support first. PM of windowsappsdk hinted that next year will be the focus on AppContainer for win32 apps.

Moral of the story :

Basically they are saying Win32 AppContainer apps will run on xbox/hololens but they won't clearly say the timeframe because saying that will directly mean the End of UWP thus will hurt UWP devs, so they will hide behind vague statements until UWP becomes irrelevant enough . But , At some point of time (maybe within 1 or 2 year of time) , AppContainer will have to come to win32 apps , it's logically inevitable, they can't escape that for the fact of users security.

I will mention that UWP will keep working as is(maintenance) for many years to come but no active investments will happen in the future, also migrating from uwp to winUI3 desktop may be pain. now you decide yourself.

[anup-das]

Thanks. There is one last hurdle....it seems Microsoft won't allow Win32 apps to update from the new store something that UWP does today.

[pjmlp]

Of course they will, that is the whole point of the new store announced for Windows 11 and being backported to Windows 10 as well.

[anup-das]

https://www.ghacks.net/2021/06/29/no-win32-updates-in-windows-11s-microsoft-store/

[pjmlp]

Press has obviously still to learn about MSIX packages.

https://docs.microsoft.com/en-us/windows/application-management/msix-app-packaging-tool

[ghost]

Microsoft won't allow Win32 apps to update from the new store something that UWP does today.

Apps updating through store isn't a UWP specific feature. Any app(uwp or win32) that is MSIX packaged can update themselves regardless of they are installed from Store or Sideloaded Locally. It just happened that UWP apps were (and still is) forced to be MSIX packaged.

MSIX supports only per user install and has virtualized registry and restricted file system access, can do clean install-uninstall and can update themselves.

But there's a catch : your msix packaged apps won't run over SSH/WinRM, doesn't support per machine install/uninstall , requires users interactive login to run (can't run as admin from standard users), can't package drivers, can't extend features through DLL based injections etc.... of course things may or may not change in the future but all of them are still unsupported though being launched since 2018. keep an eye on MSIX Blog Page for future updates/changes.

if you don't need them, you can happily use MSIX.

[anup-das]

Thanks once again. Does this mean that "EXHIBIT E: TERMS AND CONDITIONS FOR WIN32 APP PACKAGES" section of the latest app developer agreement is referring to win32 apps submitted to store without msix packaging ?

Will close this discussion once confirmed 'yes' to the question above.

[ghost]

according to the current app dev agreement , Yes if the application in question submitted is raw .EXE or .MSI packaged. They will have to resort into in-app update mechanism just like VS Code does today. It's because the new store is a front end for winget.

MSI packaged apps can also update themselves but MSIX's virtualization/clean install-uninstall is not offered.

[riverar]

Want to clarify that Win32 apps -- with or without MSIX packaging -- will NOT get automatically updated. (Packaged runFullTrust apps published through the traditional manner are an exception.)

[ghost]

Want to clarify that Win32 apps -- with or without MSIX packaging -- will NOT get automatically updated.

Please clarify the source. the source should clearly say uwp apps with msix packaging will get updated where win32 apps with MSIX packaging won't.

[anup-das]

Can a win32 msix app manually update itself on launch by checking an updated version from store without resorting to implementing its own update mechanism ?

[jonwis]

Can a win32 msix app manually update itself on launch by checking an updated version from store without resorting to implementing its own update mechanism ?

CC @jvintzel - yes, you can use https://docs.microsoft.com/en-us/windows/msix/store-developer-package-update for Desktop Bridge apps in the store as well, or https://docs.microsoft.com/en-us/windows/msix/non-store-developer-updates for apps deployed via your CDN.

[ghost]

(Packaged runFullTrust apps published through the traditional manner are an exception.)

this is what happens when you try to play around with an ill defined term. FYI , any win32 app (be it 10 years old or 30 years old) when MSIX packaged , automatically generates runFullTrust in the manifest file, but that doesn't make it a UWP app, it is still a win32 app with msix packaged.

this "WHAT IS A UWP ?" ad nauseam was an unnecessary clarification here. real bummer :(

Can a win32 msix app manually update itself on launch by checking an updated version from store without resorting to implementing its own update mechanism ?

Yes. for example : messenger, telegram and any other store apps which get updated through store regularly, which does not use CoreWindow. You can test win32 apps right now with MSIX packaging Tool.

[anup-das]

I created a new project "Blank App, Packaged (WinUI 3 in Desktop)" C++ using the latest stable channel (servicing release 0.8.1) and the Package.appxmanifest file contains runFullTrust.

"

"

So this means that such an app will get AUTOMATICALLY updated via store when an update package is submitted by the developer to "Partner Center" and approved ? @riverar what do u mean by published through traditional manner ?

In future when MSFT implements App Container support for Win32 runFullTrust will not be generated and hence the app won't get AUTOMATICALLY updated. But the app itself can check for an update from STORE on launch or at any time and get itself updated.

Please confirm that my understanding is correct. I need to make a decision to proceed with my app.

[riverar]

I think there's a bunch of confusion here around the the old and new pipelines.

Regarding MSIX packages:

• MSIX packages do not inherently have a self-updating capability.
• MSIX packages, delivered via AppInstaller, can self-update. This is not a consumer oriented feature and I can speak from experience it's buggy.

Regarding the Store:

• The Microsoft Store supports "UWP" apps. runFullTrust desktop applications are also considered "UWP" apps from the Store's perspective. These apps still undergo file/registry redirection, etc. Updates to these apps are fully managed by the Store.

• Microsoft Store recently announced the ability to deliver traditional desktop applications, with/without specialized packaging and without any containment whatsoever. This is beyond runFullTrust capabilities. Updates to these apps are fully managed by the developer.

  In the new pipeline, a developer specifies a path to an .exe/.msi, fills out a few other elements, and hits publish. There is no update pipeline here. You could, however, deliver an installer that wraps the installation of an .appinstaller manfiest that configures self-updates. But it's outside the Store at this point. You'll need to bring your own CDN, etc.

Additional reading material:

• https://developer.microsoft.com/en-us/microsoft-store/desktop-apps/ Pete's video at the end of the above page is super helpful

[ghost]

So this means that such an app will get AUTOMATICALLY updated via store when an update package is submitted by the developer to "Partner Center" and approved ?

Yes.

In future when MSFT implements App Container support for Win32 runFullTrust will not be generated and hence the app won't get AUTOMATICALLY updated.

updating apps through store doesn't rely on your app being a medium IL/runfullTrust or LowIL/AppContainer or High IL/allowElevation app.

As long as your win32 app is MSIX packaged and store approved, it will be updated through store, regardless of it being a "win32 AppContainer" app or normal desktop only "win32 runFullTrust/medium IL" app.

MS Engineer himself above has provided "Yes Flag" in case you're still not convinced.

[jonwis]

@18n2es841v9uenjm is correct. It's "presence in the store" that gets you auto-update. The store doesn't care if it's partial or full trust.

• MSIX deployed via the store are updated by the store. An app in the store can check for updates (like a game or communications app that has a dependency on its service back-end being up to date) to itself using Store APIs linked above.
• MSIX deployed via AppInstaller is updated by AppInstaller & the system. The system has an update scanner for appinstaller-sourced files, and if either the .appinstaller or the target package are updated the system updater will update your MSIX-based app. (You get to control how often this happens in your .appinstaller, and you can also ask the system to check for you too.)
• MSIX deployed by your own installer from your own CDN are updated by your installer. You can certainly write your own "installer stub" that calls PackageManager.AddPackageAsync on your CDN-hosted MSIX/MSIXBundle, for both Desktop Bridge and UWP apps. Updates, however, are up to your own app code. Once installed, your app can use PackageManager.AddPackageAsync to self-update from your CDN-hosted location. (The system takes care of shutting your app down, applying the update, and optionally restarting your app.)

If your MSIX shifts from being partial-trust to full-trust (or back) that's transparent to the user as long as you keep the same package name and publisher. (cc @ptorr-msft )

@riverar is correct in that "just being an MSIX" doesn't make the system update you. Our update stacks need to know where your package came from and how to interrogate the source for updates, when, what credentials, etc. That's what AppInstaller is for. (@jvintzel, what's the best place for filing AppInstaller bugs/features?)

[jvintzel]

Feedback Hub for AppInstaller bugs and features

[ptorr-msft]

Switching permissions is currently transparent but in the future may involve user notification / consent. There would be no work for the developer though, and it wouldn't stop auto-updates (the user might decline the update, just like they can turn off updates today).

[riverar]

@jonwis "Presence in the store gets you auto-update" is not accurate when you account for the new publishing pipeline for desktop applications. These apps, with Store presence, are not automatically updated.