Projectreunion: Proposal: Allow hosting of UWP apps inside UWP apps

Created on 3 Jun 2020  路  19Comments  路  Source: microsoft/ProjectReunion

Proposal: Allow hosting of UWP apps inside UWP apps

Summary

It would be awesome to be able to host a UWP app insider of another one.
This would be similar to what both My People and Xbox game bar do.

Rationale

I am one of the developers of Quarrel which is an unofficial UWP discord client.
The developer of MyTube (an unofficial UWP YouTube client) kindly provided us with a dll that contains large parts of the MyTube code that allows us to host an instance of MyTube inside Quarrel to provide youtube embeds in a way that does not require us to pull in a webview.
However, it would be much better if we could host the store version of MyTube inside Quarrel similarly to how Xbox game bar can host UWP apps.

I imagine there are many other similar cases in which other developers would find this useful.

Scope


| Capability | Priority |
| :---------- | :------- |
| This proposal will allow UWP apps to host other UWP apps | Must |
| This proposal will allow win32 apps to host UWP apps | Could |

Open Questions

  1. As this is not related directly to WinUI I'm not certain if this is the correct place to ask?
  2. Could this have broader security implications?
  3. Should any UWP app be able to host any other or should it require the hosted UWP app support it?
area-Hosting area-UWP

Most helpful comment

This is super interesting, thank you!

At least in theory there's support for this through a combination of App Extensions and App Services that would let you put an iframe-like thing in your app from another app.

  • The hosting app declares a app extension where the "public" folder is expected to contain some HTML+JScript. It finds extension implementations and loads their HTML into a WebView.
  • The hosted app that included the HTML then can use App Services to call over from the hosting app to the hosted app's background task.

There are security concerns for the hosting app, as they're effectively running code (JavaScript) from another app under their own identity. There's ways to control access from the JavaScript runtime to the host, and the WebView can use the "out of process" model to further isolate it. But it is possible. And It's nowhere near the model proposed on the thread so far, but it's something that works today. We understand the challenges associated with (a) writing part of your app in HTML and another in XAML (b) using AppServices efficiently as part of an interactive application.

If we do something more here, we'd follow the same model that app extensions use - the hosted app would say "this is the part of me that I'm OK to have hosted elsewhere" and use capabilities to verify that the hosting app is who they want to be. We'd also want app A's code to run inside app A's process and app B's code to run in app B's, while getting an input/output pipe between them.

A core issue for all apps is lifecycle - if A hosts B hosts C then the system needs to keep all of them alive. These would also necessarily be optional and somewhat ephemeral - the user can choose to uninstall B or A at any time, and the hosting app needs to be OK with a "this child thing disappeared" message.

So yes - I've got a lot of ideas here, but we're looking to the community to know whether this is something we should spend additional resources on, either at the platform layer or in Project Reunion. For now, please pile onto this thread:

  • Suggested API shapes
  • Scenarios you'd like to enable (either with multiple of your own apps, or apps to whom you're related)
  • Non-scenarios
  • Security, lifecycle, and identity concerns

All 19 comments

This is almost a more scoped version of a request around app extensions.

I mean if we just had C# Roslyn code generation supported in the sandbox, then we could leverage XamlReader and that to do something similar today...

This is almost a more scoped version of a request around app extensions.

I mean if we just had C# Roslyn code generation supported in the sandbox, then we could leverage XamlReader and that to do something similar today...

This is different from app extensions as this should allow you to host a whole uwp app that is activated with ActivationKind::Protocol with a custom scheme name.
This should also be done from a compiled app, not from source.
This can be done already as Xbox game bar does it, I just want that ability for all developers xD

The title makes me think "UWP Inception" :)

Could the entire app be built as a custom control to achieve something like this ? That way we could leverage all the control library features for sharing/tooling etc ? I suppose that needs extra work on the app side as opposed to just embedding the app wholesale though.

Would this allow apps to host apps that host apps that host app ... ?

How would/could this impact performance (which is one of the selling points of UWP)? Could we end up in the situation where UWP apps end up just like NPM modules, where we host an app for everything resulting in dozen dependencies?

