Conditional logic with Platform.Version

WHAT THIS TESTS Whether you can gate behavior on the operating system version, knowing that Platform.Version has different types per platform and that version is a proxy, not a direct measure, of device features.

A GOOD ANSWER COVERS Platform.Version returns the Android API level as a number, so a numeric comparison works directly, while on iOS it returns the version as a string like '17.4', which you typically parse before comparing. You use it to call APIs introduced in a specific OS version only where they exist and to fall back otherwise. A common Android case is requesting a permission added at a certain API level, such as POST_NOTIFICATIONS on Android 13 (API 33), only when Platform.Version is at least 33. For layout, prefer react-native-safe-area-context to detect actual insets rather than inferring a notch from the OS version, since version does not guarantee a specific device shape.

COMMON WRONG ANSWERS Comparing the iOS string version with a numeric operator without parsing, assuming the same type on both platforms, or inferring hardware features like a notch purely from OS version. Hardcoding magic numbers without comments about which API level they represent reduces clarity.

LIKELY FOLLOW-UPS Why is detecting safe-area insets better than inferring a notch from version? How do you write a clean comparison given the type difference? When does a feature check beat a version check?

ONE CONCRETE EXAMPLE if (Platform.OS === 'android' && Platform.Version >= 33) { await request(PERMISSIONS.ANDROID.POST_NOTIFICATIONS); } gates the runtime notification permission to Android 13 and newer, where it exists, while older devices skip it. On iOS you would parseInt(Platform.Version, 10) before comparing, because the value is a string, not a number.