Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode:
1. Conditional templating, like:
<SomeLayout>
if $is_android {
//Only render the back button for Android
<BackButton />
}
/* ... */
</SomeLayout>
2. Dynamic properties where Rust logic checks for the target platform, like:
Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs.
That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.
This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html
1. Conditional templating, like:
2. Dynamic properties where Rust logic checks for the target platform, like: 3. Maintain a separate codebase (or different specific components) for each target platform, in the spirit of React NativeOr any mix of the above.