Cross-platform Button API and implementation
API parity vs platform-specific implementation.
Shared semantic props like variant, size, disabled, loading, onPress; web renders a button element with focus and CSS, native maps to platform touchables and accessibility traits.
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.
Interview question
Why should a cross-platform Button's shared API exclude a web-only prop like type set to submit?
- a.Native platforms render faster when fewer props are defined
- b.It is platform-specific and would leak web semantics into a neutral cross-platform APICorrect
- c.The submit behavior cannot be implemented on the web at all
- d.TypeScript cannot type a prop that only some platforms use
Why? this is the answer
Keeping the shared API semantic and platform-neutral prevents web-only concepts from polluting native usage; submit can be offered via a web adapter. The other options misstate performance, web capability, and typing.
Just read this? Test yourself on what you have been reading.
- #component-api
- #cross-platform
- #button
- #accessibility
- #design-systems
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles