Мультиплатформенная Разработка — ДА/НЕТ?

НАПИШИ ОДИН РАЗ — ЗАПУСКАЙ ГДЕ УГОДНО

Основная суть — разработка сразу под несколько платформ, то есть пишем код один раз вместо двух для iOS и Android. Это же касается и фикса багов, расширения функционала, поддержки проекта.

При рассмотрении мультиплатформенного решения, обычно обращают внимание на следующие критерии:

• Объем шаринга кодовой базы. Бывают кейсы, когда универсальное решение не работает, либо работает не так, как нужно и тогда приходится его кастомизировать под конкретную платформу. Это свойство можно выражать через проценты — например, в приложении 50% общего кода. Можно выражать через абстракции — например, сетевой слой (т.е. работа с API)  общий, а UI часть на каждой платформе своя.
• Производительность. Тут вроде все очевидно.
• Порог вхождения: прежде чем работать с новой технологией ее нужно изучить/освоить.
• Легаси: слабо-обусловленный отказ от накопленных знаний и опыта. Бывает естественная необходимость в переходе на новую технологию, когда старая объективно проигрывает, но бывает и так, что переход обусловлен лишь тем, что в новых условиях, просто другая экосистема, другой технологический стек. Чем больше знаний становятся неактуальными, тем хуже.
• Перспективы: вероятность того, что технология выстрелит, ее не перестанут развивать и поддерживать, наличие активного комьюнити. Для команды это еще и актуальность знаний и опыта, на изучение которых были потрачены усилия и ресурсы.

Рассмотрим решение от JetBrains: Kotlin Mobile Multiplatform для iOS и Android.

ШАРИНГ КОДОВОЙ БАЗЫ.

На сайте JetBrains есть раздел с кейсами, как различные компании пробовали применять данную технологию. Некоторые заявляют, что смогли вынести в общий код примерно две трети проекта. Тут, конечно, многое зависит от конкретного проекта.

Обычно в общий код попадают такие штуки, как работа с сетью, бизнес логика. В нейтиве реализуют UI и какие-то специфичные для платформы API, например работа с камерой, биометрия, Google/Apple сервисы и т.д.

Чисто в теории, можно зашарить и намного больше — все зависит от того:

• на каком этапе развития находится технология
• понравилась ли она сообществу, что влияет на кол-во библиотек от сторонних разработчиков.

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

Если технология популярна, то появление библиотек это лишь вопрос времени, на гитхабе уже есть подборки с решениями для популярных кейсов.

Им, конечно, еще предстоит пройти проверку временем. Вполне возможно, что они содержат баги или покрыты не все юзкейсы, ну или просто выполнены не качественно.

С производительностью все должно быть хорошо.

Если грубо и без подробностей, то общий код компилируется в нативный и подключается как библиотека.

ПОРОГ ВХОЖДЕНИЯ/ЛЕГАСИ/ПЕРСПЕКТИВЫ

1. Новые библиотеки для разработчиков.

Если речь идет про шаренный код, то библиотеки там свои, их нужно осваивать: какие-то могут быть похожи на «старые» и даваться легко, а другие могут сильно отличаться, в том числе концептуально.

2.  Возможно новый (дополнительный) язык для iOS разработчика (Kotlin).

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

Пример.

То, что на изображении в схемке, это все шаренный код, написанный на Kotlin. При этом в iOS части (оранжевая слева) уже есть доступ к iOS SDK (разные NS обджекты).

Таким образом, либо iOS разработчик изучает Kotlin, либо Android разработчик, знающий Kotlin, изучает iOS SDK.

3. Архитектура

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

4. Две IDE (среды разработки)

Время от времени может понадобится работать в обеих IDE (Android студия и XCode). То есть речь идет о дополительном времени, чтобы освоиться.

5. Рекомендации по железу от iOS разработчика (для Mac)

• 512 GB SSD
• 16 GB RAM
• Девайс (iphone) – не обязателен (есть simulator)

Возможно хватило бы и 350-400 ГБ диска, но выбор между 256 и 512, а чего-то посредине нету. 256 слишком мало, рискованно для двух экосистем разработки.

Стоит упомянуть, что на Windows собрать бинарник для MacOS нельзя.

Девайс (iphone) – необязателен (есть simulator, который хоть и покрывает не все кейсы, но для базового функционала сгодится).

ПЕРСПЕКТИВЫ

Чисто субъективно, по инфоповодам и тому, как это выглядит со стороны: технология вроде бы приглянулась комьюнити. Активно развивается, погибать не собирается.

Список некоторых компаний, которые используют КММ. Наверное всем понятно, что они используют это в рамках экспериментов, а не как основную технологию для флагманских продуктов.

Автор: Арсен, наш Android разработчик 😎