Platform-specific file extensions

WHAT THIS TESTS Whether you know the platform extension mechanism Metro provides for cleanly separating divergent platform code at the file level rather than branching at runtime.

A GOOD ANSWER COVERS React Native's Metro bundler recognizes platform-specific file extensions. You create two files such as MyComponent.ios.js and MyComponent.android.js, each exporting a default component with the same name and API. Elsewhere you import './MyComponent' with no extension, and the bundler automatically substitutes the file matching the build platform. There is also a .native.js extension that targets both iOS and Android while letting a plain .js serve web in a shared codebase. This keeps entirely different implementations isolated and avoids large runtime conditionals, while preserving a single import path for consumers.

COMMON WRONG ANSWERS Writing the extension in the import statement, believing the convention only works for assets, or thinking it requires manual bundler configuration. Confusing it with Platform.OS, which is the runtime branching alternative for small differences within one file, is also common.

LIKELY FOLLOW-UPS When do you prefer platform files over a Platform.OS check? How does .native.js fit a web-plus-native codebase? Does the resolution work for images and other assets too?

ONE CONCRETE EXAMPLE For a header that differs entirely per platform, you create Header.ios.js using a large iOS-style title and Header.android.js using a Material toolbar. A screen simply writes import Header from './Header'; and uses it. On an iOS build Metro resolves Header.ios.js; on Android it resolves Header.android.js, with no conditional code in the screen itself.