Would this allow apps to host apps that host apps that host app ... ?

How would/could this impact performance (which is one of the selling points of UWP)? Could we end up in the situation where UWP apps end up just like NPM modules, where we host an app for everything resulting in dozen dependencies?

Nested hosting would be less useful so it's certainly not a requirement.
This would be optional so performance would really be dependant on how you use it but clearly the My People and Xbox game bar teams thought it was performant enough to use.

Would this allow apps to host apps that host apps that host app ... ?
How would/could this impact performance (which is one of the selling points of UWP)? Could we end up in the situation where UWP apps end up just like NPM modules, where we host an app for everything resulting in dozen dependencies?

Nested hosting would be less useful so it's certainly not a requirement.
This would be optional so performance would really be dependant on how you use it but clearly the My People and Xbox game bar teams thought it was performant enough to use.

Correct me if I am wrong,, My People relies on app hooks. That's the reason why Facebook or Messenger doesn't tie into it.

I am not sure all UWP app developers would like other apps "hosting" their app within other apps.

But, there could be a mechanism for an app creating a "hostable" page or UI - which could be used within other apps.

Some examples being

  • Displaying a contact's details in an app; (people app provider)
  • Loading a YouTube video from another app;
  • Linking to someone's Instagram profile;
  • Creating a Tweet from your photo app; (twitter providing a "compose tweet" UI);

Whether this UI appears in a popup window, or appears embedded in a Provider Hosting control. There would have to be behavioural hooks, so the main app hands over to another app, and is unable to log keystrokes or otherwise intercept the other app's control. But there be a way to handshake so hosted app content can return control to the main app, and send some kind of status message perhaps?

I am not sure all UWP app developers would like other apps "hosting" their app within other apps.

But, there could be a mechanism for an app creating a "hostable" page or UI - which could be used within other apps.

Some examples being

  • Displaying a contact's details in an app; (people app provider)
  • Loading a YouTube video from another app;
  • Linking to someone's Instagram profile;
  • Creating a Tweet from your photo app; (twitter providing a "compose tweet" UI);

Whether this UI appears in a popup window, or appears embedded in a Provider Hosting control. There would have to be behavioural hooks, so the main app hands over to another app, and is unable to log keystrokes or otherwise intercept the other app's control. But there be a way to handshake so hosted app content can return control to the main app, and send some kind of status message perhaps?

This is more in line with what I was thinking, it makes sense to require the hosted app supported being hosted and provide a specific page for that.

Nested hosting would be less useful so it's certainly not a requirement.

But if you try to host a page that already hosts content? E.g. I want to host a discord chat which uses a hosted youtube player?

I don't think it's a useful feature by any means. It looks like a specific need for your app, but I can hardly imagine some other UWP app needing to be hosted in another one. This will bring confusion as well.

For example, what if I don't want my UWP app to be hosted in another app? Or let's say I want to, how can I restrict some apps or how am I supposed to allow some apps? I am not even talking about technical difficulties for sandboxed environment being hosted in another sandboxed environment here. These are just permission management stuff.

Personally I don't find this feature useful or providing value to the framework itself.

Nested hosting would be less useful so it's certainly not a requirement.

But if you try to host a page that already hosts content? E.g. I want to host a discord chat which uses a hosted youtube player?

Sure it has some uses, and maybe this should be allowed, but the main focus would be non-nested hosting.

I don't think it's a useful feature by any means. It looks like a specific need for your app, but I can hardly imagine some other UWP app needing to be hosted in another one. This will bring confusion as well.

For example, what if I don't want my UWP app to be hosted in another app? Or let's say I want to, how can I restrict some apps or how am I supposed to allow some apps? I am not even talking about technical difficulties for sandboxed environment being hosted in another sandboxed environment here. These are just permission management stuff.

Personally I don't find this feature useful or providing value to the framework itself.

Its a feature used by both My People and Xbox game bar so clearly it has some uses.
The idea is that this would be opt-in so it would not affect you if you did not wish to use it.

The idea is that this would be opt-in so it would not affect you if you did not wish to use it.

