¿Cómo manejas las diferencias de UI/UX específicas de cada plataforma en una app multiplataforma sin que se sienta mal en ninguna de las dos?

#La trampa de la paridad de píxeles

Un error junior común en el desarrollo multiplataforma es tratar "una sola base de código" como un mandato de "una sola UI idéntica". No lo es. Los usuarios de iOS y Android cargan memoria muscular distinta: dónde va la acción destructiva en un diálogo de confirmación, si el gesto de retroceso vive en el borde de la pantalla o en un botón físico/de software, si un bottom sheet o un action sheet de pantalla completa es lo predeterminado para un menú contextual. Lanzar una app que ignora estas convenciones no se percibe como "branding consistente" para los usuarios — se percibe como "esta app no pertenece a mi teléfono".

El planteamiento senior es: comparte las partes de tu producto que expresan tu marca —color, tipografía, contenido, arquitectura de la información— y deja que los patrones de interacción diverjan donde la plataforma tenga una convención fuerte y bien conocida.

#Dónde aparecen realmente las diferencias

• Transiciones de navegación. iOS empuja pantallas con un deslizamiento horizontal (y un gesto de retroceso desde el borde izquierdo); el motion de Material en Android favorece transiciones de eje compartido o fade-through, y el gesto de retroceso es un deslizamiento de borde a nivel de sistema o el botón de atrás, sin estar ligado a ninguna transición de pantalla específica.
• Confirmaciones y acciones destructivas. iOS suele mostrar un action sheet inferior para decisiones destructivas, con la opción destructiva en rojo y Cancelar fijado al final. Android favorece un diálogo Material centrado con botones de texto, y no tiene una convención tan marcada sobre el orden de los botones.
• Chrome de navegación. Las tab bars de iOS mantienen ícono + etiqueta siempre visibles en la parte inferior; Android históricamente ha sido más flexible, mezclando navegación inferior, un drawer o pestañas superiores según la arquitectura de información de la app.
• Tipografía e iconografía. SF Pro/SF Symbols frente a Roboto/Material Symbols cargan pesos por defecto, espaciado de letras y metáforas de íconos distintos; forzar el renderizado de fuente de una plataforma sobre la otra se ve sutilmente ajeno para los usuarios de esa plataforma.
• Affordances del sistema. Los selectores de fecha/hora (la rueda giratoria de iOS frente al diálogo Material de Android), los hápticos y el pull-to-refresh tienen valores nativos por plataforma que los usuarios ya saben operar.

#La herramienta práctica: componentes adaptativos, no un fork de la app

El patrón de implementación en React Native es ramificar a nivel de componente, no duplicar pantallas enteras. Platform.select y Platform.OS te permiten mantener un solo árbol de componentes mientras intercambias las piezas que cargan significado de plataforma:

Ajustar líneas largas
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") {
    // Convención iOS: action sheet inferior, estilo destructivo, Cancelar al final.
    ActionSheetIOS.showActionSheetWithOptions(
      {
        options: [`Eliminar "${itemName}"`, "Cancelar"],
        destructiveButtonIndex: 0,
        cancelButtonIndex: 1,
      },
      (buttonIndex) => {
        if (buttonIndex === 0) onConfirm();
      }
    );
  } else {
    // Convención Android: diálogo centrado, botones de texto, acción afirmativa a la derecha.
    Alert.alert(`¿Eliminar "${itemName}"?`, "Esto no se puede deshacer.", [
      { text: "Cancelar", style: "cancel" },
      { text: "Eliminar", style: "destructive", onPress: onConfirm },
    ]);
  }
}

Flutter lleva la misma idea más lejos al ofrecer dos librerías de widgets paralelas —Material y Cupertino— más un conjunto creciente de widgets adaptativos que eligen el correcto por ti según la plataforma en ejecución:

Widget build(BuildContext context) {
  // Renderiza un switch estilo Cupertino en iOS, un switch Material en Android,
  // sin que tengas que ramificar tú mismo sobre Platform.isIOS.
  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);
}

#Proceso, no solo código

Los componentes adaptativos resuelven la mitad de implementación del problema; la otra mitad es proceso. Los equipos que aciertan en esto suelen:

• Diseñar contra tanto las Human Interface Guidelines de iOS como las guías de Material Design de Android para cualquier pantalla con convenciones específicas de plataforma, en lugar de diseñar una vez y portar.
• Poner dispositivos reales (no solo simuladores) de ambas plataformas frente a usuarios nativos de cada una durante las pruebas de usabilidad — un evaluador fluido en una plataforma detectará una convención fuera de lugar en la otra mucho más rápido que una checklist.
• Usar el navegador native-stack de @react-navigation (o las rutas conscientes de plataforma de Flutter) para que las transiciones de pantalla las maneje la API de transición real de UINavigationController/Fragment en lugar de una aproximación animada en JS — esto solo ya resuelve buena parte de las quejas de "esto no se siente nativo", porque la curva de transición y el manejo de gestos vienen del propio sistema operativo.