Kotlin Multiplatform / Сэкономить бюджет и ускорить разработку: переход на Kotlin Multiplatform Mobile

Сэкономить бюджет и ускорить разработку: переход на Kotlin Multiplatform Mobile

Kotlin Multiplatform Mobile — мультиплатформенный инструмент, который позволяет не только создавать общий код для приложения на iOS и Android, но и сэкономить до трети бюджета и ускорить разработку на 25%. Но что, если у вас уже есть проект и вы хотите перейти на KMM? Рассказываем в статье, какие виды переходов на мультиплатформу стоят 100 тыс. рублей, 500 тыс. рублей и 3 млн рублей.

Когда стоит внедрить KMM

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

  1. У вас есть приложение или вы только начали его разрабатывать, и его будут использовать на разных платформах: Android и iOS.
  2. У вашего приложения с Android- и iOS-версиями сложная бизнес-логика при простом UI. Например, при офлайн-синхронизации.
  3. У вас есть Android-приложение на Kotlin, но вам срочно нужно выпустить версию на iOS c переиспользованием того, что уже сделано.

60% — столько разработчиков используют или хотя бы пробовали в продакшене Kotlin Multiplatform, согласно недавно опубликованному опросу JetBrains.

Что даст внедрение KMM

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

Вы ускорите разработку на 25% и в перспективе получите возможность быстрее и легче внедрять новые функции сразу на двух платформах.

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

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

Возможно, именно поэтому 75% тех, кто когда-либо пробовал Kotlin Multiplatform ради интереса, собираются использовать ее в настоящих проектах.

Как происходит переход на KMM

Сценарий перехода на KMM зависит от текущей ситуации в вашем проекте. Условно можно выделить три сценария. Покажем их на примере наших кейсов.

Сценарий 1. У вас есть приложение на обеих платформах, и вам нужна помощь экспертов, чтобы сделать общую бизнес-логику

За таким видом переноса к нам обратились ребята из «Профи».

«Профи» — приложение для поиска специалистов из разных областей. Работает на iOS и Android. Заказчик попросил помочь перенести бизнес-логику из Android-приложения на мультиплатформу.

Как шел процесс:

  1. Подписали NDA.
  2. Проанализировали проект.
  3. Составили индивидуальный план внедрения KMM.
  4. Клиент начал по плану перетаскивать бизнес-логику в общий код.

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

План для этого проекта состоял из следующих шагов:

  1. Настроить поддержку Kotlin Multiplatform в gradle-модуле.
  2. Перенести платформенно-независимые классы в commonMain.
  3. Заменить библиотеки JVM/Android на мультиплатформенные аналоги.
  4. Перенести в commonMain JVM-зависимый код, который требует изменений.
  5. Перенести в commonMain Android-зависимый код, который требует изменений.
  6. Сделать публичные интерфейсы компонентов общей логики удобными для обеих платформ.

Дальше команда «Профи» сама смогла использовать результаты этого ревью в своей работе и подробно описала процесс на «Хабре» в шаге 3.

Сценарий 2. Ваша команда успешно опробовала KMM, и вам нужна только консультация экспертов

Такой вид работы у нас сложился с зарубежным сервисом для просмотра футбола Footballco, который также работает на iOS и Android.

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

Как шел процесс:

  1. Подписали NDA.
  2. Проанализировали проект.
  3. Дали рекомендации и обучающие материалы.
  4. Ребята внедрили часть рекомендаций и обратились за пояснением по другой части.
  5. Непонятные моменты мы разобрали на созвоне.

Как быстро сделали и сколько это стоило. На анализ и составление плана обычно уходит от двух до пяти дней, а стоимость начинается от 100 000 рублей. Аудит для этого проекта занял три дня и стоил ровно 100 000 рублей.

Вот некоторые рекомендации, которые мы дали для этого проекта:

  1. Упростить gradle-конфигурацию с помощью официального плагина и наших открытых библиотек.
  2. Включить иерархическую структуру проекта, чтобы использовать подсказки и автодополнения от IDEA в iosMain.
  3. Включить Kotlin/Native-кэш, потому что он значительно ускоряет время debug-сборки.
  4. Для ускорения сборки делать экспорт модулей не транзитивно, а указывать его только для необходимых модулей и библиотек.
  5. Заменить написание ручных оберток над корутинами на автогенерируемые, чтобы получать на стороне Swift аналогичные асинхронные методы, но на основе замыканий.
  6. Настроить заморозку объектов сразу в init, чтобы избежать потенциальных ошибок во время работы нескольких потоков.
  7. Исправить ошибку запуска iOS-приложения: некорректно работал один gradle-плагин. Оказалось, что gradle-задача podspec была настроена на статичный фреймворк, но последняя сборка фреймворка была динамичной. Чтобы пофиксить это, мы предложили сделать так, чтобы podspec генерировал фиктивный динамический фреймворк, и тогда все будет компилироваться.

Сценарий 3. Есть приложение на Android, и срочно нужно выпустить версию на iOS, не останавливая разработку, а затем объединить бизнес-логику обоих приложений

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

Как шел процесс:

  1. Подписали NDA.
  2. Проанализировали проект.
  3. Составили индивидуальный план внедрения KMM.
  4. Создали общий код для второй платформы с заделом на интеграцию с первой платформой, чтобы клиент сам мог интегрировать Android-версию.

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

А что по статистике разработчики переносят в общий код? 76% разработчиков используют сразу на двух платформах модель данных, 66% — сетевое взаимодействие и 65% — сериализацию данных.

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

Ваши разработчики только слышали об этой технологии, но еще не пробовали ее внедрить? Тогда приглашаем их на обучение. Мы обучаем как начинающих разработчиков, так и мидлов или сеньоров.

Еще статистика напоследок: у 45% разработчиков есть больше одного проекта на Kotlin Multiplatform. Пишите в комментариях, входите ли вы в это число ;)