¿Cómo equilibras la paridad entre plataformas (consistencia de funciones iOS/Android) con la excelencia específica de cada plataforma?

#Por qué "que sean idénticas" es el instinto equivocado

Esta pregunta comprueba si entiendes que iOS y Android no son dos pieles sobre la misma app — son dos plataformas con convenciones de interacción distintas, capacidades distintas y expectativas de usuario distintas, y tratar la paridad como "idéntico píxel por píxel" produce una app que se siente ajena en ambas. La respuesta senior no es "siempre las mantenemos sincronizadas" ni "siempre dejamos que cada plataforma haga lo suyo" — es un marco para decidir, funcionalidad por funcionalidad, qué tipo de consistencia realmente sirve al usuario, porque la respuesta honesta es "depende de la capa de la que estemos hablando".

#Separar qué hace el producto de cómo se presenta

Divido la pregunta en dos preguntas muy distintas que se confunden todo el tiempo: ¿coincide el conjunto de funciones entre plataformas — precios, derechos de la cuenta, contenido, lógica de negocio central — y coincide la presentación — patrón de navegación, gesto, transición, qué affordances nativas usa? La primera casi siempre debería ser idéntica; un usuario que paga premium en iOS y cambia a Android esperando los mismos derechos no es un caso límite, es la expectativa base, y publicar una función en una plataforma seis meses antes que en la otra porque "el equipo de iOS fue más rápido" es una decisión de negocio escondida dentro de lo que parece una decisión de calendario. La segunda casi nunca debería ser idéntica, porque iOS y Android discrepan, a propósito, sobre cómo se ve una buena navegación y unas buenas affordances.

#Una forma de tres niveles para hacer la decisión concreta

Me ha resultado útil clasificar cualquier cuestión de paridad en tres niveles. El nivel uno son los flujos centrales de cara al usuario y la lógica de negocio — checkout, autenticación, estado de la cuenta, derechos — donde la divergencia genera confusión real del usuario y carga de soporte, así que empujo con fuerza por la paridad funcional aunque la implementación subyacente difiera. El nivel dos son las affordances nativas de cada plataforma — navegación hacia atrás, hojas para compartir, acciones de notificación, widgets — donde quiero que la capacidad sea equivalente pero quiero explícitamente que cada plataforma la exprese en su propio idioma, porque pelear contra las convenciones propias del sistema operativo es justo lo que produce esa sensación de "claramente es un port multiplataforma" que los usuarios notan de inmediato. El nivel tres es capacidad genuinamente exclusiva de una plataforma — Live Activities y la Dynamic Island en iOS, la profundidad del ecosistema de widgets de pantalla de inicio y App Shortcuts en Android — donde me parece bien, incluso bueno, publicar de forma desigual, siempre que la experiencia central no deje varados a los usuarios de la plataforma que carece de ella.

#La autenticación biométrica como ejemplo concreto al que recurro

El ejemplo que más uso en entrevistas es el login biométrico. La capacidad subyacente — dejar que el usuario desbloquee la app con su rostro o su huella en lugar de una contraseña — tiene que alcanzar paridad total, porque un usuario no debería perder una función de seguridad por cambiar de teléfono. Pero la implementación es necesariamente específica de cada plataforma: LocalAuthentication/Face ID en iOS frente a BiometricPrompt respaldado por el Keystore de Android, y la interfaz que cada sistema operativo presenta alrededor de ese prompt es distinta por diseño y no debería combatirse. Eso es el nivel uno y el nivel dos conviviendo en la misma funcionalidad: capacidad idéntica, presentación idiomática de cada plataforma.

#Convertirlo en una decisión compartida, no en un unilateral de ingeniería

La paridad es fundamentalmente una decisión de producto, y procuro que el papel de ingeniería sea exponer con claridad el coste real de cada opción, no tomar la decisión en solitario ni dejar que se desvíe en silencio. En la práctica eso significa mantener una matriz de paridad viva — revisada en cada ciclo de planificación, que liste cada funcionalidad con divergencia significativa y por qué — para que "iOS tiene X y Android todavía no" sea una decisión documentada y revisitada, en lugar de un hecho que nadie recuerda haber acordado. Una capa de dominio o lógica de negocio compartida, incluso cuando las capas de UI están completamente separadas por plataforma, es la estructura técnica que hace barata de mantener la paridad de nivel uno, en vez de algo que hay que reverificar a mano en cada release.

#Manejar la presión de "que sea igual y ya"

La objeción que más recibo viene de un stakeholder que vio la pantalla de la otra plataforma y quiere paridad de píxeles en una funcionalidad que legítimamente pertenece al nivel dos o tres. No lo discuto en abstracto — muestro las propias guías de diseño de la plataforma, y pregunto qué problema de usuario concreto está causando de verdad el desajuste, frente a lo que costaría forzar la coincidencia en tiempo de ingeniería y en sentirse ajena para los usuarios de esa plataforma. La mayoría de las veces la queja real es "esto se siente como productos distintos", que es un problema de nivel uno — normalmente terminología inconsistente, arquitectura de información o disponibilidad de funciones — mal diagnosticado como uno visual de nivel dos.