Kotlin Multiplatform и Compose Multiplatform — стратегический провал Apple

«Технология Kotlin Multiplatform предназначена для упрощения разработки кроссплатформенных проектов. Она сокращает время, затрачиваемое на написание и поддержку одного и того же кода для разных платформ, сохраняя при этом гибкость и преимущества нативного программирования.» ~ Kotlin.org

Это Святой Грааль для разработчиков мобильных приложений — и менеджеров — повсюду.

Возможность написать код один раз, а затем запустить его на любой платформе.

Есть несколько причин желать этого:

1. Общая кодовая база уменьшает количество несоответствий между платформами.
2. Снижает требований к тестированию.
3. Сокращая время выхода на рынок.
4. Снижает стоимости разработки.

Но если быть честным, то, вероятно, именно последний пункт является ключевым.

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

Один раз для iOS и один раз для Android.

Kotlin Multiplatform (KMP) и Compose Multiplatform (CM) представляют собой одну из последних попыток решить эти проблемы. Вместе они представляют собой яркую надежду для менеджмента…

А для Apple они представляют собой крупный стратегический провал высшего порядка.

Но сначала — Грааль.

В поисках Грааля

Святой Грааль всегда был неуловим. Такова природа Грааля.

Но на протяжении многих лет у нас было много анонсов от компаний и технологий, не просто ищущих Грааль… но объявляющих, что они и есть Грааль.

От Java и Flash в ранние времена до Cordova и Ionic, JavaScript/React и совсем недавно таких технологий, как Xamarin и Flutter.

Все они претендовали на трон. Мы — единственные. Напишите один раз. Запускайте где угодно.

Но на самом деле многоплатформенная разработка — это сложно.

Платформы используют разные языки и API. У них разные среды разработки и IDE. У них разные пользовательские интерфейсы и элементы управления, и, что самое главное, они ведут себя по-разному.

Внешний вид и ощущение

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

Ощущается ли мое приложение для iOS как приложение для iOS? Ведет ли мое приложение для Android себя как приложение для Android? Соответствуют ли они рекомендациям Apple по пользовательскому интерфейсу или рекомендациям Google по материальному дизайну?

Или что-то… не так?

Как я уже писал ранее, это основная проблема таких решений, как Flutter, которые, по большей части, просто имитируют элементы управления и пользовательского интерфейса платформы и отображают их собственную версию с помощью Skia.

И это также проблема Compose Multiplatform. CM использует Skiko, который, в свою очередь, снова использует Skia в качестве API графического рендеринга.

Для некоторых приложений такие несоответствия могут не иметь значения. Но для остальных? Ну, они могут иметь значение. Пользователи данной платформы, как правило, выбирают ее не просто так, и они хотят, чтобы их приложения вписывались в нее, вели себя последовательно и предсказуемо и хорошо интегрировались с другими приложениями и сервисами на данном устройстве.

Это подводит нас к последнему шагу в этом искусстве.

Kotlin Multiplatform

Опять же, цитируя сайт:

Там, где другие технологии абстрагируются или полностью заменяют разработку приложений для конкретных платформ, Kotlin Multiplatform дополняет существующие технологии для конкретных платформ и нацелен на замену бизнес-логики, не зависящей от платформы. Это новый инструмент в наборе инструментов, а не замена набора инструментов.

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

Затем вы используете эту логику на Android или переносите ее на iOS в качестве встроенной библиотеки.

Затем обе платформы используют этот код в сочетании со своими собственными интерфейсными библиотеками, возможно, Compose на Android и SwiftUI на iOS.

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

Пользовательский интерфейс пишется дважды, но основная логика, мозг приложения, пишется, проверяется и тестируется только один раз.

Это мощная, коварная концепция.

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

Почему?

Android First разработка

Самая большая проблема, конечно, заключается в том, что это неизбежно приводит к ситуации, которую я назову Android First Development.

