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?