Кроссплатформа для мобильного приложения: как ускорить и удешевить разработку?

Алексей Гладков

Технический архитектор «Леруа Мерлен»

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

У компании уже были мобильные приложения для iOS и Android, но дублирование логики домена, устаревший код и огромные затраты на поддержку обеих платформ создавали множество проблем. Чтобы повысить управляемость, гибкость и рентабельность, мы решили всё переписать. Специалистов у нас было меньше, чем обычно в команде разработчиков мобильных приложений в нашей отрасли, а это означало, что внедрение изменений займёт больше времени.

Представлялось два варианта ускорить процесс:

• нанять больше людей;
• использовать технологию, которая позволит объединить платформы iOS и Android.

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

React Native уже использовался в других приложениях, поэтому эта технология в первую очередь попала в число претендентов. Но React Native не оправдал наших ожиданий из-за качества итогового продукта. Можно было бы создать приложение с использованием Flutter, но возникли проблемы:

• на тот момент было мало специалистов, которые знают Dart;
• уже была команда, которая писала нативно;
• Android и iOS регулярно выпускают новые версии и UX-паттерны, и между нативным выпуском и его реализацией Flutter будет разрыв.

Дальнейшие исследования показали, что лучше не использовать общий пользовательский интерфейс между мобильными платформами. Android и iOS имеют разные принципы руководства пользовательским интерфейсом, и для поддержки общего UI иногда требуется больше времени, чем занимает отдельная разработка.

Требовалось кроссплатформенное решение. Узнав про Kotlin Multiplatform Mobile, мы поняли, что это тот самый подход. Технология исключает дублирование бизнес-логики, обеспечивая производительность и безопасность собственного пользовательского интерфейса.

Использование Kotlin в продукте

Тестирование подхода KMM мы начали в тех частях приложения, которые использовались реже — это, например, соглашения с клиентами и формы обратной связи. Важно было понять, не возникнут ли проблемы, связанные с библиотекой.

В нашем приложении есть два типа запросов: с авторизацией и без. Запросы с авторизаций — самая сложная часть, поэтому мы начали экспериментировать с запросами, которые не требовали ни авторизации, ни работы с базой данных. В процессе переписывания модулей с самого начала разрабатывались новые пользовательские сценарии с KMM. Но и существующие были перенесены в KMM.

Перед написанием мультиплатформенного кода приложения для iOS и Android должны иметь схожую архитектуру с модулями или уровнями, имеющими идентичную логику. В наших приложениях было подобное разделение слоев:

• UI (презентация);
• домен (уровень бизнес-логики);
• дата (уровень источника данных).

Сначала мы ограничивались перемещением уровня данных, но затем стали перемещать всё остальное, включая бизнес-логику приложения. Единственные части KMM, которые мы не используем, — это пользовательский интерфейс и специфичные для платформы функции, такие как Apple и Google Pay.

Внутри библиотеки мы используем Ktor, Kotlin Serialization и Coroutines. Оболочка Rx применяется для адаптации платформы, но в будущем планируем использовать только Coroutines на Android и, если будет возможность использовать Async\Await на стороне iOS

Чтобы перенести функциональность корзины пользователя нужно было кэшировать данные с API и мы начали использовать библиотеку SQLDelight. Выполнив эту задачу, начали переносить в KMM более сложные функции приложения.

Достоинства и недостатки КММ

Недостатки, которые обнаружились при использовании Kotlin Multiplatform Mobile:

• нашим разработчикам iOS пришлось потратить много времени на изучение Gradle, среды разработки и языковых функций;
• сложнее тестировать на устройстве, сложный контроль качества.

Далее выявленные достоинства.

• До KMM основные функции типа корзины требовали 40-60 часов работы для каждой платформы (80-120 часов для обеих), не считая тестирования. С помощью KMM мы можем сократить временные рамки до 50-70 часов для обеих платформ.
• Мы разделяем только бизнес-логику между платформами и используем собственный код для каждого пользовательского интерфейса. Такой подход обеспечивает максимальную производительность при минимальном количестве шаблонного кода.
• Легкий наём и поддержка — KMM работает на Kotlin, которым владеют большинство разработчиков Android. А из-за близости к JVM-языкам любой backend-разработчик теоретически может работать с Kotlin и KMM.
• Идентичная логика на обеих платформах значительно снижает расхождения, а значит, удешевляет разработку и поддержку.