В сентябре прошлого года мы запустили крупное обновление Proton Mail для iOS и Android.
Внешне новые приложения предлагают современный дизайн, лучшую производительность и возможность работы офлайн — но это гораздо больше, чем кажется на первый взгляд. За кулисами эти приложения представляют собой полную переработку Proton Mail на новом технологическом стеке, проект, который внутри компании называется Engineering Transformation. Термин новый использован намеренно, потому что — насколько нам известно — это первый случай использования выбранной технологии в контексте устоявшегося производственного приложения.
Эта статья призвана пролить свет на увлекательный путь, который прошла наша команда при создании этой революции, и ответить на некоторые вопросы, которые задавало нам наше сообщество на этом пути. Прежде всего, обоснованием является необходимость изменить статус-кво.
Как все началось
Осознание того, что все нужно менять, пришло в пятницу вечером в октябре 2023 года. Оно материализовалось с удивительной ясностью, но не на пустом месте: это была кульминация месяцев, потраченных на поиск общего знаменателя для казалось бы не связанных проблем, влияющих на опыт наших пользователей с мобильными продуктами Почты и Календаря.
Рискуя чрезмерно упростить, мы можем свести болевые точки к трем областям:
- Качество: Почта на iOS и Android, взятые по отдельности, не оправдывали ожиданий с точки зрения качества и производительности.
- Разрыв в функциях между iOS и Android: Некоторые функции были доступны только на одной платформе, без ясности, когда другая их получит.
- Скорость разработки: Ключевые обновления и долгожданные функции не доставлялись своевременно на обе платформы.
Некоторые из проблем выходили за рамки мобильных устройств, и ответ на них потребовал бы отступления от технологической области в увлекательное пространство проблем организационного масштабирования, и в частности быстрорастущих технологических стартапов. Но хрупкость мобильной экосистемы была очень сильно укоренена в технологиях и архитектуре.
Масштабирование мобильной разработки
Масштабирование мобильной разработки связано с уникальным набором проблем, которые существенно отличаются от масштабирования бэкенд- и веб-команд. Эти различия проистекают из фрагментации платформ и операционных реалий мобильной экосистемы. Мобильным командам обычно необходимо поддерживать несколько платформ на множестве операционных систем и устройств (телефоны, планшеты, иногда носимые устройства). iOS и Android поставляются со своими языками программирования, фреймворками и инструментами, что приводит к большому объему дублирующихся усилий: несколько команд, дублирующиеся кодовые базы и постоянные компромиссы между специфической для платформы и продуктовой работой. Поддержание синхронности продуктового предложения требует огромного количества координации.
То, что является общеотраслевой проблемой, было особенно остро для Proton. Функциональные приложения, такие как Почта и Календарь, по своей сути сложнее большинства мобильных приложений на рынке. Когда вы добавляете сверху дополнительный слой клиентской логики, необходимый для обработки сквозного шифрования, вы получаете особенно «толстые» клиенты. В свое время команда Android была занята переписыванием Почты для улучшения стандартов качества — инвестиция, которая заняла большую часть 18 месяцев. iOS также остро нуждалась в перестройке архитектуры, не говоря уже о Календаре. Стоимость дублирования съедала все наши инженерные ресурсы, и стало ясно, что мы не добьемся успеха, делая больше того же самого.
Лучшее в признании того, что вы застряли, — это то, что это действует как фактор, заставляющий мыслить за пределами ограничений вашего текущего статус-кво. Что бы мы сделали, если бы могли начать заново, освободившись от бремени выбора и обязательств, которые привели нас сюда? Когда вы внимательнее посмотрите, как успешные компании решали эту проблему в предыдущем десятилетии, вы поймете, что они следовали одной из двух возможных стратегий:
- Они забрасывали проблему деньгами, создавая все более крупные команды, поскольку высокие операционные расходы компенсировались сочетанием бездонных инвестиций и/или щедрых доходов. Это не было вариантом для бизнес-модели Proton без венчурного капитала: мы не можем конкурировать с расходами конкурентов, поддерживаемых рекламой и инвесторами.
- Они перепроектировали свои приложения, чтобы избавиться от потерь, то есть создавали приложения, используя (насколько это возможно) общую кодовую базу.
Поскольку вариант 1 был невозможен, путь вперед был определен.
Средство для достижения цели: выбор правильного технологического стека
Следующим шагом был выбор технологического стека, который действительно мог бы выполнить эту работу.
За последние 15 лет кроссплатформенная мобильная разработка была наводнена решениями «один размер подходит всем»: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform и многими другими. Каждое из них приходило с одним и тем же обещанием — полностью заменить нативную разработку. На практике большинство либо полностью провалились, либо преуспели только в жестко ограниченных проблемных пространствах. Не существует универсальной абстракции, которая заставляет различия платформ исчезнуть: любой, кто выпускал и поддерживал крупные мобильные приложения, знает это. Единственный надежный путь вперед — идти от конкретных требований, а не от трендов инструментов.
Мы перевели эту конечную цель в набор обязательных требований (1), которым должно было удовлетворять любое выбранное решение, и использовали их в качестве нашей руководящей структуры на протяжении всего процесса оценки:
- Затраты и сроки: Стек должен был существенно сократить затраты и время, необходимые для выпуска, поддержки и развития Proton Mail на iOS и Android.
- Пользовательский опыт: Он должен был сохранить почти нативную производительность и качество взаимодействия — что-то меньшее было невозможно.
- Стратегическая защита будущего: Решение должно было быть долговечным. Мы намеренно избегали сторонних фреймворков, которые сделали бы нашу дорожную карту зависимой от постоянной поддержки другого поставщика.
Напряжение между первыми двумя ограничениями — это отраслевая версия святого грааля: «Кроссплатформенное решение, которое обеспечивает производительность и пользовательский опыт нативных приложений».
Мы с самого начала скептически относились к тому, что React Native или Flutter — два доминирующих кроссплатформенных фреймворка того времени — смогут соответствовать этой планке. Тем не менее, мы проверили этот скептицизм, создав концептуальные реализации просмотра списка сообщений Почты.
React Native быстро выявил свои ограничения. Прокрутка большого набора данных сделала стоимость его интерпретируемой модели выполнения болезненно очевидной. Flutter работал лучше, но пользовательский интерфейс оставался явно ненативным, особенно на iOS. Что еще более важно, Flutter — это проприетарный фреймворк, контролируемый Google, который имеет историю(новое окно) отказа от собственных технологий и недавно уволил значительную часть команды Flutter. Для продукта с гарантиями долгосрочной безопасности и надежности такой уровень внешней зависимости был неприемлем.
Kotlin Multiplatform был следующим кандидатом. Это привлекательный вариант — особенно для организаций с глубокой экспертизой в Android — но в конечном итоге он не подошел для нашего случая использования. Отсутствие общего слоя пользовательского интерфейса, вопросы зрелости и дополнительные накладные расходы, вносимые его моделью выполнения, перевесили преимущества.
В этот момент вывод был ясен и соответствовал нашей первоначальной интуиции: единственная архитектура, которая стабильно приближается к желаемому результату, — это намеренно смешанный стек. Нативный пользовательский интерфейс на каждой платформе — Jetpack Compose на Android, SwiftUI на iOS — поддерживаемый общим слоем бизнес-логики, написанным на высокопроизводительном низкоуровневом языке. У этого подхода есть история: Dropbox известно использовал C++ для обмена бизнес-логикой между мобильными платформами, прежде чем отказаться от него в 2019 году из-за эксплуатационной и когнитивной стоимости языка.
К концу 2023 года Rust явно выделился как преемник в ряду языков системного программирования.
Rust занимает ту же нишу производительности, что и C++, но без многих его исторических недостатков. Он обеспечивает надежные гарантии безопасности памяти без сборки мусора, обеспечивает потокобезопасную параллельность во время компиляции и поддерживается большой, высококомпетентной экосистемой с открытым исходным кодом. Что не менее важно, Rust чисто интегрируется с нативными мобильными языками — Swift и SwiftUI на iOS, Kotlin и Jetpack Compose на Android — что делает его прагматичным выбором для обмена основной логикой без ущерба для слоя пользовательского интерфейса.
Это не было решение без риска. В то время было мало примеров масштабных мобильных приложений, ориентированных на потребителя, построенных на архитектуре, ориентированной на Rust, а опыт работы с Rust в команде был ограничен.
Но значимые инновации редко происходят на территории с низким риском. Настоящим вызовом был не сам Rust, а организационная инерция — переход от проверенных, консервативных подходов к преднамеренным экспериментам, руководствуясь четкими ограничениями и инженерным суждением.
Новый Proton Mail: результат и выводы
Давайте перенесемся в сегодняшний день и посмотрим, как сыграла эта ставка.
Диаграмма ниже представляет архитектуру мобильной Почты. Ядро Rust отвечает за всю бизнес-логику приложения. Мы расширили использование Rust за пределы его обычных применений (сеть, хранение, алгоритмические вычисления) вплоть до обработки сложной логики навигации. Примером может служить логика, управляющая бесконечной прокруткой списка сообщений. Хотя это и нетрадиционно, это оказалось ключевым для достижения нашей цели максимизации повторного использования кода. В результате почти 80% кодовой базы теперь является общей для iOS и Android.
Привело ли это к более быстрому и качественному выводу на рынок? Хотя еще слишком рано для окончательного вердикта, первые признаки были очень обнадеживающими:
- За два месяца после релиза команде удалось поддерживать еженедельный темп обновлений функций на обеих платформах (всего 12 релизов функций).
- Мы закрыли разрывы в функциях между платформами, добавив долгожданные функции на Android, такие как откладывание, ответ на приглашение календаря и свайп к следующему сообщению.
- Даже на этом раннем этапе новая кодовая база оказалась более стабильной, чем предыдущие поколения на обеих платформах: уровень сбоев iOS составляет 0,05% (снижение с 0,12%), в то время как Android вернулся к историческому базовому уровню (0,19%). Это сильное подтверждение стабильности работы Rust.
Поддержка также масштабируется более эффективно при таком подходе. Часто быстрее определить и устранить одну общую первопричину, чем гоняться за поверхностно похожими проблемами, возникающими из-за немного разных логических недостатков, разбросанных по двум независимым кодовым базам. Мы нашли эмпирическое подтверждение тому, что ранее было рабочей гипотезой, исправляя класс проблем синхронизации категорий, влияющих на логику, лежащую в основе офлайн-возможностей приложения: одна первопричина, одно решение — представленное на диаграмме выше модулем перебазирования, выпущенным с версией 7.6.2.
Другая сторона медали?
- Ошибки и регрессии, вероятно, будут иметь более широкое влияние и затронут пользователей на обеих платформах. Вы не можете получить все сразу — но вы определенно можете смягчить риск, переиндексируя сквозное (E2E) тестирование.
- Как и при любом разделении ориентированного на пользователя решения по горизонтальному технологическому разделению, существует риск создания изолированных знаний и потери некоторого инженерного фокуса на сквозном пользовательском опыте. Вы должны знать об этом и намеренно смягчать риск. Среди наиболее эффективных мер:
- Согласуйте подкоманды для доставки функций, а не технологических слоев.
- Обучайте мобильных инженеров становиться «фулстек», то есть способными выполнять отладку, поддержку и проектирование как в кодовой базе Rust, так и на нативных платформах.
Что дальше для Engineering Transformation
С самого начала этого проекта было ясно, что ставки выходят далеко за рамки только Proton Mail. Успешное применение этого технологического стека к флагманскому приложению Proton всегда задумывалось как первый шаг в более длительном путешествии — том, которое в конечном итоге увидит этот подход развернутым по всей остальной нашей мобильной экосистеме.
Этот сценарий сейчас разворачивается. Пока я пишу эту статью, наши SDK для аккаунтов и платежей, а также следующее поколение мобильных приложений Proton Calendar переписываются в соответствии с этим новым техническим направлением.
Это знаменует начало второй волны инженерной трансформации — эволюции, которая расширяет технологический план архитектурным фреймворком, разработанным для упрощения повторного использования компонентов не только между платформами, но и между продуктами. Хотя этот переход не произойдет в одночасье, он является фундаментальным для создания бесшовно интегрированной экосистемы, ориентированной на конфиденциальность, которую наши клиенты ожидают от Proton.
(1): Саймон Льюис,“Стратегия реализации приложений на нескольких платформах”, 2023.