I don't think it will work like that. I own AppA. You own AppB. I allow developers to host my app. Your AppB hosts my AppA. Then I update my app to host another UWP app called AppC. Or, I update it to host even your AppB. Suddenly your AppB hosts AppC inside my AppA, or there is a host-ception issue :) You can't rely on some other developer's app or published store app to just behave as it was in development stage of yours.

Just because some internal apps are using it doesn't mean that whole framework development effort should be re-directed to it. There might be useful cases, but those cases are very unique and minor. The reason why they are intended to be used only internally is that they are unique to Microsoft. Not to an external developer. If your argument is 'Microsoft internally has it, just enable us to do it as well', then allowing this to public will require a lot of tooling development for VS, some changes to developer portal in web and hard thinking on corner cases. Like, the app you're hosting might not be available for user region.

You handled this problem with your solution with the help of MyTube developer as it needed to be handled. That is the correct way to fix this problem. Enabling all devs to host any UWP app they want from Store is not a fix at all.

Interesting. This scenario is more like an App model scenario rather than WinUI scenario.

Just thinking about the security implications here, it could take a tremendous amount of time to design it, if the security team doesn't block it, of course, but I think there are a lot of chances this happen.

Adding @AdamBraden , who works in the app model, for awareness.

The idea is that this would be opt-in so it would not affect you if you did not wish to use it.

I don't think it will work like that. I own AppA. You own AppB. I allow developers to host my app. Your AppB hosts my AppA. Then I update my app to host another UWP app called AppC. Or, I update it to host even your AppB. Suddenly your AppB hosts AppC inside my AppA, or there is a host-ception issue :) You can't rely on some other developer's app or published store app to just behave as it was in development stage of yours.

This can be solved by just not allowing nested hosting, or maybe by requiring nested hosting be enabled for all apps in the hosting chain.

Better off just using hooks.

You can already host another app using Launcher.LaunchForResults.

This is super interesting, thank you!

At least in theory there's support for this through a combination of App Extensions and App Services that would let you put an iframe-like thing in your app from another app.

  • The hosting app declares a app extension where the "public" folder is expected to contain some HTML+JScript. It finds extension implementations and loads their HTML into a WebView.
  • The hosted app that included the HTML then can use App Services to call over from the hosting app to the hosted app's background task.

There are security concerns for the hosting app, as they're effectively running code (JavaScript) from another app under their own identity. There's ways to control access from the JavaScript runtime to the host, and the WebView can use the "out of process" model to further isolate it. But it is possible. And It's nowhere near the model proposed on the thread so far, but it's something that works today. We understand the challenges associated with (a) writing part of your app in HTML and another in XAML (b) using AppServices efficiently as part of an interactive application.

If we do something more here, we'd follow the same model that app extensions use - the hosted app would say "this is the part of me that I'm OK to have hosted elsewhere" and use capabilities to verify that the hosting app is who they want to be. We'd also want app A's code to run inside app A's process and app B's code to run in app B's, while getting an input/output pipe between them.

A core issue for all apps is lifecycle - if A hosts B hosts C then the system needs to keep all of them alive. These would also necessarily be optional and somewhat ephemeral - the user can choose to uninstall B or A at any time, and the hosting app needs to be OK with a "this child thing disappeared" message.

So yes - I've got a lot of ideas here, but we're looking to the community to know whether this is something we should spend additional resources on, either at the platform layer or in Project Reunion. For now, please pile onto this thread:

  • Suggested API shapes
  • Scenarios you'd like to enable (either with multiple of your own apps, or apps to whom you're related)
  • Non-scenarios
  • Security, lifecycle, and identity concerns

This idea has great potential, may be in future the whole windows shell could be a UWP app and other developers can just make different shells as UWP app just like how Android handles Launchers.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Jaiganeshkumaran picture Jaiganeshkumaran  路  4Comments

Felix-Dev picture Felix-Dev  路  6Comments

Jaiganeshkumaran picture Jaiganeshkumaran  路  4Comments

FrayxRulez picture FrayxRulez  路  7Comments

mrlacey picture mrlacey  路  3Comments