Может ли Kotlin Multiplatform сократить трудозатраты при разработке одного продукта под несколько платформ? Мои вычисления говорят, что да, на 21%. Покажу это на примере своего хобби-проекта GitBudget для Android + iOS.
Текущее положение дел
Одним из популярных способов разработки под несколько платформ является схема «одна платформа - одна команда разработки». Например, взглянем на известный мессенджер, заточенный под парковки. Некоторое время назад я словил следующую багу исчезновения сообщений:
Как следует из видео, в ходе переписки с GigaChat у меня пропадали сообщения: на Android бага проявилась лишь раз (4-я секунда видеозаписи), на Web бага повторялась стабильно. Разное поведение на разных платформах свидетельствует о том, что продукт под разные платформы делают разные команды разработки. У каждой команды свой язык программирования, своя архитектура, свой процесс code review, свой уникальный набор порождаемых багов, своя команда тестирования, свой ФОТ и т.д..
Таким образом, чем больше мы дублируем в коде, тем больше мы вынуждены дублировать организационно. КМП может помочь сократить дублирование части кода, но, конечно, не полностью, а лишь на определённый процент. Каков этот процент? Посчитаем на примере моего хобби-проекта GitBudget.
Обзор GitBudget
GitBudget - это крошечный хобби-проект для упрощения ведения собственных трат. На текущий момент нет истории трат, поддержки Git и прочего запланированного. Тем не менее, я пользуюсь этим приложением не первый месяц для упрощения ежедневного подсчёта двух важных для меня цифр:
Перерасход: Насколько на текущий день траты превышают план (бюджет)
Осталось ₽/д: Сколько можно потратить сегодня и в последующие дни текущей недели средств, чтобы не превысить недельный план (бюджет)
Углубляться в формулу и в архитектуру сейчас не буду, т.к. они не предмет данной статьи. Пытливый читатель всё это найдёт сам на GitHub.
Ознакомимся с внешним видом приложения на Android и iOS:
Никакой фантастики в UI/UX нет, все элементы интерфейса стандартные (и даже не везде выровненные). Использование приложения на текущий момент сводится к трём действиям пользователя:
Вставить из буфера обмена траты за вчера (Spent)
Вставить из буфера обмена остаток баланса на вчерашний день (Morning balance)
Скопировать итоговый расчёт в буфер обмена (Result)
Трудозатраты на разработку
Для удобства подсчёта условимся о разделении всего кода приложения на три группы:
№ |
Группа |
Пример |
Файлы Android |
Файлы iOS |
|---|---|---|---|---|
1 |
UI |
Jetpack Compose, SwiftUI |
MainActivity.kt, VM.kt |
AppView.swift, VM.swift |
2 |
Платформа |
ClipboardManager, UIPasteboard |
budget.kt, main.kt, other-android.kt, registerOneliners.kt |
budget.swift, cld-ios.swift, other-ios.swift |
3 |
Логика |
budgetShouldResetMorningBalance |
budgetFun.kt, entities.yml |
budgetFun.kt, entities.yml |
КМП в GitBudget я использую лишь для логики, а UI и платформенный код нативные. Почему так? Потому что логика полностью под моим контролем, она обновляется по моему усмотрению. С UI и платформенным кодом ситуация иная - это собственность корпораций Apple и Google, они задают правила игры и обновляют UI с платформой по своему усмотрению (например, придумывают Liquid Glass, от которого не увернуться).
Считать будем два объективных показателя - количество строк кода и время, затраченное на реализацию какой-либо функциональности. На каждый из этих показателей посмотрим в разрезе вышеобозначенных трёх групп - UI, платформа, логика - и двух платформ - Android, iOS.
Первый показатель: Количество строк кода
№ |
Платформа |
Всего |
UI |
Платформа |
Логика |
|---|---|---|---|---|---|
1 |
Android |
692 |
160 (23%) |
221 (32%) |
311 (45%) |
2 |
iOS |
540 |
90 (16%) |
139 (26%) |
311 (58%) |
Вывод-1: 311 строк логики для iOS я не писал повторно благодаря КМП, это 58% всего кода iOS.
Вывод-2: 311 ненаписанных повторно строк кода для iOS с точки зрения обеих платформ (692 + 540 = 1232) означают, что 25% кода всего проекта я не писал повторно.
Второй показатель: Время реализации функциональности
Под запись я добавил кнопку Paste для поля ввода Morning balance как для Android:
Так и для iOS:
В итоге получились такие цифры:
№ |
Платформа |
Тип реализация |
Особенности реализации |
Время |
|---|---|---|---|---|
1 |
Android |
Первичная |
Создаём новую функциональность, которой не было, собираем почти все грабли |
17:34 |
2 |
iOS |
Вторичная |
Подключаем готовую логику, дописываем лишь UI, граблей практически нет |
07:33 (43%) |
Вывод-3: Повторение функциональности на iOS с готовой логикой заняло на 57% меньше времени, т.е. произошло в 2 раза быстрее
Вывод-4: Если принять, что без КМП функциональность на каждой из двух платформ делали бы в сумме 17:34 * 2 = 35:08 минут, то сэкономленные 10 минут при повторении функциональности для iOS означают, что для всего проекта я сэкономил 21% времени.
Выводы
Итак, экономия с КМП в цифрах выглядит так:
Количество строк для iOS снизилось на 58%
Суммарно количество строк кода по всему проекту снизилось на 25%
Время, необходимое на повторение функциональности для iOS, снизилось на 57%
Суммарно затраченное время по всему проекту на реализацию функциональности снизилось на 21% (эту цифру я использовал в самом начале статьи)
Вопросы читателю
Суммарная экономия в 21% по времени проекта - это много или мало?
Окупает ли экономия в 21% явно не однодневный переход команд на новый процесс разработки?
Насколько важен синхронный выпуск функциональности на обе платформы, причём работающей одинаково на каждой платформе?
Комментарии (6)
laptev_am
28.01.2026 18:33На вопросы ответа не будет, потому что многое зависит от функционала. Ваш пример по сути простой "Hello world" и на таком рафинированном примере достичь цифры 21% достаточно легко. Можно и больше, используя CMP для одинакового UI.
Проблемы начинаются тогда, когда нужно работать с датчиками, камерой, bluetooth, файлами и пр. Если, скажем для сетевых запросов есть готовая библиотека Ktor, то для платформо-специфических вещей универсального решения нет. Да и не факт, что оно вообще появится когда-нибудь.
Еще есть проблема перехода команды. Далеко не факт, что разработчики под одну платформу хотя бы читали документацию по другой платформе. Т.е. процесс перехода на CMP/KMP может быть не такой быстрый и безоблачный, каким представляется на подобных примерах. Единственное, но не настолько значимое, преимущество у Android разработчиков - они хотя бы синтаксис и стиль Kotlin знают. Но опять же, это особого профита не даст.
Суммируя:
если приложение просто тонкий CRUD клиент - то однозначно имеет смысл работать с CMP/KMP
если приложение работает с hardware смартфона - то черт знает... думайте сами :)
xephosbot
28.01.2026 18:33На iOS там хотя бы 90% апи кодогенерацией через Kotlin Native подтягивается, и в принципе поискать примеры на Swift, и адаптировать их под KN порой вполне возможно)
А вот с Desktop таргетами на JVM тяжко, получить доступ к какому-то платформенному функционалу ещё те танцы с бубнами. Но нативные Desktop клиенты пока не в приоритете у Jetbrains :(
Anfet
28.01.2026 18:33А пото ты берешь флаттер и команда из 5 превращается в команду из 2 без потери скорости и качества. Без дублирования ui на разных платформах, без учения свифта.
Да, пугают что "ой, нет поддержки чего-то", но я за последние года как-то не встречал.
И рендеринг один. Сплошные удобства.
Nihao_1337
28.01.2026 18:33Ответы:
Так то 21% это почти 1/5, так что, скорее много
С учетом потраченного времени на изучение КМП, следует улучшение и стабильность самого приложения в будущем, что говорит о положительном векторе развития
Мне кажется, синхронный выпуск версий одного приложения положительно скажется как на пользователях, так и на самой команде, которая делает данное приложение
Вопросы:
Насколько долгий порог входа в кмп и должен ли я буду изучить языки, на которых пишет андроид?
vkompaniec
28.01.2026 18:33А почему тогда не взять React Native или Flutter ? Изучение займет немного времени. Библиотеки все есть. Интерфейс хочешь системный, хочешь кастомный. React Native и так превращает код в нативные элементы и прекрасно общается с нативными библиотеками если прям приспичит.
Такое приложение приложение пишется руками за час с интерфейсом, работой с апи и т.д.
TDMNS
Ответы на вопросы:
Если команда из пяти разработчиков, то это -1 (точно не мало).
Если долгострой, то да.
Важен для всех (как для бизнеса так и для команды).
Пара встречных вопросов:
Какой порог сложности проекта, после которого КМП начинает окупаться быстрее, чем натив?
Что из логики ты сознательно не стал выносить в КМП и почему?