Сэкономить бюджет и ускорить разработку: переход на Kotlin Multiplatform Mobile
Kotlin Multiplatform Mobile — мультиплатформенный инструмент, который позволяет не только создавать общий код для приложения на iOS и Android, но и сэкономить до трети бюджета и ускорить разработку на 25%. Но что, если у вас уже есть проект и вы хотите перейти на KMM? Разбираем в статье, каким может быть переход, и раскрываем цифры и сроки.
Когда стоит внедрить KMM
Перейти на Kotlin Multiplatform Mobile можно как в начале разработки, так и на этапе реализации или запуска готового проекта. Чтобы вы получили выгоду от внедрения, должно выполняться одно из трех условий:
- У вас есть приложение или вы только начали его разрабатывать, и его будут использовать на разных платформах: Android и iOS.
- У вашего приложения с Android- и iOS-версиями сложная бизнес-логика при простом UI. Например, при офлайн-синхронизации.
- У вас есть Android-приложение на Kotlin, но вам срочно нужно выпустить версию на iOS c переиспользованием того, что уже сделано.
60% — столько разработчиков используют или хотя бы пробовали в продакшене Kotlin Multiplatform, согласно недавно опубликованному опросу JetBrains.
Что даст внедрение KMM
В перспективе вы можете сэкономить до трети бюджета. В основном экономия бюджета происходит за счет разработки общего кода сразу для двух платформ: Android и iOS — его может написать один человек.
Вы ускорите разработку на 25% и в перспективе получите возможность быстрее и легче внедрять новые функции сразу на двух платформах.
Проекты станут работать идентично на двух платформах, не будет различия в мелких деталях или сложных кейсах.
У разработчиков на iOS и Android будет общий контекст, что позволит им понимать чужой код в любом месте бизнес-логики и оперативно дорабатывать его и вносить исправления.
Возможно, именно поэтому 75% тех, кто когда-либо пробовал Kotlin Multiplatform ради интереса, собираются использовать ее в настоящих проектах.
Как происходит переход на KMM
Сценарий перехода на KMM зависит от текущей ситуации в вашем проекте. Условно можно выделить три сценария. Покажем их на примере наших кейсов.
Сценарий 1. У вас есть приложение на обеих платформах, и вам нужна помощь экспертов, чтобы сделать общую бизнес-логику
За таким видом переноса к нам обратились ребята из «Профи».
«Профи» — приложение для поиска специалистов из разных областей. Работает на iOS и Android. Заказчик попросил помочь перенести бизнес-логику из Android-приложения на мультиплатформу.
Как шел процесс:
- Подписали NDA.
- Проанализировали проект.
- Составили индивидуальный план внедрения KMM.
- Клиент начал по плану перетаскивать бизнес-логику в общий код.
Как быстро сделали и сколько это стоило. Вообще, внедрение по такому сценарию занимает от двух недель до полугода в зависимости от проекта и стоит от 500 000 рублей. Но тут ребята большую часть работы сделали сами, а мы только помогли с планом «переезда». Наша работа заняла несколько дней: за это время мы сделали анализ того, что ребята уже сделали для создания общего кода, и составили план переноса бизнес-логики.
План для этого проекта состоял из следующих шагов:
- Настроить поддержку Kotlin Multiplatform в gradle-модуле.
- Перенести платформенно-независимые классы в commonMain.
- Заменить библиотеки JVM/Android на мультиплатформенные аналоги.
- Перенести в commonMain JVM-зависимый код, который требует изменений.
- Перенести в commonMain Android-зависимый код, который требует изменений.
- Сделать публичные интерфейсы компонентов общей логики удобными для обеих платформ.
Дальше команда «Профи» сама смогла использовать результаты этого ревью в своей работе и подробно описала процесс на «Хабре» в шаге 3.
Сценарий 2. Ваша команда успешно опробовала KMM, и вам нужна только консультация экспертов
Такой вид работы у нас сложился с зарубежным сервисом для просмотра футбола Footballco, который также работает на iOS и Android.
К проекту мы подключились на этапе запуска. Сначала ребята самостоятельно сделали общую логику и подключили ее к своим Android- и iOS-приложениям, затем пришли к нам за экспертизой.
Как шел процесс:
- Подписали NDA.
- Проанализировали проект.
- Дали рекомендации и обучающие материалы.
- Ребята внедрили часть рекомендаций и обратились за пояснением по другой части.
- Непонятные моменты мы разобрали на созвоне.
Как быстро сделали и сколько это стоило. На анализ и составление плана обычно уходит от двух до пяти дней, а стоимость начинается от 100 000 рублей. Аудит для этого проекта занял три дня и стоил ровно 100 000 рублей.
Вот некоторые рекомендации, которые мы дали для этого проекта:
- Упростить gradle-конфигурацию с помощью официального плагина и наших открытых библиотек.
- Включить иерархическую структуру проекта, чтобы использовать подсказки и автодополнения от IDEA в iosMain.
- Включить Kotlin/Native-кэш, потому что он значительно ускоряет время debug-сборки.
- Для ускорения сборки делать экспорт модулей не транзитивно, а указывать его только для необходимых модулей и библиотек.
- Заменить написание ручных оберток над корутинами на автогенерируемые, чтобы получать на стороне Swift аналогичные асинхронные методы, но на основе замыканий.
- Настроить заморозку объектов сразу в init, чтобы избежать потенциальных ошибок во время работы нескольких потоков.
- Исправить ошибку запуска iOS-приложения: некорректно работал один gradle-плагин. Оказалось, что gradle-задача podspec была настроена на статичный фреймворк, но последняя сборка фреймворка была динамичной. Чтобы пофиксить это, мы предложили сделать так, чтобы podspec генерировал фиктивный динамический фреймворк, и тогда все будет компилироваться.
Сценарий 3. Есть приложение на Android, и срочно нужно выпустить версию на iOS, не останавливая разработку, а затем объединить бизнес-логику обоих приложений
Так мы делали для приложения для совместных игр онлайн и общения GetMega. Общий код делали на основе версии на Android, которая уже была написана на Kotlin. И создали его сразу с интеграцией с iOS-приложением. В результате клиент получил два приложения с общей логикой, не прерывая работу над функционалом Android-приложения.
Как шел процесс:
- Подписали NDA.
- Проанализировали проект.
- Составили индивидуальный план внедрения KMM.
- Создали общий код для второй платформы с заделом на интеграцию с первой платформой, чтобы клиент сам мог интегрировать Android-версию.
Как быстро сделали и сколько это стоило. Это самый дорогой и сложный вид услуг — работа может стоить от 1 млн рублей. Анализ и составление плана занимает обычно так же от двух до пяти дней. На создание приложения с общим кодом может уйти от одного до шести месяцев, а на интеграцию с первой платформой — от двух недель до нескольких месяцев. В этом проекте анализ задачи занял три дня, а разработка — три месяца. При этом клиент уложился в бюджет в 3 млн рублей.
А что по статистике разработчики переносят в общий код? 76% разработчиков используют сразу на двух платформах модель данных, 66% — сетевое взаимодействие и 65% — сериализацию данных.
Мы будем рады проконсультировать команды и бизнес по вопросам разработки мобильных приложений на Kotlin Multiplatform Mobile, а также готовы присоединиться к разработке. Написать нам можно на этой странице.
Ваши разработчики только слышали об этой технологии, но еще не пробовали ее внедрить? Тогда приглашаем их на обучение. Мы обучаем как начинающих разработчиков, так и мидлов или сеньоров.
Еще статистика напоследок: у 45% разработчиков есть больше одного проекта на Kotlin Multiplatform. Пишите в комментариях, входите ли вы в это число ;)
Flutter лучше и точка.
Вот вы все прикалываетесь над названием мака, а маркетологи знали, что это всё бесплатная реклама))
Любой инструмент хорош для своих задач. Флаттер хорош для создания проекта с нуля. А если продукт уже есть, при этом он большой, сложный, на 4х платформах (бекенд, фронт, айос и андроид)? Как оптимальнее вести работы? Как ускорить разработку? Пригодится тут флаттер? Лучше он тут?
Флаттер для нищебродов или простеньких приложений, все еще тормозит лол)
kmm пока не готов, кто ловил вылеты на ровном месте, поймет.
А вот нативом занимаются нормальные конторы с нормальной зарплатой.
Очередная рекламная статья, не тащите мультиплатформу, если планируете серьезно развивать приложение. Для одноразовых поделий или быстрой аутсорс разработки сойдет и флаттер. Для всего остального логику нужно по максимуму отдавать с бэка.