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. Detrás de escena, las aplicaciones son una reescritura completa de Proton Mail sobre una pila de tecnología novedosa, un proyecto que lleva el nombre interno de Transformación de Ingeniería. El término novedoso es deliberado, porque, hasta donde sabemos, esta ha sido la primera vez que se utiliza la tecnología elegida en el contexto de una aplicación de producción establecida.
Este artículo tiene como objetivo arrojar luz sobre el fascinante viaje que nuestro equipo ha atravesado en la realización de esta revolución, y responder a algunas de las preguntas que nuestra comunidad nos ha hecho en el camino. Primero y ante todo, la razón fundamental detrás es la necesidad de cambiar el status quo.
Cómo empezó todo
La comprensión de que las cosas debían cambiar llegó un viernes por la noche en octubre de 2023. Se materializó con sorprendente claridad, pero no de la nada: fue la culminación de meses dedicados a tratar 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 Calendario.
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 cumplieron 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 extendieron más allá del móvil, y responder a ellos requeriría una digresión del dominio de la tecnología al fascinante espacio de problemas del escalado organizacional, y en particular de las start-ups tecnológicas de rápido crecimiento. Pero la fragilidad del ecosistema móvil estaba muy arraigada en la tecnología y la arquitectura.
Escalado de 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 de backend y web. Estas diferencias se derivan de la fragmentación de la plataforma y las realidades operativas del ecosistema móvil. Los equipos móviles generalmente necesitan 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 lleva 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 Calendario son inherentemente más complejas que la mayoría de las aplicaciones móviles en el mercado. Cuando agrega encima la capa adicional de lógica del cliente requerida para gestionar el cifrado de extremo a extremo, termina 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 tomó la mayor parte de 18 meses. iOS también necesitaba urgentemente una reestructuración, por no mencionar Calendario. El costo 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á atascado es que actúa como un factor forzoso para pensar fuera de las limitaciones de su status 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 echa un vistazo más detenido a cómo las empresas exitosas lidiaron con este problema en la década anterior, se da 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 costos 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 de riesgo de Proton: no podemos competir con el gasto de los competidores respaldados por inversores y basados en anuncios.
- Reingenierizaron sus aplicaciones para deshacerse del desperdicio, lo que significa construir aplicaciones utilizando (tanto como sea posible) una base de código compartida.
Con la opción 1 siendo inviable, la ruta por delante estaba establecida.
Un medio para un fin: elegir la pila tecnológica adecuada
El siguiente paso fue elegir una pila tecnológica que realmente pudiera hacer el trabajo.
En los últimos 15 años, el desarrollo móvil multiplataforma se ha inundado con 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 de problemas estrictamente limitados. No existe una abstracción universal que haga desaparecer las diferencias de plataforma: cualquiera que haya enviado y mantenido grandes aplicaciones móviles lo sabe. La única forma confiable de avanzar es trabajar hacia atrás desde requisitos concretos en lugar de hacia adelante desde las 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 durante todo el proceso de evaluación:
- Costos y plazos: La pila tenía que reducir materialmente el costo y el tiempo requeridos para enviar, mantener y evolucionar Proton Mail en iOS y Android.
- Experiencia de usuario: Tenía que preservar el rendimiento casi nativo y la calidad de interacción; cualquier cosa menos era inviable.
- Preparación estratégica para el futuro: La solución tenía que ser de larga duración. 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 restricciones 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. Aún 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 a través de un gran conjunto de datos hizo que el costo 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(nueva ventana) 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 confiabilidad 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 estaba 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 de negocios compartida escrita en un lenguaje de bajo nivel y alto rendimiento. Este enfoque tiene un historial: Dropbox usó famosamente C++ para compartir la lógica de negocios a través de plataformas móviles antes de abandonarlo en 2019 debido al costo operativo y cognitivo del lenguaje.
A finales de 2023, Rust había emergido claramente como el sucesor en el linaje de los lenguajes de programación de sistemas.
Rust ocupa la misma envoltura 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 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 a gran escala orientadas al consumidor 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 hacia una experimentación deliberada, guiada por restricciones claras y juicio de ingeniería.
El nuevo Proton Mail: resultados y aprendizajes
Avancemos hasta hoy y veamos cómo resultó la apuesta.
El siguiente diagrama representa la arquitectura móvil de Mail. El núcleo de Rust es responsable de la totalidad de la lógica de negocios 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. Si bien es poco ortodoxo, esto demostró ser 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 en 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 fallos 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 fallas lógicas ligeramente diferentes dispersas en dos bases de código independientes. Encontramos confirmación empírica de lo que anteriormente había sido una hipótesis de trabajo mientras solucioná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 Rebasing 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 puede tenerlo todo, pero definitivamente puede mitigar el riesgo indexando en exceso las 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 cierto enfoque de ingeniería en las experiencias de usuario de extremo a extremo. Debe ser consciente de esto y mitigar intencionalmente el riesgo. Entre las medidas más efectivas:
- Alinear sub-equipos para entregar funciones en lugar de capas tecnológicas.
- Capacitar 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 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 tuvo la intención de ser 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 ahora se está desarrollando. 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 de acuerdo 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 a través de plataformas sino también a través de 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,“Una estrategia para la implementación de aplicaciones en múltiples plataformas”, 2023.
