Почему наши клиенты приходят за разработкой на Kotlin Multiplatform Mobile: нативный UI и возможности развития

В предыдущих статьях серии мы уже рассказали о том, как снизить риски в iOS-разработке в условиях санкций с помощью Kotlin Multiplatform Mobile. Сегодня перейдем от теории к практике: расскажем, как создали на KMM приложение для поиска автомоек «Мойка-мойка» для Ucar и что это дало нашему клиенту.

Почему наши клиенты приходят за разработкой на Kotlin Multiplatform Mobile: нативный UI и возможности развития

Что хотел клиент

Приложение создавали для Ucar — маркетплейса автомоек. Ранее мы уже работали с Ucar, поэтому клиент был знаком с нашим подходом к работе и пришел к нам целенаправленно за KMM, рассчитывая создать две версии приложения: на Android и iOS.

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

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

Что внедрили в приложение для удобного поиска автомоек

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

  1. «Мойка-мойка» показывает автомойки на карте со всей необходимой информацией: временем работы, ценами, акциями, загруженностью моек.
  2. Приложение подбирает тарифы в зависимости от того, работает человек в такси или собирается помыть собственную машину.
  3. Оплатить услугу можно сразу в приложении. При этом, когда владелец авто приезжает на автомойку, сотрудники определяют клиента по номеру машины и уже знают, какие виды услуг должны оказать.
  4. В приложении можно добавить несколько машин, чтобы для каждой подобрать оптимальный вариант. Цены на услуги для легковых и крупногабаритных автомобилей отличаются — это удобно, когда у водителя несколько авто.
Процесс выбора услуги в «Мойке-мойке» похож на заказ такси: нужно выбрать комплекс услуг, тариф и перейти к оплате
Процесс выбора услуги в «Мойке-мойке» похож на заказ такси: нужно выбрать комплекс услуг, тариф и перейти к оплате
В приложении можно получить скидку по промокоду
В приложении можно получить скидку по промокоду

Как создавали приложение «Мойка-мойка»

Разработку начали с нуля. Задача была несложная, поэтому в создании участвовал один разработчик и тимлид. Для ускорения реализации мы использовали наши библиотеки МОКО. Мы регулярно создаем и дополняем opensource-библиотеки KMM, чтобы расширить возможности их применения для конкретных задач.

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

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

В какие сроки уложились

Первый старт MVP-приложения занял два месяца. При этом общий срок работ над проектом составил семь месяцев.

Работа шла в рамках двухнедельных спринтов по Agile. Начало спринта — постановка, распределение задач, созвоны раз в два дня с вопросами или предварительным результатом. Конец спринта — отгрузка сборок, фидбек по доработкам.

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

Релиз приложения состоялся летом 2021 года. На данный момент Ucar сотрудничает с большим количеством таксопарков и получает много положительных отзывов о приложении. А мы занимаемся поддержкой и модернизацией приложения.

Почему использовали KMM

KMM сочетает в себе две возможности: она позволяет писать код сразу под обе платформы и при этом реализовать полностью нативный UI. То есть приложение будет выглядеть именно так, как задумал дизайнер, или именно так, как привычно пользователям той или иной платформы. Эта особенность KMM позволила использовать заранее подготовленный клиентом дизайн для приложения «Мойка-мойка».

Что в итоге получил клиент благодаря KMM

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

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

Поэтому мы и наши клиенты так любим КММ: это надежная база для разработки сложного проекта. Из-за того, что один код пишется сразу под iOS и Android, в краткосрочной перспективе есть экономия по сравнению с нативной разработкой за счет общей логики. А в долгосрочной перспективе будет экономия трудозатрат на доработку приложения.

Kotlin Multiplatform Mobile была, есть и будет: читайте нашу статью о том, почему уход JetBrains (создателей KMM) из России не остановит мультиплатформенную разработку.

Мы будем рады проконсультировать команды и бизнес по вопросам разработки мобильных приложений с Kotlin Multiplatform Mobile, а также готовы присоединиться к разработке. Написать нам можно на этой странице.

В следующей статье мы расскажем, как перейти на KMM, если у вас уже есть приложение. Подписывайтесь на наш телеграм-канал, чтобы не пропустить!

1010
3 комментария

Спасибо за статью, не так давно слежу за КММ, но всё же назрел вопрос. Забабахали вы сторону андроида и мультиплатформенную логику, ios пока остался в стороне, затем придет клиент и скажет - пилим ios!
Собственно сам вопрос в том, а не будет ли потом этот самый ios разраб страдать из-за того, что в прошлом нативный разраб, а ныне мультиплатформенный котлинист, прикрутил мультиплатформу так, что её использование будет удобно только андроиду? Есть же согласованность между разработчиками как в описанном вами случае, что например, так делаем, а так не делаем, по тому что.... на стороне ios?

Такие ситуации мы, на самом деле, действительно довольно часто ловили на первых проектах, когда ещё обкатывали технологию. Это работало в обе стороны - андроидщики ломали iOS, айосники ломали андроид.
Об этом говорили вот тут вот на докладе: https://www.youtube.com/watch?v=h9ioWnSlUJc (примерно с 6:40).
Поэтому мы вывели определённый набор правил и стандартов, которых придерживаемся у нас при разработке. Они помогают унифицировать подходы по взаимодействию нативных приложений с common-кодом без ущерба какой-либо из платформ. Так что сейчас вероятность таких поломок сведена к минимуму

2