Вся основная бизнес-логика, валидация и сетевое взаимодействие выполняются в Kotlin и в Android Studio. А поскольку экспорт библиотеки в iOS для использования в Xcode — это трудоемкий промежуточный шаг, имеет смысл сначала провести большую часть разработки и тестирования в Android.

Компиляция-выполнение-тестирование происходит гораздо, гораздо быстрее, если вы остаетесь на платформе.

А затем, когда вы убедитесь, что все работает, вы экспортируете библиотеку и отдаете ее разработчикам iOS, чтобы они подключили ее к пользовательскому интерфейсу.

Но это означает, что структура приложения и код были разработаны так, чтобы лучше всего подходить для Android. Интерфейсы приложения, сервисы и API были написаны на Kotlin и настроены для работы в среде Compose.

Но что происходит, когда эта библиотека попадает на iOS?

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

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

И что руководство скажет iOS-команде?

«Сделайте так, чтобы это работало».

Стагнация языка и платформы

Вторая большая проблема, как для разработчиков, так и для Apple, заключается в том, что тогда не имеет значения, какие классные изменения или функции добавляются в Swift, iOS или SwiftUI.

Это не имеет значения, потому что они не существуют на Android, и поэтому разработчики iOS не смогут их использовать.

Добавить async/await в Swift? Не имеет значения. В таком виде они не существуют в Kotlin, так что они становятся колбеками.

Добавить в Swift поддержку макросов или моделей? Отлично. Вот только все модели и модели представления — это промежуточные классы на базе Objective-C, перенесенные из Kotlin, поэтому их тоже нельзя использовать.

Перечисления с ассоциированными типами для управления состоянием? Извините.

Я мог бы продолжить, но вы поняли идею. В мире Android First Development, iOS превращается в гражданина второго сорта, где правят приложения с наименьшим общим знаменателем.

Android в первую очередь.

Решение Apple?

Каково же решение Apple?

Никакого.

WWDC 2023 прошла и закончилась, и не было ни одного упоминания о том, что что-то подобное уже поставляется или даже находится в разработке. Новые продукты, например, Apple Vision Pro? Конечно. О нем все слышали.

 

Новые дополнения к Swift и SwiftUI? Конечно. Они оба получили множество новых замечательных функций… которые большинство разработчиков не смогут использовать до 2024 или даже 2025 года!

Как я уже писал в статье “Apple сделала это снова”, Apple добавила новую, фундаментальную технологию в Swift и SwiftUI… а затем снова ограничила эту технологию так, что она работает только на iOS 17 и новейших версиях iPadOS, macOS и так далее (то, что они с такой любовью называют «выровненными платформами»).

Забудьте о нескольких платформах. Apple даже не может обеспечить обратную совместимость кода пользовательского интерфейса на своей собственной платформе!

А что с Compose, с другой стороны? Ну, об этом я тоже писал. См. “SwiftUI против Jetpack Compose: почему Android выигрывает не напрягаясь”.

Почему Google и JetBrains могут поддерживать более ранние версии своих платформ?

Действительно, как получилось, что они вообще могут поддерживать платформы конкурентов… а Apple — нет?

На этот вопрос есть простой ответ.

Платформы

В мире Apple кроссплатформенная разработка означает, что вы берете приложение и код для iOS и запускаете его на iPad. Или на часах Apple. Или на каком-либо другом устройстве в экосистеме Apple.

Но Android? Я не уверен, что во время всего выступления на WWDC было хотя бы одно упоминание Android как платформы.

Было ли упоминание Meta*? Нет.

Было ли упоминание о VR? Нет.

ИИ? Нет.

В мире Apple других технологий и платформ просто не существует.

Но проблема, конечно, в том, что они существуют.

Экосистема

Apple любит превозносить свою экосистему.

Во время анонса Vision Pro компания Apple несколько раз упомянула, что приложения для iOS и iPad будут доступны на устройстве, когда оно поступит в продажу.

Это работает, потому что сегодня почти все эти приложения были разработаны специально для iOS, с использованием инструментария iOS и инструментов платформы.

