Примечание от переводчиков: при словах «мобильные приложения Netflix» вспоминаются их основные приложения для просмотра видеоконтента, но компания ведёт и «киностудийную» разработку — для тех, кто этот контент создаёт. И их пост посвящён использованию Kotlin Multiplatform во втором случае.
В последние годы Netflix разрабатывает сервис Prodicle для индустрии производства телесериалов и фильмов. Мир съёмок живёт в быстром темпе, а его запросы существенно различаются в разных странах, регионах и даже проектах. Специфика этой работы означает, что мы делаем софт с упором на запись, в распределённом окружении, причём у устройств с ним на съёмочной площадке менее чем в трети всех случаев интернет-соединение будет очень надёжным, а право на ошибку у нас ограничено. Поэтому мы, будучи маленькой инженерной командой, обнаружили, что оптимизация надёжности и скорости выпуска продукта просто необходима нам, чтобы успешно отвечать растущим запросам наших клиентов.
Поскольку сетевое соединение часто оказывается ненадёжным, мы обратились к мобильным решениям для персистентности на клиентской стороне и поддержки офлайна. А потребность выпускать быстро привела к экспериментам с мультиплатформенной архитектурой. И теперь мы зашли тут ещё на шаг дальше, использовав Kotlin Multiplatform, чтобы писать платформонезависимую бизнес-логику один раз на Kotlin и компилировать её в Kotlin-библиотеку для Android и нативный Universal Framework для iOS с помощью Kotlin/Native.
Kotlin Multiplatform
Kotlin Multiplatform позволяет вам делать единую кодовую базу для бизнес-логики iOS- и Android-приложений. Вам требуется писать код для конкретной платформы только там, где это необходимо: например, для реализации нативного UI или при работе с платформоспецифичными API.
Kotlin Multiplatform подходит к кроссплатформенной мобильной разработке не так, как некоторые другие известные технологии. В то время как другие полностью абстрагируются от платформозависимой разработки, Kotlin Multiplatform дополняет её, он нацелен на замену только платформо-агностичной бизнес-логики. Он «даёт новый инструмент в ваш набор», а не «выкидывает весь набор инструментов и заменяет на другой».
Этот подход хорошо работает для нас по нескольким причинам:
- У наших приложений для Android и iOS общая архитектура со схожей, а порой и идентичной бизнес-логикой на обеих платформах.
- Почти 50% нашего продакшн-кода в наших Android- и iOS-приложениях не связано с платформой.
- Это никак не мешает нам изучать новые технологии от самих этих платформ (Jetpack Compose, Swift UI и так далее).
Итак, что мы с этим делаем?
Управление опытом (experience management)
Как мы уже заметили, потребности наших пользователей очень различаются. Это приводит к большому количеству конфигураций приложения, чтобы менять то, какие фичи доступны, и подстраивать пользовательский опыт для разных конкретных случаев.
Отделить код, который управляет этими конфигурациями, от самих приложений помогает уменьшать сложность при росте приложений. И наш первый эксперимент с единым кодом для разных платформ затронул реализацию мобильного SDK для нашего внутреннего инструмента Hendrix, который отвечает как раз за это «управление опытом».
По своей сути Hendrix — это простой интерпретируемый язык, который выражает, как должны вычисляться значения конфигурации. Эти выражения оцениваются в контексте текущей сессии приложения, и могут обращаться к данным вроде местонахождения устройства, его атрибутам, значениям A/B-тестов. В нашем случае мы конфигурируем наборы функций приложения, зависящие от региона, версии и типа проекта.
Связь бывает плохой, а значения конфигурации часто меняются в ответ на действия пользователя, и вместо это означает, что оценивать их желательно на устройстве, а не на сервере.
Это привело нас к решению сделать легковесный мобильный SDK для Hendrix — и он был отличным кандидатом для Kotlin Multiplatform, так как требует значимой бизнес-логики и полностью платформонезависим.
Реализация
Для краткости мы опустим конкретные детали о Hendrix и затронем отличия в использовании Kotlin Multiplatform от Kotlin/Swift.
Сборка
На Android всё как обычно. Hendrix Multiplaform SDK подключается с помощью Gradle в качестве Android-библиотеки как любая другая зависимость. В случае с iOS нативный «бинарь» включается в проект Xcode как универсальный фреймворк.
Эргономика разработки
В случае с Kotlin Multiplatorm исходный код можно редактировать, перекомпилировать и добавлять к нему отладчик с брейкпойнтами хоть в Android Studio, хоть в Xcode (включая поддержку lldb). Android Studio работает из коробки, поддержка Xcode достигается с помощью плагина xcode-kotlin от TouchLabs.
Отлаживаем Kotlin-исходники в Xcode
Работа с сетью
Hendrix интерпретирует набор правил — удалённо конфигурируемые файлы, которые оказываются скачаны на устройство. Мы используем Multiplatform HttpClient из фреймворка Ktor, чтобы добавить наш код работы с сетью в SDK.
Дисковый кэш
Конечно, сеть может быть недоступна, поэтому скачанные наборы правил нужно закэшировать. Для этого мы используем SQLDelight с его Android и Native Database-драйверами, чтобы получить персистентность на обеих платформах.
Завершающие мысли
Мы внимательно следим за эволюцией Kotlin Multiplatform в последние годы и верим, что технологиях достигла «точки перегиба». Тулинг и интеграции с системой сборки для Xcode улучшились достаточно, и теперь сложности, связанные с интеграцией и обслуживанием, больше не перевешивают преимущества единой имплементации для разных платформ.
Возможностей для дальнейшего объединения кода между нашими приложениями для киностудий ещё много. Потенциальные будущие применения технологии становятся ещё интереснее, когда мы берём в расчёт, что возможна ещё и транспиляция в JavaScript.
Мы очень заинтересованы возможностью развивать наши студийные приложения в направлении тонких UI-оболочек с единой бизнес-логикой, и продолжим делиться с вами тем, что узнаем на этом пути.
Мы обратили внимание на пост Netflix, потому что перекликающийся с ним доклад скоро представят на нашей конференции Mobius: там тожерасскажут об опыте внедрения Kotlin Multiplatform в продакшн крупной компанией. Только речь пойдёт не о малоизвестном нишевом приложении, а о суперпопулярных Яндекс.Картах. Если два таких гиганта почти одновременно заговорили о продакшн-опыте, значит ли это, что вот теперь время Kotlin Multiplatform пришло?
