Kotlin Multiplatform Mobile: Опыт iOS-разработчика и выгоды для бизнеса

Я постоянно сталкиваюсь с одним и тем же вызовом от бизнеса: как нам разрабатывать приложения быстрее, дешевле и при этом не терять в качестве? И мой ответ в последнее время все чаще — Kotlin Multiplatform (KMM).

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

Конечно, я понимаю опасения, которые мне регулярно озвучивают: «Смогут ли наши «нативщики», привыкшие к Swift, адаптироваться?», «Не усложнит ли это архитектуру?», «Окупится ли вообще этот переход?». Это абсолютно резонные вопросы. Давайте я поделюсь своим видением, почему KMM действительно того стоит.

Какие проблемы я вижу в компаниях каждый день?

Когда я провожу аудит или общаюсь с коллегами из других компаний, я вижу три повторяющиеся проблемы:

1. Тотальное дублирование кода и раздутые команды. Классический пример, который я встречаю постоянно: экран авторизации или корзина в интернет-магазине. Логика идентична на 100%, но из-за особенностей платформ мы вынуждены реализовывать ее дважды. Это двойная трата человеко-часов.
2. Астрономические затраты. Будем честны: зарплаты опытных нативных разработчиков высоки. Я считаю, что необходимость держать две полные команды (iOS и Android) увеличивает ФОТ на разработку в 2, а то и в 3 раза по сравнению с потенциальной универсальной командой.
3. Устаревшие технологии. Недавно я консультировал компанию, которая до сих пор поддерживает ключевое приложение на Objective-C. Найти разработчиков, готовых с энтузиазмом погружаться в такой код, — настоящий квест. Обучение новичков съедает месяцы и ресурсы.

KMM: Как я вижу решение на практике

Для меня KMM — это прямой ответ на все эти вызовы: общий код, оптимизация команды и, как следствие, ускорение time-to-market. Но как это выглядит на практике, особенно для тех, кто привык к «яблочной» экосистеме?

Я хорошо помню, как еще несколько лет назад рынок был четко поделен: вот Swift-разработчики, вот Kotlin/Java. Но сейчас я наблюдаю явный тренд: бизнес ищет специалистов, способных работать с обеими платформами.

Переход на новую технологию

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

1. Сначала теория: Я настаиваю, чтобы ребята сначала поняли основы Kotlin (он очень похож на Swift, что является огромным плюсом), принципы KMM и ключевые инструменты вроде Ktor (для сетевых запросов) и SQLDelight (для баз данных).
2. Затем практика: Мы не бросаем новичка сразу на сложный проект. Я даю небольшие, изолированные задачи: «Вынеси логику вот этого экрана в shared-модуль, используя механизмы expect/actual». Это лучший способ «пощупать» технологию и обрести уверенность.

Конкретные выгоды: мой опыт и кейсы

Как KMM помогает бизнесу? Я могу говорить об этом часами, но выделю два ключевых момента.

1. Экономия времени и денег — это не маркетинг

KMM позволяет сократить дублирование кода, и это не просто красивая фраза. Приведу личный пример: раньше у нас в команде экран авторизации делали два человека. iOS-разработчик тратил, скажем, 8 часов на Swift, и Android-разработчик — еще 8 на Kotlin.

С KMM я, как тимлид, или один из моих старших разработчиков пишем общую логику за те же 8 часов. После этого моим «нативщикам» остается только настроить UI, что занимает пару часов на каждой платформе. Итог: вместо 16 часов мы тратим 10–12, и логика работает гарантированно одинаково. Я считаю, что в масштабах крупного проекта с десятками экранов это колоссальная экономия.

2. Упрощение найма и уход от «legacy»

Мой опыт как нанимающего менеджера показывает: молодые специалисты не хотят идти работать с Objective-C. Переход на KMM (с ядром на Kotlin) позволяет нам омолодить стек и стать привлекательнее для кандидатов.

Кроме того, я уверен, что рынок движется к универсальным разработчикам. Я вижу, как бывшие «чистые» iOS-специалисты с помощью KMM начинают закрывать задачи на обеих платформах. По моим наблюдениям, при должной поддержке в компании полная адаптация Swift-разработчика занимает всего 2–3 месяца. Мы решаем проблему нехватки кадров: вместо двух отдельных вакансий нам часто достаточно одной.

Реальный пример: от аудита к результату

Приведу в пример недавний кейс. К нам обратилась ритейл-компания. Когда я пришел к ним на аудит, у них было две команды: 5 iOS и 5 Android-разработчиков. Мы проанализировали код и увидели, что около 60% функционала (авторизация, каталог, корзина) — это просто дублирование логики.

Мы предложили им поэтапный переход на KMM. Всю общую логику вынесли в shared-модуль. В итоге ядро команды сократилось до 6 универсальных разработчиков. Экран корзины, который раньше суммарно занимал у них 20 часов (10 на iOS, 10 на Android), теперь делается за 12 часов. По нашим совместным подсчетам, их time-to-market сократился на 30%, а затраты на разработку упали почти на 25%.

Мой вывод: KMM — это не страшно, а выгодно

Я считаю, что KMM — это уже абсолютно зрелая технология, которая приносит бизнесу реальную, измеримую пользу. Для iOS-разработчиков, с которыми я общаюсь, это прекрасная возможность расширить свои навыки и стать гораздо востребованнее на рынке.

Мой главный совет: не бойтесь пробовать! Я всегда рекомендую начинать с чего-то простого, вроде экрана авторизации или модуля аналитики. Изучайте примеры от JetBrains, подключайтесь к комьюнити. Уверяю вас, как человек, видевший этот переход много раз: Swift и Kotlin очень похожи, так что процесс будет на удивление плавным.

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