1. We build on top of cross platform abstractions with feature detection (wgpu is our cross platform low level graphics library, cpal is that for audio, etc). We build our features in a way that adjust the ECS app logic according to what features are available at runtime 2. In a few cases we do "compile time feature/platform detection" to select the appropriate code for a given platform. But most "Bevy features" don't use this / we opt for (1) more than anything else
In the case of geometry: that has a "dynamic" representation that can be adjusted according to the platform context (although in practice we don't do any platform-specific geometry transforms yet). And that gets written to the platform's gpu using wgpu.
Bevy has a "render graph", which feeds on Bevy ECS data. We adapt the render graph (and the ECS data that drives it) according to the features supported on a given platform.
How did you tackle the problem of components containing geometry for platform-specific graphics engines? Does Bevy use platform-specific components? If an application needs multiple offscreen textures to compose a frame, are there components that contain metadata for which passes they belong to (so, now, platform and pass specific components)?