Platform files versus Platform.OS checks

WHAT THIS TESTS Whether you can match the divergence mechanism to the size and nature of the difference, balancing code duplication against readability and bundle hygiene.

A GOOD ANSWER COVERS Platform-specific files (.ios.js, .android.js) are best when implementations diverge substantially, when one platform imports a native module that does not exist on the other, or when mixing both would bloat a file with conditionals. The bundler ships only the matching file, so platform-only dependencies never reach the wrong build. Platform.OS, and the related Platform.select, are best for small, localized differences such as a padding value, a single style prop, or a minor behavior tweak, because keeping them inline preserves shared logic in one place and avoids duplicating nearly identical files that must be maintained in lockstep. Overusing either is the smell: huge Platform.OS branches hurt readability, and split files that differ by one line invite drift.

COMMON WRONG ANSWERS Claiming one approach is always correct, branching an entire complex component with Platform.OS, or splitting files that share ninety percent of their code. Ignoring that platform files matter for excluding incompatible native imports is a subtle miss.

LIKELY FOLLOW-UPS How do platform files help when a native module is iOS-only? How does Platform.select compare to Platform.OS? How do you avoid duplicated logic across platform files?

ONE CONCRETE EXAMPLE A button that differs only by a 4-pixel top margin uses paddingTop: Platform.OS === 'ios' ? 12 : 8 inline. But a media player wrapping a fully different iOS AVPlayer module and an Android ExoPlayer module belongs in Player.ios.js and Player.android.js, so the Android build never tries to import the iOS-only native module and vice versa.