Feature Request: .NET MAUI/mobile support 🌺

[maddymontaquila]

cc @BretJohnson @bradygaster

It would be great to launch .NET MAUI apps from the AppHost file, see them on the dashboard, and auto-hook-up all the endpoints and such. This sort-of works but I would like to formalize it and make sure it works well and aligned with how aspire actually does its thing

Requirements

• Can add/reference .NET MAUI app in the AppHost file
• Ability to choose which MAUI target to launch: via apphost? something in VS or VSCode tooling? Something in the dashboard perhaps would be cool - "Start MAUI app" > popup to choose device???
• Endpoint configuration - ie, the Android emulator/iOS sim/device/local Windows or mac app should use some form of devtunnel etc to talk to the APIs and other containers spun up
• Support for OTEL? I have no idea if this would "just work" or not
• NON GOAL - deployment is unnecessary unless Aspire gets a really great CI/CD story down the line. Mobile apps aren't really... deployed lol. But they use plenty of deployed things!

Bret had taken a stab at a proof of concept of this here https://github.com/BretJohnson/aspire-mobile - I think we need to change how we're doing launch in this though (currently, you ctrl+f5 the app host then start the maui app separately... ideally we do something better than that!)

For reference, this is how you currently choose a debug target/TFM (maui uses multi-targeting) in VS and VS Code when you debug a MAUI app. you often change between different targets, so we need a way for people to do this in aspire.

maui-vs-selectdebug.mp4

(I cant get the vs code vid to upload ill add it later lol)

[maddymontaquila]

Could possibly be related to #813

[BretJohnson]

Thanks @maddymontaquila , for adding this. In terms of the launch experience, the two main options we've been discussing are:

1. Add new UI when launching from AppHost allowing the user to pick the target platform and device.
2. For MAUI apps, allow the MAUI app itself to be the startup project and have it implicitly launch the Aspire AppHost when launched, to startup the backend services (likely non-debug by default, but could be configurable). With this option, the current MAUI UI to choose target platform and device would continue to be used.

As for which option is better, we should continue to discuss, with an eye toward what most of our customers would prefer.
I've personally been liking option (2), as it's less of a change to existing user workflow & could potentially work for other scenarios too, like starting a non-Aspire ASP.NET backend automatically, but (1) is more of the current Aspire model. In any case, I'm keen to hear what others, like @bradygaster and @sayedihashimi, think here.

[BretJohnson]

FYI - MAUI work to support Aspire is being tracked here: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2000198/. But let's use this issue to track the Aspire support that's needed as part of that.

[maddymontaquila]

we could put it here, same thing as web browser just like... "Device Target" or something?

[danmoseley]

Eshop is aspirified and has a mobile app - I assume it would benefit?

[BretJohnson]

we could put it here, same thing as web browser just like... "Device Target" or something?

Yes, potentially. FYI, when we discussed this back in January @DamianEdwards said there are other scenarios, beyond MAUI, where they'd like to show some kind of launch UI in the future. I asked for examples and he said this:

[bijington]

To give my input on the possible options mentioned in #4684 (comment)

While I would probably prefer option 2 initially because it fits more with the expected workflow of a .NET MAUI app developer I think option 1 would likely be a better fit as it gives a consistent approach to the current Aspire model as you said @BretJohnson

[maddymontaquila]

Eshop is aspirified and has a mobile app - I assume it would benefit?

You know it!!! This was the main reason we didnt "finish" wiring up the eshop mobile client - no way to launch them both without it being gross.

[maddymontaquila]

To give my input on the possible options mentioned in #4684 (comment)

While I would probably prefer option 2 initially because it fits more with the expected workflow of a .NET MAUI app developer I think option 1 would likely be a better fit as it gives a consistent approach to the current Aspire model as you said @BretJohnson

I'm with you here Shaun. I think 1 is the "right" thing to do from the Aspire perspective. Maybe we call that the MVP and listen to see if that really confuses people or it works okay. I don't think we'd need to separate out by TFM either - just a list of available debug targets we find.

[BretJohnson]

To give my input on the possible options mentioned in #4684 (comment)
While I would probably prefer option 2 initially because it fits more with the expected workflow of a .NET MAUI app developer I think option 1 would likely be a better fit as it gives a consistent approach to the current Aspire model as you said @BretJohnson

I'm with you here Shaun. I think 1 is the "right" thing to do from the Aspire perspective. Maybe we call that the MVP and listen to see if that really confuses people or it works okay. I don't think we'd need to separate out by TFM either - just a list of available debug targets we find.

Though worth noting - I think that 1 is the more expensive option technically.

[bijington]

@BretJohnson When you say it is more expensive (not that I am footing the bill) but do you have any thoughts on how much more expensive over option 2? Could there be an option that starts with option 2 (or possibly a new option) but puts infrastructure in place for option 1?

[BretJohnson]

@bijington - In terms of cost, we still need to design (design both UX and implementation) and cost it. And I think we should design and cost. I believe that @bradygaster will be looking at the experience design. Dev cost wise, I'd say probably at least a couple man months, but I'm just swaging and we need to dig in - which we should.

My main concern here is just to make sure we have a good sense of what customers (like yourself) actually want to do - what workflows want to support well. And use that knowledge to drive the spec / priorities. It'd be a shame to devote a lot of effort to supporting option 1, and only option 1, if option 2 is what folks actually would prefer most often in practice. Or maybe we should support both. For instance, most of the time when debugging the MAUI app would you also want to debug all the services? Most of the time when restarting the MAUI app would you want to restart all the services? That's clearly a useful option to support - which is a natural the Aspire model today. But do typical MAUI / client app devs want it to be the default - or only - option?

[maddymontaquila]

Ok so the current POC -

• Everything is driven via the AppHost. You start debugging the apphost, and that will start the MAUI app along with all the other things. Let's cost what it'll be for that to happen if we use the launch UI @DamianEdwards had shared earlier to select a target device. (Also we can do something in that popout menu that says - to manage MAUI devices change your startup proj)
• Reference the MAUI proj in AppHost either with AddMauiApp or AddClientApp/AddNativeApp - leaning towards AddMauiApp so we don't accidentally pigeonhole ourselves into having supporting everything else right away
• Something something devtunnels @sayedihashimi is going to sort out LOL (related to Support VS dev tunnels with Aspire #813 )
• The apphost/DCP should probably try to start the maui app ABSOLUTELY LAST so that it doesnt slow down the other builds - maui usually takes the longest. Maybe implicitly we use something like WaitOn() (or whatever we do for Control startup order / readiness check for services #921 ) when that gets implemented but user could override
• this will be icky until we implement something to help w Restart individual Aspire project #3095 since youll have to restart everything including the maui app every time and as we all know mobile b slow

cc @bradygaster @BretJohnson

[francoistanguay]

Would be nice to consider how the broader .NET UI ecosystem like Uno could benefit from this and properly integrate/extend.

In other words, no strong dependency on MAUI bits from an Aspire standpoint.

[maddymontaquila]

@francoistanguay yeah absolutely!!! ideally aspire apphost knows nothing about the projects its referencing, so im sure we could extend it to work somehow with Uno, or at least hook you guys up in your extension

[maddymontaquila]

Update for the folks following along - MAUI platform team (@emaf ) is gonna look at #3043 when they get a chance because that is the first thing we hit with apphost blocking us. There will also be some Android SDK changes needed to pass launch variables and such.

[maddymontaquila]

also related #876

[Robbert-jansen]

Omg, this would save my life

[bricefriha]

I would just like to say that this would make more sense (cents) than a changing machine. (This sentence works better when being spoken).

Either way, that would be a game-changer!
Pretty please!?