What is the recommended way to build modern Android applications?

[RoundRaspberry]

I apologize if this is the wrong place to ask.

I want to port a WPF application to Android and have been looking at my options. The WPF application is, for the most part, well written. It adheres to MVVM, and I expect to be able to reuse the view models with only minor code changes.

I would like this application to look and feel both native and modern. Currently, this would be Material 3 Expressive, but I also want to keep up with any future updates to the design language.

I believe these are my options:

1. Use .NET MAUI. Material 3 does not appear to be implemented yet.
2. Use .NET for Android with Views. Some components do not seem to be implemented in MDC-Android (FAB Menu for example). A few components will have to be implemented in Compose using Compose interop.
3. Use .NET for Android, but write most of the UI in Compose. I mean not just individual components, but entire pages, if not the entire application's UI.
4. Write a Kotlin/Compose application that binds to the .NET view models. This is different from the previous option in that the application's entry point would not be in .NET.
5. Give up on the idea of reusing the .NET view models and write the entire application in Kotlin.

I understand that some of these options may not be feasible.

I am not that experienced with Android development, so I would like some advice from those that are. I enjoy working with Kotlin and Compose, but it seems difficult to combine those with .NET. I don't think the documentation describes how to do this. There's documentation on how to combine Kotlin/Compose with Java/Views and there is documentation that describes how to combine Java with C#.

What is the recommended approach for building modern Android apps with .NET?

[ghost]

From my experience, if you stick with the default MAUI approach, it works well. If you stray too far from the official documentation with unusual combinations, you’re more likely to encounter quirks and end up on your own. In my view, MAUI is a really solid tool for mobile development—especially when paired with C# library re-usage, Visual Studio, regular MAUI updates, and an active community.

Example? FAB Menu. MAUI does not support it, but you can do it in XYZ way.

Hope this helps.

[RoundRaspberry]

Sorry for the late reply.

I think I understand what you mean. MAUI is a decent option when trying to build an application for multiple platforms with relatively little effort. That said, I believe .NET for Android is a better fit for my requirements. It is already possible to write Material 3 applications using .NET for Android. For the most part, it works well.

It's just that it does not provide a complete implementation of Material 3 Expressive. Compose interop is recommended, but using it with .NET for Android feels daunting.

It seems that Android development is moving toward Compose, and I wonder what that means for .NET for Android and .NET MAUI.

[ghost]

Yes, MAUI connects to .NET for Android when build against Android platform. I think MAUI will stay, as Compose is Android only, while with MAUI I can re-usage C# library and compile against iOS and Android. Just with some workarounds for MAUI quirks :)

[RoundRaspberry]

I don't think MAUI is going anywhere. It is very useful when building applications for multiple platforms. Compose is not going to replace it.

In my case, however, I want to build an application specifically for Android (following the latest Material design guidelines). iOS support is not a requirement and is unlikely to become one in the future.

There may still be benefits to using .NET MAUI in this scenario, but it seems easier to use .NET for Android directly to achieve a specific user interface on Android.

I would also encounter limitations using .NET for Android with XML views (e.g. the FAB menu). Compose would solve this problem for me, but as a .NET developer, I would prefer to stick to .NET. That said, I wouldn't mind writing the views in Kotlin if I could implement the application logic in C#.

As far as I can tell, there is no documentation specifically describing how to use a Compose component in a .NET for Android (or MAUI) application.

[jingliancui]

Not sure if i understand your question.
But it simple to me for 2 choice.
1.MAUI shows natives things through handler, that's mean if you want to show something special from android just wrap them by handler and show them on maui.
2.If you choose dotnet android, then reuse maui thing, check this

https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/native-embedding?view=net-maui-9.0&pivots=devices-android

[RoundRaspberry]

It's a component, typically located in the bottom right corner of an application. It expands into a menu when pressed, allowing the user to select an action. Link to Material documentation

[jingliancui]

It's a component, typically located in the bottom right corner of an application. It expands into a menu when pressed, allowing the user to select an action. Link to Material documentation

I just asked AI and responded me that it's a view.
So I think you just using handler to map to use in Maui is fine.
But I didn't do any try.

[RoundRaspberry]

The problem I encountered is that this view is not available in Material Components for Android. To use it, I must find a way to use a Jetpack Compose component in a .NET for Android application.

[jingliancui]

The problem I encountered is that this view is not available in Material Components for Android. To use it, I must find a way to use a Jetpack Compose component in a .NET for Android application.

try to upload you code to github, let see if anyone can help?

[RoundRaspberry]

I unfortunately cannot share the code.

I have written a composable function in Kotlin and built an .aar file that contains it. I then created a bindings library. It builds successfully, but when referenced from my .NET for Android project, I encounter the following error:
Type androidx.compose.runtime.Immutable is defined multiple times

It is described here. I haven't had the time to figure that out just yet.

I may then be able to follow this documentation.

However, I am concerned that may be approaching this incorrectly. The original post is deliberately vague, and I would like to know if any particular strategy is preferred in a scenario like mine. Specifically, I want to understand what limitations a .NET developer might encounter that could be avoided if the application were written entirely in Kotlin with Jetpack Compose.