Native interop with Jetpack Compose and SwiftUI handlers #29199
Replies: 2 comments 3 replies
-
I am also interested in this question. As you have laid out, it certainly does appear that Jetpack Compose and SwiftUI are very much the direction of travel. Achieving some form of interop with these would seem to be essential to securing a long-term future for MAUI, at least so long as the rendering model continues to be to target native controls on each platform. Whilst the UIKit and Views approaches are not likely to disappear in the short term, it's clear the latest platform features are going to be focussed around the new frameworks.
I had the same question in mind, and I have tried to find the latest public statements on this topic. My understanding is that in the case of SwiftUI, there is work to be done by the .NET runtime team as a pre-requisite, tracked here: I'm less clear on what is required for Compose support within MAUI, and I could not find a work item anywhere regarding this, but did find some related discussion on the below pull reuqest, where it sounds like the dotnet android tooling would have to perform some functions currently performed by a kotlin compiler plugin. Perhaps @jonathanpeppers might be willing to let us know if anything along these lines is or could be planned?
Whilst it's perhaps not a DSL at the level of the runtime, we've loved using the .NET MAUI Markup Community Toolkit in favour of XAML for a few years now, with great results. It does allow a declarative paradigm, similar to SwiftUI and Compose, to be used today. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding:
What are you wanting to do here? Compose only works on Android, are you wanting to use Android-only compose views inside a MAUI app? What would you do for the other non-Android platforms? I think there is just some more thought on what the actual need here is. MAUI is its own UI stack, so it doesn't seem like it needs to mix & match with every other UI framework under the sun. Or is the real ask, you want to use Compose with C# (Android only) and not use MAUI at all? |
Beta Was this translation helpful? Give feedback.
-
What myself and, I believe the OP, are alluding to, is the possible use of the Compose stack as the rendering layer for MAUI on Android, and the use of the Swift UI stack for the rendering layer on iOS. This would be the same role as the "Views" stack performs currently on Android for MAUI, and the "UIKit" stack currently performs on iOS within MAUI. Nothing in the public API for MAUI controls and layouts would necessarily change, but the implementations of the Handlers would render to a different native stack on these platforms. For further clarity, my understanding of native UI architecture on iOS is that there are two full and differing implementations - UIKit, and SwiftUI. These are not merely two patterns to achieve the same underlying runtime views, they are two entirely different rendering stacks. This situation is to the best of my knowledge mirrored on Android, with Compose being more than a way to render the same Views components, but an entirely different stack. I am of course happy to be corrected if this is not the case, as I do not spend much time in native Android development currently. So this would not be a use case to embed Compose views inside the Android version of a MAUI app per se, nor to use the Compose APIs in C# to construct an app UI instead of MAUI (however, this final scenario would be related, whereby the ability to address Compose APIs in C# would be required, but only in order for a Handler which targets Compose to be implemented). The motivation behind my question is the understanding that the Compose stack is the path the Android team are taking, with the Views system explicitly not recommended for new development by the documentation. This is of course not to suggest it will be removed imminently or anything like that, but it nevertheless does appear to be the case that Compose is the focus of the team going forwards. Even refencing documentation for any "Views" UI component begins with a signpost to refer to the Compose version as the recommended UI toolkit, such as below There is a similar, but slightly less dramatic set of messaging from Apple, where SwiftUI is the "best" way to build Apple UI, see below These Apple docs then reference some features only available in SwiftUI. I think the fear is that even if UIKit and Views are here to stay, the new features and APIs will eventually (and to some extent currently) only be accessible on the new stacks, and thus ultimately become legacy. Without the Compose / SwiftUI interop, this scenario would leave MAUI unable to address the new features also. |
Beta Was this translation helpful? Give feedback.
-
So, this is basically "rewriting" MAUI's backend on two platforms. I would think there would need to be a significant reason to do this. I honestly don't see how Apple would deprecate UIKit without killing thousands of apps. Same for Android and their APIs that have been around since API 1.
From what I have observed for Android, plenty of new features keep appearing in AndroidX & Google Play services components. MAUI may need to update these/switch to a new type, etc., but that is a much smaller jump than moving to Compose. We would have to ask the iOS team for their opinion on Apple, but their concern is likely more about new Swift-only frameworks. Swift interop features to allow MAUI & other developers to call them. This has been worked on for a bit, but I don't know the current status. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the original comment:
I'm not sure that is true, this would mean Android deprecates hundreds, (thousands?) of APIs that have been available since Android API 1. I just don't think they can ever break the entire ecosystem like that. |
Beta Was this translation helpful? Give feedback.
-
💡 Idea Summary
With the ongoing deprecation of Android’s XML-based Views and Apple’s increasing shift toward SwiftUI, it’s worth considering a future direction where .NET MAUI’s handlers system could directly integrate with Jetpack Compose and SwiftUI as the native render targets, instead of relying on legacy UI frameworks (ViewGroup/UIViews/etc).
🤔 Why This Matters
Jetpack Compose is now the official recommended way to build Android UIs.
SwiftUI is rapidly replacing UIKit and storyboards on Apple platforms.
MAUI currently renders to legacy view systems, which may be deprecated or unsupported in the coming years.
Modern UI trends favor declarative and composable UI DSLs, which are currently missing in MAUI unless we manually implement a C#-only abstraction.
🧱 Proposed Approach
Extend the MAUI handler architecture to optionally target:
Jetpack Compose components (e.g., Text, Column, Row, etc.)
SwiftUI views (Text, VStack, Button, etc.)
Create bridges or rendering backends that allow MAUI to map controls like Label, Button, VerticalStackLayout to their modern native equivalents:
Example:
new Label { Text = "Hello" } // maps to -> Text("Hello") in Compose or SwiftUI based on platformNo reliance on XML or Storyboards, enabling full C#-driven app logic with modern native performance and look.
👉 QUESTION
What is the long-term plan for MAUI once native Android Views and Storyboards are no longer supported?
Will handlers eventually be mapped to Jetpack Compose/SwiftUI?
Will Microsoft introduce a C#-native declarative UI DSL similar to Compose/SwiftUI?
Beta Was this translation helpful? Give feedback.
All reactions