Kotlin Multiplatform может сократить время разработки на 30 процентов — об этом написали статью наши коллеги из компании Archer Software. Они подробно разобрали проблемы, которые возникают в процессе работы, и то, может ли кроссплатформенная технология их решить. Мы считаем, что материал нужный и полезный, поэтому публикуем в нашем блоге перевод.
Из этой статьи вы узнаете:
Если учесть, что в мире ежегодно появляется 100 миллионов стартапов, то время вывода продукта на рынок теперь намного важнее стоимости. Пользователи становятся все требовательнее, поэтому разработчикам лучше выбирать нативные решения.
Однако приложение сразу под три платформы: Android, iOS и десктоп — обойдется клиенту в три раза дороже. Но можно пойти другим путем и создать универсальный код, который работает одинаково на всех платформах.
Какие проблемы возникают, когда над приложением работают несколько команд
Как правило, при разработке мультиплатформенных нативных приложений несколько команд работают независимо друг от друга. Конечно, им нужно общаться и обмениваться результатами, но в процессе координации возникает ряд проблем.
Разные решения одних и тех же задач
Две независимые команды могут придумать разные подходы к решению задачи клиента, поэтому версии приложения для разных операционных систем будут выглядеть и работать по-разному. Особенно если у пользователя разные устройства для запуска одного и того же приложения, например iPhone, планшет Android и десктоп на Windows.
Трудности коммуникации
Важно, чтобы удаленные коллективы могли быстро обмениваться информацией, тем более когда две команды одновременно создают приложение для разных операционных систем.
Например, клиент может дать одной из команд новую задачу, а вторая команда будет продолжать заниматься тем, что делала раньше. Получится два разных результата.
Специфические особенности платформ
Каждая из операционных систем предъявляет свои требования к качеству продукта, в особенности — к пользовательскому интерфейсу, который должен максимально соответствовать конструкции устройств, использующих эту ОС.
Для каждой платформы используют разные языки, фреймворки и библиотеки. Но при этом разработчики должны построить два приложения с максимально идентичным пользовательским интерфейсом.
Взаимозаменяемость разработчиков
В идеале код должен быть настолько понятным, чтобы любой специалист, владеющий определенным языком программирования, мог разобраться, как он работает.
На деле часто получается спагетти-код — запутанная и сложная программа. Поэтому заменить или усилить членов группы разработчиков сложно. Новичку приходится тратить слишком много времени, чтобы включиться в работу. Он просто разбирается с тем, что написали до него.
Может ли кроссплатформенная технология решить эти проблемы
Процесс разработки нужно как-то синхронизировать. Кажется, что единственный выход — использовать одну кроссплатформенную технологию, которая способна хранить и применять код для различных операционных систем. Однако все не так радужно, как хотелось бы.
Недостатки кроссплатформенных решений
- трудно получить доступ к API системы;
- обновления запаздывают;
- нет возможности работать с устаревшим кодом;
- большинство кроссплатформенных комплектов для разработки (SDK) доступны только в бета-версии или на экспериментальной стадии;
- одинаковый вид приложения на всех платформах может испортить впечатление пользователя.
Чем хорош Kotlin Multiplatform при разработке кроссплатформенных приложений
Эти недостатки не настолько критичны, если знать, как с ними справляться. Чтобы ускорить разработку и облегчить взаимодействие между отдельными командами, наша компания использует Kotlin.
Что такое Kotlin Multiplatform? Это язык программирования с открытым исходным кодом, позволяющий создавать максимально чистый код. С ним не нужно делать одну и ту же работу дважды. Например, если мы создаем приложение для Android и iOS, мы можем частично использовать один и тот же код.
Как работает Kotlin Multiplatform
Kotlin для Android, iOS и других популярных операционных систем хранит фрагменты кода, которые можно использовать для двух и более версий приложения. На Kotlin мы пишем общий код, а затем компилируем его в нативные фреймворки с ссылкой на нативные Android и iOS проекты.
Функции, которые неэффективно кодить с помощью Kotlin, можно прописать в нативной среде. Так ниже риск разработки двух или более решений для разных платформ. И это не единственное преимущество.
Основные преимущества Kotlin Multiplatform
Значительная экономия денег и времени. Разработчики при работе на Kotlin экономят 30–50% рабочего времени. Поэтому экономит и клиент: разработчикам не надо платить за то, что они воспроизводят один и тот же код несколько раз.
Меньше ошибок. Kotlin позволяет создавать максимально чистый код. Однако, если ошибки все-таки закрались, их можно найти и исправить до начала исполнения. Это экономит время и деньги в процессе тестирования и контроля качества (QA).
Эффективная работа в команде. Kotlin помогает командам программистов взаимодействовать и фокусироваться на приоритетных задачах. Более того, он позволяет распределять задачи между разработчиками. Например, команда Android может работать над реализацией регистрации (user signup flow), а команда iOS — созданием поста (post create flow). На следующем этапе команда Android может использовать код, написанный командой iOS, и наоборот.
Практически нативное решение. Код Kotlin очень похож на Swift и на 100% совместим с Java.
Недостатки Kotlin Multiplatform
Несмотря на все плюсы, есть также минусы, которые следует учитывать, принимая решение в пользу языка программирования Kotlin.
Нужно время на обучение
Разработчики часто спрашивают, как можно бесплатно изучить Kotlin или сколько времени на это нужно. Изучать основы вы можете бесплатно. Если владеете Java, вам потребуется меньше времени, чтобы их освоить.
Тем не менее, не стоит ждать, что ваша команда разработчиков переключится на Kotlin через несколько часов. Переход потребует дополнительного времени и затрат на обучение.
Так что лучше: Kotlin или Java? Это зависит от цели, которую вы хотите достичь.
Нехватка разработчиков-экспертов
Конечно, для решения конкретных задач лучше нанимать программистов с опытом разработки на Kotlin Multiplatform. Но найти им замену нелегко, потому что технология не так широко распространена, как нативные языки программирования.
Заключение
Если вам нужно приложение для двух платформ и веб-версия, обращайтесь к экспертам по Kotlin, это беспроигрышный вариант. Мы в компании IceRock Development, как и наши коллеги в Archer Software, знаем, насколько он эффективен.
Наша компания делает заметный вклад в развитие технологии Kotlin Multiplatform:
- https://moko.icerock.dev — наши опенсорс библиотеки для быстрого старта при использовании Kotlin Multiplatform;
- https://t.me/kotlinmpp — телеграм-канал, где тему обсуждают 800+ программмистов;
- https://kmp.icerock.dev — сайт с библиотеками и ссылками на проекты;
- https://libs.kmp.icerock.dev — сайт с библиотеками для Kotlin Multiplatform.
Приходите к нам, и мы покажем, как Kotlin Multiplatform может быть полезен вашему бизнесу!
В общем, экономия при разработке сильно зависит от проекта и его особенностей – где больше работы над интерфейсами (UI) в приложении - там экономии меньше, поскольку UI реализуется на платформенной стороне дважды. А если у проекта много бизнес-логики - тогда экономии больше, потому что она реализуется в общем коде один раз.
В целом, мы на проектах видимо от 20% до 40% экономии трудозатрат по сравнению с использованием только нативных технологий, поэтому 30% будет где-то близко к нашему опыту :)
Или можно писать на Dart/Flutter, но недостатки те же.
Плюс может потребоваться платформозависимый код, от этого, насколько я понимаю, и в Kotlin Multiplatform никуда не деться.
Сравнение KMP и кроссплатформы типа Flutter/RN не совсем корректно.
В случае с KMP мы получаем нативные приложения.
Слой бизнес логики, обычно, у мобильных приложений не большой,
но если его держать общим для двух платформ, то очень сильно экономим на синхронизации меж командами. От сюда и экономия по времени разработки.
Flutter is Google’s UI toolkit for building beautiful, NATIVELY compiled applications
Согласен полностью.
Не совсем так. Кроссплатформенные решения вида Flutter или React Native добавляют дополнительную абстракцию от платформ. Они усложняют работу с самой платформой и не дают использовать обширный набор библиотек от нативного iOS/Android-сообщества.
А Kotlin Multiplatform - решение лишено подобных недостатков, в связи с чем имеет заметные преимущества перед остальными т.к. платформозависимый код с kotlin multiplatform сильно проще реализуется, чем в Flutter и React Native - не надо никакие каналы и прокси строить, просто вызываешь функции напрямую, а UI приложения полностью нативный для Android и iOS, и развитие проекта наращивание функционала возможно без ограничений.
В итоге получается, что при отладке кода его нужно будет править лишь один раз, и исправления произойдут сразу на обеих платформах. Но вы правы, без платформенного кода никуда - UI используется полностью нативным (что мы считаем преимуществом).
Усложняют ли работу с платформой — нет, они унифицируют.
В итоге получается, что при отладке кода его нужно будет править лишь один раз, и исправления произойдут сразу на обеих платформах.Усложняют работу с нативными библиотеками — да.
Но про "не дают использовать" — неправда же. Да, через бриджи или каналы, но возможность есть.
И во flutter сейчас пока это не совсем удобно.
Серьезно? А может лучше честно?)
Ладно, я придираюсь, не один раз, а — в едином проекте. Но так это в любом кроссплатформенном решении же.
Только дебагать придется далеко не один раз и под каждой платформой)
Для других читателей:
https://flutter.dev/docs/development/platform-integration/platform-channels
https://reactnative.dev/docs/platform-specific-code
Серьезно и честно. Когда у вас реализована общая логика в общем модуле, то изменения в этом модуле применяются сразу на двух платформах.
Но так это в любом кроссплатформенном решении же.
В том и суть, что KMP сильно отличается от других кроссплатформ, потому что:
- взаимодействует с OS напрямую
- реализует нативный UI.
- хочешь пишешь в общем модуле, не хочешь - уносишь пишешь на нативе.
Это для нас самое важное и ключевое.
В случае флаттера тоже так.
Плюс можно прогреть анимации(не разобрался как работает, но возможность такая есть)
А вот с RN, Ionic совсем не так, согласен.
Но ведь вы сами написали, что флаттер работает через бриджи? :) А теперь пишете, что в случае флатера тоже также, где правда? :)
Эм...начнем с того, что я такого не писал.
Так что
In addition, Flutter is different because it only has a thin layer of C/C++ code. Flutter implements most of its system (compositing, gestures, animation, framework, widgets, etc) in Dart (a modern, concise, object-oriented language) that developers can easily approach read, change, replace, or remove. This gives developers tremendous control over the system, as well as significantly lowers the bar to approachability for the majority of the system.source:
https://flutter.dev/docs/resources/faq
Да, вы корректнее и точнее сформулировали.
Нехватка разрабов - это большая проблема. Поддержка кода который не умеет рисовать или рисует по тормозному (превед react native) - это тоже проблема. Это пытается решить Flutter. И очень много готовых компонент, это к вопросу о цене.
Единственный плюс, пока не решены задачи выше, Котлин няшный, но для бизнеса это сомнительный плюс. Общую логику можно даже и на питоне закрутить.
Общую логику и на плюсах писали. Конечно, с декларативным UI проще все унифицировать, но как там дела с реактивностью в котлине?
Что ты имеешь ввиду ?) Что ты понимаешь под "реактивностью" в отношении конкретного языка ?)
В конкретном случае hot reload при разработке:)
hot reload и реактивность несвязанные понятия.
Где я сыпал доками по котлину?
В случае флаттера всё прекрасно
https://flutter.dev/docs/development/tools/hot-reload
Ну кроме разве что
If you’ve changed native code (such as Kotlin, Java, Swift, or Objective-C), you must perform a full restart (stop and restart the app) to see the changes take effect.Но спасибо за пинок, узнал про Instant run
Интересно, что простой вопрос сообщества @Kotlin в твитере по поводу использования этой технологии в продакшене вызвал шквал ответов: https://twitter.com/kotlin/status/1219575319327334400
На счет 30% согласны? Или у вас есть друге цифры? Поделитесь?
Упс, ответили комментарием ниже :/