В условиях перехода значительной доли трафика в мобильные приложения у сетевых ритейлеров возникла необходимость оптимизировать внутренние процессы, сократить расходы и ускорить разработку. О том, как выбрать кроссплатформенную технологию, которая не только позволит сэкономить на разработке и поддержке, но и повысит эффективность приложения, рассказывает Алексей Гладков, технический архитектор «Леруа Мерлен».
Решение переписать флагманское приложение для iOS и Android было связано с дублированием бизнес-логики приложения и устаревшим кодом в предыдущей версии. Затраты на управление росли, и приходилось расширять команду, чтобы поддерживать работоспособность на должном уровне.
Множились задачи и исполнители, но хотелось еще больших результатов, эффективности и скорости. Назрела необходимость в кардинальной смене подхода. Тогда мы и задумались о кроссплатформенном решении с интеграцией пользовательского интерфейса и единым кодом на все платформы.
В процессе поиска рассматривали Flutter, React Native и Kotlin Multiplatform Mobile.
В React Native нам не подошло качество продукта — он очень медленный, особенно при масштабировании. Мы увидели потенциальные ограничения и будущие пробуксовывания, поэтому продолжили поиски.
При изучении Flutter обнаружились две проблемы:
- узкий круг специалистов, знакомых с языком Dart (снова невозможность масштабировать);
- разрывы между регулярно выпускаемыми новыми версиями Android и iOS и реализацией во Flutter, с которыми можно смириться во внутренних приложениях, но никак не в клиентском.
Также исследования показали, что лучше не использовать одинаковый клиентский интерфейс между Android и iOS, так как интерфейсы этих платформ имеют разные принципы управления.
Когда стали изучать Kotlin Multiplatform Mobile, то в первую очередь оценили, что это решение исключает дублирование бизнес-логики, создает клиентские интерфейсы для конкретных платформ в соответствии с рекомендациями и одновременно обеспечивает скорость и качество нативных форм.
Плюсом было и то, что Kotlin является родным языком Android, т. е. не предполагает никаких проблем с поиском и обучением разработчиков. А из-за близости к JVM-языкам потенциально любой kotlin-разработчик может работать с Kotlin и KMM. Это было как раз то, что нужно.
Еще одним преимуществом стало разделение в наших приложениях слоев на UI, Домен и Данные, которое вписывалось в требование схожей архитектуры с модулями и уровнями с идентичной логикой для создания единого кода.
KMM на практике
Сейчас мы не вынесли в KMM пользовательский интерфейс и функции Apple Pay и Google Pay.
Мы используем KMM:
- внутри библиотеки — Ktor, Kotlin Serialization и Coroutines;
- Rx для адаптации платформы (в будущем будут только Coroutines на Android);
- в библиотеке SQLDelight для кэширования API, чтобы увеличить функциональность клиентской корзины без привязки к интернету.
Нюансы, которые обнаружились при использовании Kotlin Multiplatform Mobile:
- наши разработчики iOS потратили приличное количество времени на изучение Gradle, среды разработки и языковых функций;
- сложность тестирования на устройстве;
- сложный процесс контроля качества;
- ошибки в случае возникновения появляются сразу на обеих платформах.
Плюсы КММ:
- единый код, который можно в любое время дописывать и изменять;
- до KMM функция пользовательской корзины требовала примерно 40–60 часов работы для каждой платформы (80–120 часов для обеих), не считая тестирования, с KMM время сократилось для обеих платформ на 50%;
- разделение бизнес-логики между iOS и Android с сохранением собственного кода для каждого клиентского интерфейса;
- любые изменения и корректировки происходят одновременно на обеих платформах.
Еще одна проблема — это локальная сборка артефакта. Если стоит задача добавить зависимость от KMM модуля в качестве зависимости, то это можно сделать через CocoaPods для iOS и через Gradle для Android.
Такой подход увеличивает сложность сборки проектов, но позитивно влияет на эффективность разработчиков iOS, которые не хотят работать с мультиплатформой.
В целом KMM показала себя как стабильная и гибкая технология, которая позволяет сэкономить время и упростить разработку приложения. Все этапы работы, включая тестирование, проходят значительно быстрее, чем при отдельном решении для каждой платформы. Не нужно делать двойную работу, что экономически выгодно для компании. Ну а поддержка других языков означает больше возможностей для развития.