Cross-platform Button API and implementation

WHAT THIS TESTS Whether you can define a semantic, platform-neutral component API and articulate how the same API maps onto very different underlying primitives and accessibility models.

A GOOD ANSWER COVERS Define core props by intent, not platform: variant such as primary, secondary, ghost; size; disabled; loading with a busy state; leading and trailing icon; fullWidth; an accessible label for icon-only buttons; and a press handler. Keep the API platform-agnostic and avoid web-only leakage. On web, implement with a real button element so you inherit focus, Enter and Space activation, and form semantics, style via CSS custom properties bound to tokens, and use aria-busy and aria-disabled for loading and disabled. On native, render a Pressable or platform touchable, map press to onPress, supply accessibilityRole button and accessibilityState for disabled and busy, handle platform feedback like Android ripple versus iOS opacity, and translate tokens to native style objects. The shared API stays identical; the primitive, styling mechanism, and accessibility plumbing differ.

COMMON WRONG ANSWERS Leaking web-only props such as type submit or href into the cross-platform API. Using a div with a click handler on web, losing keyboard and focus. Forgetting accessible labels for icon-only buttons. Ignoring the loading and disabled distinction. Assuming identical implementation across platforms.

LIKELY FOLLOW-UPS How do you handle an icon-only button's accessibility? Why prefer a button element over a styled div on web? How do tokens translate to native styles? How do you expose a submit button without polluting the shared API?

ONE CONCRETE EXAMPLE The shared Button takes variant, size, loading, disabled, and onPress. On web it renders a button element styled with token-driven CSS variables and sets aria-busy when loading. On native it renders a Pressable mapping onPress and setting accessibilityRole button with accessibilityState busy, while web-specific submit behavior is offered through a separate adapter rather than the shared API.