☝? Чтобы уменьшить рассинхрон в релизах на вебе и мобилке, сократить Time to Market, унифицировать интерфейсные решения и сэкономить ресурсы компании. 

Привет! Меня зовут Лена Евгеньева, я продакт-менеджер в ЮMoney. Недавно мы с коллегами решили провести эксперимент — запустить кроссплатформенную разработку, а потом рассказать, что из этого получилось. 

Рассказывать о ходе эксперимента будем по очереди. Я стану первой — посмотрю на кроссплатформу глазами продуктового менеджера. ? А потом своими наблюдениями поделятся коллеги из отделов тестирования, нативной разработки и фронтенда. Так что ждите серию материалов на эту тему. ?

Почему мы вообще решили перейти на кроссплатформенную разработку

Сегодня непростые времена для мобильной разработки — зато очень интересные. Мы вне зоны комфорта и сталкиваемся с новыми задачами, ищем и пробуем новые решения.

Во-первых, сохраняется тенденция на рост доли мобильных пользователей. А наш отдел мобильной разработки сильно меньше, чем отдел веб-разработки с продуктовыми командами. Поэтому, когда какая-либо фича выходит в вебе, может пройти около трёх месяцев, прежде чем она появляется в мобильном приложении. 

Это серьёзный рассинхрон, и нам очень хочется сократить этот интервал в релизах. В идеале — сделать их одновременными, а заодно уменьшить сам релизный цикл и Time to Market. 

Во-вторых, мы стремимся сделать так, чтобы приложение и сайт ЮMoney выглядели для пользователей одинаково. Чем меньше интерфейсы и сценарии взаимодействия с продуктом отличаются друг от друга, тем проще пользователям ориентироваться при переходе с одной платформы на другую. К тому же на вебе становится всё больше мобильных пользователей. Они используют сайт в тех же условиях, что и пользователи мобильного приложения, поэтому делать разные интерфейсы стоит разве что для проведения A/B-исследований.

Мы подумали, что можем решить эти задачи с помощью перехода на кроссплатформенную разработку. 

Какой фреймворк мы выбрали и почему

React Native — это кроссплатформенный фреймворк с открытым исходным кодом для разработки нативных мобильных и настольных приложений на JavaScript и TypeScript. Можно работать с вебом, с платформами Android, iOS, macOS, Windows и не только.

У нас уже были проекты на React Native — с его помощью мы успешно сделали один продукт. Но тогда мы использовали классический подход, при котором общий код разрабатывается только для платформ Android и iOS, а код для веба пишется отдельно. В этот раз хотим прийти к единой кодовой базе. По нашему мнению, это лучше всего отвечает нашим целям: упростить пользовательский опыт, экономить ресурсы и уменьшить время от начала разработки фичи до её выхода на рынок.

Чтобы понять, с какими вызовами и трудностями мы можем столкнуться во время эксперимента, рассмотрим каждую цель по отдельности. 

Цель 1. Синхронизировать циклы жизни продукта на разных платформах

В вебе мы можем делать по 100 релизов в день, и пользователи ничего не заметят. А мобильные релизы мы выкатываем раз в месяц. При этом есть пользователи, которые не сразу обновляются, а кто-то вообще остаётся со старой версией приложения. 

React Native позволяет синхронизировать циклы жизни продукта на разных платформах с учётом различий между вебом и мобильными приложениями. С помощью технологии CodePush можно выпускать небольшие обновления без релиза основного приложения, используя одну кодовую базу. 

Обычно веб существует сам по себе, потому что у него действительно другой жизненный цикл, а кроссплатформенная разработка ведётся отдельно. Это две кодовые базы, нам же нужно уместить продукты с разным циклом обновлений в одной. Вот первый челлендж, который нас ждёт в рамках эксперимента.

Цель 2. Унифицировать интерфейсные решения

Ещё один вызов связан с UX-гайдами платформ. Они везде разные — на вебе, на iOS и на Android. И перед нами стоит задача синхронизировать опыт на этих платформах, причём так изящно, чтобы пользователи ничего не заметили.

Отдельно скажу про десктоп. Мобильная версия вполне может походить на мобильное приложение — у многих компаний уже получилось этого добиться. А вот у десктопной версии сайта своя логика отображения и свои специфические элементы, например различия в использовании мыши с помощью пальца и жестов, выпадающие списки, кнопки и ссылки, различия в навигации и структуре представлений. 

Всё это предстоит учитывать при кроссплатформенной разработке. Многие, кстати, успешно справились с подобными задачами — например, Discord, Facebook, Pinterest, Skype. 

Надеюсь, у нас тоже получится. Конечно, это непросто, ведь текущее пользовательское интерфейсное решение не предназначено для таких изменений. Но интерфейсы всё больше переходят в мобильное пространство, что естественно. Поэтому наша задача — сделать сайт более похожим на приложение, а не наоборот.

Цель 3. Снизить расходы на разработку

Мы надеемся, что сможем сократить не только Time to Market, но и расходы на разработку.

К сожалению, сейчас у нас нет приложений в сторах. Но, когда мы там появимся, на нас может в один момент обрушиться весь бэклог срочных задач и острый дефицит ресурсов, если у нас будет разная кодовая база для веб-версии и мобильного приложения. Фичи, добавленные на вебе за время действия санкций, потребуется быстро реализовывать в приложении. Чтобы этого избежать, мы хотим попробовать единую кодовую базу. 

При этом освоить React Native нам будет гораздо проще, чем Flutter. Он очень похож на то, в чём мы уже разбираемся. 

Сейчас, чтобы присутствовать в сторах с одним продуктом, нам нужно как минимум два мобильных разработчика и один веб-разработчик. Но, как я уже отмечала, в веб-разработке у нас больше людей, и все они пишут на JavaScript или TypeScript, хорошо знают React. Поэтому React Native — подходящее решение.

Цель 4. Сравнить React Native с кроссплатформенным решением на Progressive Web Application

По сути, Progressive Web Applications (PWA) — это веб-сайт, который можно быстро открыть, кликнув по иконке на рабочем столе. Как и приложение, PWA позволяет использовать разные нативные фичи, например считывать QR-код камерой. 

PWA проще и дешевле с точки зрения кроссплатформенной разработки, но одного PWA недостаточно, чтобы приложение компании присутствовало в мобильных сторах. А вот React Native позволит нам иметь в своём арсенале этот канал дистрибуции. 

Поэтому мы хотим развиваться в обоих этих направлениях. Сейчас благодаря PWA наши iOS-пользователи могут с комфортом пользоваться сервисом и не страдать. Другой плюс PWA — независимость от сторов.

Из публикаций об этой технологии и по опыту коллег я знаю, что PWA уже умеет использовать функции мобильных приложений, например пуши и камеру. Но есть и минусы:

• с PWA не работает VPN (это для нас не критично);

• есть проблема с поддержкой фоновых процессов (это для нас уже важнее).

Заключение

Таким образом, нашим экспериментом с React Native движут целых четыре задачи:

• сократить Time to Market и иметь возможность быстрой дистрибуции на разные платформы;

• добиться одинаковых UX и UI;

• экономить ресурсы.

Чтобы следить за ходом эксперимента, подписывайтесь на наш блог.

Пишите в комментариях, был ли у вас опыт кроссплатформенной разработки и к чему это привело. Нам очень интересно. ?