How do you handle platform-specific UI/UX differences in a cross-platform app without it feeling wrong on both platforms?

#The trap of pixel parity

A common junior mistake in cross-platform development is treating "one codebase" as a mandate for "one identical UI." It isn't. iOS and Android users carry different muscle memory: where the destructive action goes in a confirmation dialog, whether a back gesture lives at the edge of the screen or in a hardware/software button, whether a bottom sheet or a full-screen action sheet is the default for a contextual menu. Shipping an app that ignores these conventions doesn't read as "consistent branding" to users — it reads as "this app doesn't belong on my phone."

The senior framing is: share the parts of your product that express your brand — color, typography, content, information architecture — and let interaction patterns diverge where the platform has a strong, well-known convention.

#Where the differences actually show up

• Navigation transitions. iOS pushes screens with a horizontal slide (and a back-swipe gesture from the left edge); Android's Material motion favors shared-axis or fade-through transitions, and the back gesture is a system-level edge swipe or the back button, not tied to any specific screen transition.
• Confirmation and destructive actions. iOS commonly surfaces a bottom action sheet for destructive choices, with the destructive option styled in red and Cancel pinned last. Android favors a centered Material dialog with text buttons, and doesn't have as strong a convention about button order.
• Navigation chrome. iOS tab bars keep icon + label always visible at the bottom; Android has historically been more flexible, mixing bottom navigation, a drawer, or top tabs depending on the app's information architecture.
• Typography and iconography. SF Pro/SF Symbols vs. Roboto/Material Symbols carry different default weights, letter spacing, and icon metaphors; forcing one platform's font rendering onto the other looks subtly foreign to users of that platform.
• System affordances. Date/time pickers (iOS's spinning wheel vs. Android's Material dialog), haptics, and pull-to-refresh all have platform-native defaults users already know how to operate.

#The practical tool: adaptive components, not a fork of the app

The implementation pattern in React Native is branching at the component level, not duplicating whole screens. Platform.select and Platform.OS let you keep one component tree while swapping the pieces that carry platform meaning:

import { Alert, ActionSheetIOS, Platform, StyleSheet } from "react-native";

const styles = StyleSheet.create({
  header: {
    height: Platform.select({ ios: 44, android: 56, default: 48 }),
    paddingTop: Platform.select({ ios: 0, android: 8 }),
  },
});

function confirmDelete(itemName: string, onConfirm: () => void) {
  if (Platform.OS === "ios") {
    // iOS convention: bottom action sheet, destructive styling, Cancel last.
    ActionSheetIOS.showActionSheetWithOptions(
      {
        options: [`Delete "${itemName}"`, "Cancel"],
        destructiveButtonIndex: 0,
        cancelButtonIndex: 1,
      },
      (buttonIndex) => {
        if (buttonIndex === 0) onConfirm();
      }
    );
  } else {
    // Android convention: centered dialog, text buttons, affirmative action on the right.
    Alert.alert(`Delete "${itemName}"?`, "This cannot be undone.", [
      { text: "Cancel", style: "cancel" },
      { text: "Delete", style: "destructive", onPress: onConfirm },
    ]);
  }
}

Flutter takes the same idea further by shipping two parallel widget libraries — Material and Cupertino — plus a growing set of adaptive widgets that pick the right one for you based on the running platform:

Widget build(BuildContext context) {
  // Renders a Cupertino-style switch on iOS, a Material switch on Android,
  // without you branching on Platform.isIOS yourself.
  return Switch.adaptive(
    value: notificationsEnabled,
    onChanged: (value) => setState(() => notificationsEnabled = value),
  );
}

Route<T> buildPlatformRoute<T>(WidgetBuilder builder) {
  return Platform.isIOS
      ? CupertinoPageRoute<T>(builder: builder)
      : MaterialPageRoute<T>(builder: builder);
}

#Process, not just code

Adaptive components solve the implementation half of the problem; the other half is process. Teams that get this right usually:

• Design against both the iOS Human Interface Guidelines and Android's Material Design guidelines for any screen with platform-specific conventions, rather than designing once and porting.
• Put real devices (not just simulators) of both platforms in front of platform-native users during usability testing — a reviewer fluent in one platform will flag an off convention on the other far faster than a checklist will.
• Use @react-navigation's native-stack navigator (or Flutter's platform-aware routes) so screen transitions are driven by the real UINavigationController/Fragment transition APIs instead of a JS-animated approximation — this alone fixes a large share of "this doesn't feel native" complaints, because the transition curve and gesture handling come from the OS itself.