En septiembre del año pasado, lanzamos una actualización importante de Proton Mail para iOS y Android.
En la superficie, las nuevas aplicaciones ofrecen un diseño moderno, mejor rendimiento y capacidades sin conexión, pero hay mucho más de lo que se ve a simple vista. Entre bastidores, las aplicaciones son una reescritura completa de Proton Mail sobre una pila tecnológica novedosa, un proyecto que lleva el nombre interno de Transformación de Ingeniería. El término novedosa es deliberado, porque (hasta donde sabemos) esta ha sido la primera vez que la tecnología elegida se ha utilizado en el contexto de una aplicación de producción establecida.
Este artículo tiene como objetivo arrojar luz sobre el fascinante viaje por el que ha pasado nuestro equipo en la realización de esta revolución, y responder a algunas de las preguntas que nuestra comunidad nos ha hecho en el camino. Ante todo, la razón detrás es la necesidad de cambiar el statu quo.
Cómo empezó todo
La comprensión de que las cosas tenían que cambiar llegó un viernes por la tarde en octubre de 2023. Se materializó con sorprendente claridad, pero no de la nada: fue la culminación de meses pasados tratando de encontrar un denominador común para los problemas aparentemente no relacionados que afectaban la experiencia de nuestros usuarios con los productos móviles de Mail y Calendar.
A riesgo de simplificar demasiado, podemos resumir los puntos débiles en tres áreas:
- Calidad: Mail iOS y Mail Android, tomados de forma aislada, no cumplían con las expectativas en términos de calidad y rendimiento.
- Brecha de funciones entre iOS y Android: Algunas funciones solo estaban disponibles en una plataforma, sin claridad sobre cuándo la otra se pondría al día.
- Velocidad de ingeniería: Las actualizaciones clave y las funciones largamente esperadas no se entregaron de manera oportuna en ambas plataformas.
Algunos de los problemas se extendían más allá del móvil, y responder a esos requeriría una digresión del dominio tecnológico al fascinante espacio problemático de la escala organizacional, y en particular las startups tecnológicas de rápido crecimiento. Pero la fragilidad del ecosistema móvil estaba muy arraigada en la tecnología y la arquitectura.
Escalar la ingeniería móvil
Escalar la ingeniería móvil conlleva un conjunto único de desafíos que son significativamente diferentes de escalar equipos backend y web. Estas diferencias provienen de la fragmentación de la plataforma y las realidades operativas del ecosistema móvil. Los equipos móviles suelen necesitar dar soporte a múltiples plataformas en una variedad de sistemas operativos y dispositivos (teléfonos, tabletas, a veces wearables). iOS y Android vienen con sus propios lenguajes de programación, marcos y herramientas, lo que conduce a grandes cantidades de esfuerzo duplicado: múltiples equipos, bases de código duplicadas y compromisos constantes entre el trabajo específico de la plataforma y el relacionado con el producto. Mantener la oferta de productos sincronizada requiere una enorme cantidad de coordinación.
Lo que es un desafío en toda la industria fue particularmente agudo para Proton. Las aplicaciones de funcionalidad como Mail y Calendar son inherentemente más complejas que la mayoría de las aplicaciones móviles del mercado. Cuando añades encima la capa adicional de lógica del cliente requerida para manejar el cifrado de extremo a extremo, terminas con clientes particularmente “gruesos”. En su día, el equipo de Android estaba ocupado reescribiendo Mail para mejorar los estándares de calidad, una inversión que llevó la mayor parte de 18 meses. iOS también tenía una necesidad imperiosa de reestructuración, por no mencionar Calendar. El coste de la duplicación estaba consumiendo todos nuestros recursos de ingeniería, y quedó claro que no íbamos a tener éxito haciendo más de lo mismo.
Lo mejor de reconocer que estás atascado es que actúa como un factor forzado para pensar fuera de las limitaciones de tu statu quo actual. ¿Qué haríamos si pudiéramos empezar de nuevo, liberados de la carga de las elecciones y compromisos que nos llevaron aquí? Cuando observas más de cerca cómo las empresas exitosas lidiaron con este problema en la década anterior, te das cuenta de que siguieron una de solo dos estrategias posibles:
- Arrojaron dinero al problema, construyendo equipos cada vez más grandes ya que los altos costes operativos se compensaban con una combinación de inversiones sin fondo y/o retornos lujosos. Esta no era una opción para el modelo de negocio libre de capital riesgo de Proton: no podemos competir con el gasto de competidores basados en anuncios y respaldados por inversores.
- Rediseñaron sus aplicaciones para deshacerse del desperdicio, lo que significa construir aplicaciones usando (tanto como sea posible) una base de código compartida.
Siendo la opción 1 inviable, el camino por delante estaba marcado.
Un medio para un fin: elegir la pila tecnológica correcta
El siguiente paso fue elegir una pila tecnológica que realmente pudiera hacer el trabajo.
Durante los últimos 15 años, el desarrollo móvil multiplataforma se ha inundado de soluciones de “talla única”: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform y muchas otras. Cada una llegó con la misma promesa: reemplazar el desarrollo nativo por completo. En la práctica, la mayoría falló por completo o tuvo éxito solo dentro de espacios problemáticos estrictamente limitados. No existe una abstracción universal que haga desaparecer las diferencias de plataforma: cualquiera que haya lanzado y mantenido grandes aplicaciones móviles lo sabe. La única forma fiable de avanzar es trabajar hacia atrás desde requisitos concretos en lugar de hacia adelante desde tendencias de herramientas.
Tradujimos ese objetivo final en un conjunto de requisitos no negociables (1) que cualquier solución elegida tenía que satisfacer, y los usamos como nuestro marco guía a lo largo del proceso de evaluación:
- Costes y plazos: La pila tenía que reducir materialmente el coste y el tiempo requeridos para enviar, mantener y evolucionar Proton Mail en iOS y Android.
- Experiencia de usuario: Tenía que preservar un rendimiento y una calidad de interacción casi nativos; cualquier cosa menos era inaceptable.
- Preparación estratégica para el futuro: La solución tenía que ser duradera. Fuimos intencionales en evitar marcos de terceros que hicieran que nuestra hoja de ruta dependiera del soporte continuo de otro proveedor.
La tensión entre las dos primeras limitaciones es la versión de la industria del santo grial: “Una solución multiplataforma que ofrece el rendimiento y la experiencia de usuario de las aplicaciones nativas.”
Éramos escépticos desde el principio de que React Native o Flutter (los dos marcos multiplataforma dominantes en ese momento) pudieran cumplir con este estándar. Aun así, validamos ese escepticismo construyendo implementaciones de prueba de concepto de la vista de lista de mensajes de Mail.
React Native reveló rápidamente sus limitaciones. Desplazarse por un gran conjunto de datos hizo que el coste de su modelo de ejecución interpretado fuera dolorosamente obvio. Flutter funcionó mejor, pero la interfaz de usuario seguía siendo visiblemente no nativa, especialmente en iOS. Más importante aún, Flutter es un marco propietario controlado por Google, que tiene un historial(ventana nueva) de abandonar tecnologías internas y había despedido recientemente a una gran parte del equipo de Flutter. Para un producto con garantías de seguridad y fiabilidad a largo plazo, ese nivel de dependencia externa era inaceptable.
Kotlin Multiplatform fue el siguiente candidato. Es una opción convincente (particularmente para organizaciones con profunda experiencia en Android), pero finalmente se quedó corta para nuestro caso de uso. La ausencia de una capa de interfaz de usuario compartida, las preguntas sobre la madurez y la sobrecarga adicional introducida por su modelo de ejecución superaron sus beneficios.
En este punto, la conclusión era clara y alineada con nuestra intuición inicial: la única arquitectura que se acerca consistentemente al resultado deseado es una pila deliberadamente mixta. Interfaz de usuario nativa en cada plataforma (Jetpack Compose en Android, SwiftUI en iOS) respaldada por una capa de lógica empresarial compartida escrita en un lenguaje de alto rendimiento y bajo nivel. Este enfoque tiene un historial: Dropbox usó famosamente C++ para compartir la lógica empresarial entre plataformas móviles antes de abandonarlo en 2019 debido al coste operativo y cognitivo del lenguaje.
A finales de 2023, Rust había emergido claramente como el sucesor en el linaje de lenguajes de programación de sistemas.
Rust ocupa el mismo espectro de rendimiento que C++, pero sin muchas de sus responsabilidades históricas. Proporciona fuertes garantías de seguridad de memoria sin recolección de basura, impone concurrencia segura para hilos en tiempo de compilación y está respaldado por un gran ecosistema de código abierto altamente competente. Igual de importante, Rust se integra limpiamente con lenguajes móviles nativos (Swift y SwiftUI en iOS, Kotlin y Jetpack Compose en Android), lo que lo convierte en una opción pragmática para compartir la lógica central sin comprometer la capa de interfaz de usuario.
Esta no fue una decisión libre de riesgos. En ese momento, había pocos ejemplos de aplicaciones móviles orientadas al consumidor a gran escala construidas sobre una arquitectura centrada en Rust, y la experiencia en Rust dentro del equipo era limitada.
Pero la innovación significativa rara vez ocurre en territorio de bajo riesgo. El verdadero desafío no era Rust en sí, sino la inercia organizacional: pasar de enfoques probados y conservadores a la experimentación deliberada, guiada por limitaciones claras y juicio de ingeniería.
El nuevo Proton Mail: resultado y aprendizajes
Avancemos hasta hoy y veamos cómo resultó la apuesta.
El diagrama a continuación representa la arquitectura móvil de Mail. El núcleo de Rust es responsable de la totalidad de la lógica empresarial de la aplicación. Empujamos el uso de Rust más allá de sus aplicaciones habituales (redes, almacenamiento, cálculo algorítmico) hasta el manejo de lógica de navegación compleja. Un ejemplo es la lógica que rige el desplazamiento infinito de la lista de mensajes. Aunque poco ortodoxo, esto resultó clave para lograr nuestro objetivo de maximizar la reutilización de código. Como resultado, casi el 80 % de la base de código ahora se comparte entre iOS y Android.
¿Se tradujo esto en un tiempo de comercialización más rápido y de mayor calidad? Si bien aún es demasiado pronto para un veredicto final, las primeras señales han sido muy alentadoras:
- En los dos meses posteriores al lanzamiento, el equipo logró mantener una cadencia semanal de actualizaciones de funciones en ambas plataformas (un total de 12 lanzamientos de funciones).
- Cerramos las brechas de funciones entre plataformas, trayendo funciones largamente esperadas a Android como pausar, RSVP de calendario y deslizar para el siguiente mensaje.
- Incluso en esta etapa temprana, la nueva base de código ha demostrado ser más estable que las generaciones anteriores en ambas plataformas: la tasa de bloqueos de iOS es del 0,05 % (bajando del 0,12 %), mientras que la de Android ha vuelto a una línea base histórica (0,19 %). Este es un fuerte respaldo a la estabilidad del tiempo de ejecución de Rust.
El soporte también escala de manera más efectiva bajo este enfoque. A menudo es más rápido identificar y resolver una causa raíz única y compartida que perseguir problemas superficialmente similares que surgen de fallos lógicos ligeramente diferentes dispersos en dos bases de código independientes. Encontramos confirmación empírica de lo que había sido previamente una hipótesis de trabajo mientras arreglábamos una clase de problemas de sincronización de categorías que afectaban la lógica que sustenta las capacidades sin conexión de la aplicación: una causa raíz, una solución (representada en el diagrama anterior por el módulo de rebase enviado con la versión 7.6.2).
La otra cara de la moneda
- Es probable que los errores y las regresiones tengan un impacto más amplio y afecten a los usuarios en ambas plataformas. Realmente no puedes tenerlo todo, pero definitivamente puedes mitigar el riesgo sobreindexando en pruebas de extremo a extremo (E2E).
- Al igual que con cualquier división de una solución orientada al usuario a lo largo de una división tecnológica horizontal, existe el riesgo de crear silos de conocimiento y perder algo de enfoque de ingeniería en las experiencias de usuario de extremo a extremo. Debes ser consciente de esto y mitigar intencionalmente el riesgo. Entre las medidas más efectivas:
- Alinear subequipos para entregar funciones en lugar de capas tecnológicas.
- Formar a los ingenieros móviles para que se conviertan en “full stack”, es decir, capaces de depurar, dar soporte e ingeniería tanto en la base de código de Rust como en las plataformas nativas.
Qué sigue para la Transformación de Ingeniería
Desde el principio de este proyecto, estaba claro que lo que estaba en juego se extendía mucho más allá de Proton Mail solamente. Aplicar con éxito esta pila tecnológica a la aplicación insignia de Proton siempre se pensó como el primer paso en un viaje más largo, uno que finalmente vería este enfoque implementado en el resto de nuestro ecosistema móvil.
Ese escenario se está desarrollando ahora. Mientras escribo este artículo, nuestros SDK de Cuenta y Pago, así como la próxima generación de aplicaciones móviles de Proton Calendar, se están reescribiendo en línea con esta nueva dirección técnica.
Esto marca el comienzo de una segunda ola de transformación de ingeniería, una evolución que expande el plan tecnológico con un marco arquitectónico diseñado para facilitar la reutilización de componentes, no solo entre plataformas sino también entre productos. Si bien esta transición no ocurrirá de la noche a la mañana, es fundamental para construir el ecosistema perfectamente integrado y centrado en la privacidad que nuestros clientes esperan que sea Proton.
(1): Simon Lewis,“A strategy for application implementation on multiple platforms”, 2023.
