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

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

Встает классический вопрос: какое разрабатывать приложение — нативное, под каждую ОС или единую кроссплатформу?

Привет, я Android-разработчик IT-компании SimbirSoft Владислав. В этой статье расскажу, с какими трудностями мы столкнулись на одном из проектов кроссплатформенной разработки Kotlin Multiplatform (KMP), как команда SimbirSoft с ними справилась и почему кроссплатформа не всегда лучший выбор. Данная статья будет полезна как для разработчиков, так и для предпринимателей, которые решили создать мобильное приложение для своего бизнеса и думают над выбором технологии. 

Особенности Kotlin Multiplatform

Kotlin Multiplatform (KMP) в последние годы набирает популярность и успешно конкурирует с другими средствами кроссплатформенной разработки.

KMP позволяет создать общий модуль на языке Kotlin, который можно скомпилировать под каждую платформу. В такой модуль обычно помещаются общие механизмы, которые будут одинаково работать на всех устройствах независимо от операционной системы, например, сетевые запросы API, бизнес-логика, утилиты. Отдельно под каждую платформу требуется разрабатывать только слой представления (presentation или view), сохраняя все особенности пользовательского опыта каждой платформы.

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

К чему нужно быть готовым на старте работы с Kotlin Multiplatform

Перед началом разработки приложения на Kotlin Multiplatform владельцам бизнеса важно обратить внимание на несколько деталей:

1. Команда

В первую очередь, конечно, нужно подумать о составе команды разработчиков и очередности их включения в проект. Так как общий модуль и Android-версия приложения пишется на языке Kotlin, разумно поручить обе задачи одной команде. Таким образом, Android-разработчиков должно быть априори больше, так как сфера их ответственности выше. При этом, если в проекте используется подход DDD (domain-driven development), то разработка любой из платформ затруднительна, либо невозможна вовсе без бизнес-логики общего модуля.

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

2. Версионность

Не секрет, что разработка новых программных механик в приложении может добавлять, удалять и менять некоторые значимые части бизнес-логики. При несовпадении релизных версий обеих платформ возникает сложность: если добавление новой механики может не повлиять на старый функционал, то удаление и тем более изменения повлекут за собой ошибки на отстающей платформе. Конечно, выходом в таких случаях является сохранение существующих механик и добавление новых под конкретную задачу. Это решит основную проблему, но одновремено создаст новую — появится избыточный код, который рано или поздно может «выстрелить» ошибкой при очередном апдейте платформы.

3. Доступность кода

Для iOS-разработчиков сложностью является работа не только с платформенным языком программирования Swift или Objective-C, но и с языком Kotlin, на котором написан общий модуль и к которому также важно обращаться. То есть такому разработчику всегда нужно иметь на рабочем компьютере не только свою основную IDE XCode, но и Android Studio, уметь читать и дебажить код сразу на двух языках.

Однако поиск iOS-разработчиков со знанием Kotlin также накладывает дополнительные ограничения на проект, тем самым удорожая его.

Как нивелировать эти трудности?

Как вы могли понять, решение описанных задач почти полностью зависит от аппарата управления проектом и применяемых менеджерских механик. 

Точность планирования и составления плановой документации поможет решить проблему состава и распределения команды. Например, диаграмма Ганта. 

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

Решить проблему версионности также можно с помощью верно выбранной методологии планирования и грамотного распределения рабочей силы на проекте. Хранение KMP-модуля в отдельном репозитории тоже положительно сказывается на успешности разработки, как минимум, разгружает репозиторий от изменений со стороны Android-платформы.

Все эти пункты команда SimbirSoft выделила при работе над проектом одного из наших крупнейших клиентов. 

С чем мы столкнулись на проекте

Команда SimbirSoft взяла в работу проект, который уже находился в продакшене и на стадии поддержки, в также имел большой показатель уникальных пользователей в сутки (DAU). Подключившись к проекту, мы провели аудит процессов и кодовой базы, после чего обновили документацию, привели в порядок систему управления рабочим процессом, сформировали команда разработчиков.

Далее мы работали непосредственно над приложением:

• Провели полный рефакторинг приложения: выстроили структуру проекта, привели все компоненты к единому шаблону, удалили проблемные проектные решения и заменили их на новые. 

• Очень плотно работали с отделом дизайна и аналитики для обработки тех трудностей и ошибок, которые возникали у пользователей. 

• Выделили KMP-модуль в отдельный репозиторий, выстроили график релизов и систему версионности приложения по принципу семантического версионирования. 

• Для обозначения версий в системе Git использовали теги. 

• На площадке-хостинге репозиториев посредством pipelines настроили CI/CD для облачной сборки и публикации очередной версии общего модуля. После этого он становился доступным к подключению в мобильный проект в качестве библиотеки зависимости. 

Только после такого большого объема проделанной работы по приведению проекта в порядок, мы приступили к выполнению бизнес-задач.

Всего меньше чем за год (а это небольшой срок для проекта такого масштаба) мы восстановили и дали развитие проекту. На данный момент, у приложения на обеих мобильных платформах повысилась стабильность до 99.8%, вырос показатель DAU, а также рейтинг на площадках, клиент получает большое количество положительных отзывов.

Команде разработчиков стало гораздо проще и приятнее  создавать новые фичи, исправлять баги проводить анализ и оптимизацию.

Подведем итог

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

Если это небольшое приложение, визитка, акция, программа лояльности, возможно сезонное приложение, которое нужно сделать быстро, красиво и оно не нацелено на выполнение больших долгосрочных задач, то разработка на Kotlin Multiplatform полностью оправдает свои затраты.

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

Спасибо за внимание!

Больше авторских материалов для mobile-разработчиков от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.