Но что происходит, когда вы ограничены возможностями другой экосистемы? Инструментами и возможностями другой платформы?

Что происходит, когда разработчики перестают разрабатывать в мире, ориентированном на iOS?

Корпоративное принятие

Как я уже писал в начале статьи, KMP-проекты будут в основном осуществляться корпорациями, желающими поверить в обещание «одного кольца, которое будет править всеми». В конце концов, это в их природе — «сокращать расходы» и «максимизировать прибыль».

Я читаю комментарии к своим статьям, подобные этому:

Каждый год у SwiftUI появляются новые возможности, но выбор Apple в пользу того, чтобы поставлять его как часть ОС, вынуждает нас отставать в разработке на 2/3 года, с урезанными или частично работающими функциями из-за ошибок в API, которые мы не можем использовать.

Google с Jetpack Compose для Android решил поставлять его в виде библиотеки (Compose — это эквивалент SwiftUI для Android) и, когда обнаруживаются ошибки, решение может быть найдено в следующей версии, выпущенной в течение 2 месяцев.

Именно по этой причине мы уже работаем с KMM (Kotlin Multiplatform Mobile), который в ближайшие 2 года позволит нам иметь один проект для нескольких платформ (Android, iOS и iPadOS), используя Compose для iOS в качестве пользовательского интерфейса, оставив политику обновления SwiftUI как кошмар прошлого.

А еще есть громкие истории, например, как Netflix публично принял Kotlin Multiplatform.

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

Я читал о других попытках, которые показывают, что внедрение KMP/CM, конечно, не так просто, как вы ожидаете. Такие истории вы можете прочитать, например, здесь, здесь или здесь.

Разработчики будут жаловаться на все проблемы интеграции. Они будут пытаться объяснить, что большая часть времени, сэкономленного на начальном этапе, будет съедена на последующих этапах при попытке проследить за всеми системами и увидеть, где именно скрывается конкретная ошибка.

Они укажут на то, что в системе есть еще одна серьезная зависимость, которая делает цепочку инструментов еще более хрупкой. Она препятствует переходу на новые версии iOS и iPadOS до тех пор, пока цепочка инструментов в свою очередь не будет обновлена Apple.

Или тот незначительный факт, что вы привязываете свой процесс разработки и приложения к сторонней библиотеке, которая еще не выпущена, еще не стабильна, и, насколько это возможно, в любой момент может быть отменена.

Неважно.

Притягательность Грааля сильна.

И если Apple не станет лидером, то это сделает кто-то другой.

Неважно, что здесь, в США, Apple является доминирующей технологической платформой.

Неважно, что здесь, в США, большинство пользовательских устройств работают преимущественно на iOS.

Если корпорация считает, что может сэкономить деньги, сделав iOS-устройства и клиентов гражданами второго сорта, то она так и поступит.

Если ИТ-директору скажут, что он может сократить бюджет на мобильные устройства на 30%, 40% или даже 50%, не думаете ли вы, что он посмотрит на это… со всем вниманием?

Конечно, это и близко не будет таким, но…

Притягательность Грааля сильна.

Swift работает на других платформах, а SwiftUI с его уникальным дизайном мог бы стать настоящим кроссплатформенным набором инструментов.

Мы могли бы жить в iOS First мире.

У Apple был шанс возглавить гонку.

Они отреклись от власти.

Итоги

Я думал над этим вопросом некоторое время.

Я все еще верю в iOS-разработку, в инструменты и технологии Apple. Я считаю, что SwiftUI быстро становится одной из лучших библиотек пользовательского интерфейса.

Но снова, снова и снова Apple ставит перед разработчиками препятствия. Начиная с WWDC 2020 и далее, они мешают разработчикам реально использовать почти каждый новый инструмент, API и усовершенствования, которые они создали и анонсировали.

Их выбор и политика привели их к этому моменту.

И я даже не уверен, что они знают, что он настал.

Источник