У нас в проекте был Compose Multiplatform, но снова я бы так не делал

Мобильная разработка продолжает развиваться, но, если честно, никаких революционных прорывов в последнее время не произошло. Громкие темы, вроде Kotlin Multiplatform (KMP), Flutter, Jetpack Compose, SwiftUI, уже давно закрепились в индустрии, а новинки больше эволюционируют, чем меняют правила игры. Компании экспериментируют с кроссплатформенными решениями, и это выглядит логично. Писать общий код для iOS и Android 一 это экономия ресурсов и времени. Вроде бы верно, но на практике всё не так гладко.

Привет, меня зовут Максим Плахута и с недавнего времени я руковожу Android разработкой «Кинопоиска». До этого руководил мобильной разработкой Почты Яндекс. А ещё я участник ПК новой конференции по мобильной разработке Apps Conf. Расскажу, какие шишки набили в реализации кроссплатформенного проекта и чего лучше не делать в современной мобильной разработке.

Как мы адаптировали потоковую передачу на Android

Моя первая серьёзная работа с видеостримингом в мобильных устройствах началась ещё во времена Android 4. Тогда существовали жёсткие ограничения на количество видеопотоков, которые устройство могло обрабатывать одновременно. Рынок кишел китайскими смартфонами с нестабильными характеристиками, разными типами процессоров и непредсказуемыми возможностями декодирования.

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

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

Это позволило:

• Стабилизировать работу приложения даже на слабых устройствах.

• Оптимизировать нагрузку на процессор и память, перераспределяя потоки.

• Обеспечить плавное воспроизведение видео без артефактов и лагов.

Фактически, пользователь просто включал видео 一 и оно работало. Без рывков, задержек и зависаний, хотя под капотом происходила сложная адаптация под конкретное железо. Нагрузка на устройство снизилась, что означало также и рост среднего качества просматриваемого видео на тех же сетях и это подтверждали пользовательские отзывы.

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

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

Разработка под давлением

Представьте, что вам нужно запустить мобильное приложение за 3 месяца, а команда только что собралась! Её  сформировали с нуля, причём искали разработчиков с разными компетенциями. Нужен был стек сразу под iOS и Android. Да ещё как-то оптимизировать процессы, чтобы уложиться в сжатые сроки.

У нас не было выбора — мало людей и времени, при этом нужно либо максимально катить фичи, либо поставлять такое же количество фичей, но сразу на две платформы. Возникнет вопрос, почему не Flutter? И у меня есть ответ:  look and feel нативных приложений. Конечно, и такие проблемы решаются. Но нам важно было не только решить текущие проблемы, но и подумать о поддержке решения в будущем, когда нас на проекте уже не будет.

 Обычно в таких проектах общий код ограничивается сетевым или дата-слоем, но мы пошли дальше и вынесли в кроссплатформенную часть бизнес-логику. Понадеялись на глубокие знания команды: понимание различий между iOS и Android, разработку кросс-платформенных API, которые должны были одинаково работать на обеих платформах. Ставку сделали на Kotlin Multiplatform (KMP).  Она, как раз таки, позволяла писать общую бизнес-логику для обеих платформ. Но мы сошли с ума и решили накрутить compose multiplatform, чтобы получить дополнительный таргет в виде десктопа (получили) и возможности закрывать лёгкие неважные фичи (типа экрана about) единоразовыми трудозатратами. И это была ошибка.

Да, такой подход дал нам преимущества в скорости разработки, но привёл к сложностям: некоторые Android-библиотеки не имели аналогов на iOS, что требовало кастомных решений. Кроме того, в KMP существуют проблемы с инструментами, особенно при генерации обёрток для Swift.

Пришлось постараться, обеспечивая взаимодействие между командами iOS и Android. Столкнулись мы, конечно, с обычными проблемами — необходимость погружаться в Kotlin код, сложные нечитаемые стактрейсы в случае проблем, очень ограниченная поддержка дебага. Но были и неожиданности: например, отсутствие compose preview. Не говоря уже про paginglibrary, поддержку dragndrop, которые пришлось выносить в expect/actual. Также мы словили проблемы всех early adopters — непонимание что и в каких версиях заехало в адаптированных библиотеках. Также получили невозможность использовать популярные решения типа Accompanist – они не имеют поддержки и приходится либо искать что-то другое, либо реализовать самостоятельно.

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

Сложности сборки и проблемы кроссплатформенных решений

Гонка мобильной разработки всё ускорялась. Все хотели как можно сильнее сократить Time to market, и без кроссплатформенных решений было не обойтись. Поэтому, из-за своего бэкграунда, я сталкивался с ними на каждом втором проекте. Или даже чаще. Но проблема, как это часто бывает, заключается в недостаточно продуманных инструментах. И даже, если кто-то скажет что «плохому танцору» всегда что-то мешает, я отвечу 一 может и так. Но танцевать в туфлях на три размера меньше, — то ещё удовольствие.

В нашем решении Kotlin Multiplatform показала себя хорошо, но в части Compose Multiplatform всё же пострадала производительность за счёт решения проблем, которых могло бы и не быть.

Давайте обосную своё мнение. Я уже говорил, что не стал бы использовать  и Compose Multiplatform в текущем виде, и вот почему:

Разные реализации API и неполнота функционала. Когда мы пробовали использовать Compose Multiplatform, то столкнулись с неожиданными проблемами.

Отсутствие полного соответствия API. Некоторые вещи, к которым разработчики Android привыкли, просто не работали или работали иначе.

Писать код приходилось с костылями. Мы создавали решения, которых не должно было быть в идеальном сценарии. 

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

Отсутствие библиотек и адаптации. Ещё одна проблема 一 молодость технологии. Когда мы начали работать с Compose Multiplatform, стало ясно, что поддержка библиотек оставляет желать лучшего. Многие популярные решения просто не были адаптированы, а искать альтернативы 一 дополнительная работа.

Особенно сильно мы споткнулись на адаптации нашей дизайн-системы под Windows-платформу. Это оказалось настолько сложным процессом, что мы в какой-то момент задумались: а стоило ли вообще начинать?

Накладные расходы на поддержку и обучение. Любая новая технология требует времени на обучение команды и адаптацию процессов. Здесь важно учитывать профиль команды. Если у вас перевес в сторону Android-разработчиков, то кроссплатформенные решения могут дать выигрыш, потому что iOS-адаптация будет проще. Если команда уже сбалансирована, то мультиплатформа скорее замедлит разработку, чем ускорит. Да, бытует мнение, что чинить баг один раз будет выгоднее на дистанции. Но, по факту, если разбирать его будет iOS разработчик, вы потеряете время из-за недостаточного тулинга. Либо весь багофикс целиком уйдёт в Android-команду, что приведёт к разбалансирвоке в реализации фич. И никакой сбалансированной команды не получится. Некоторые вещи, которые нативно работают идеально, в кроссплатформенном коде могут вести себя нестабильно.

Поэтому перед тем, как принять решение о внедрении мультиплатформенного подхода, важно оценить зрелость процессов и готовность команды к таким изменениям. А чтобы всё это уверенно качать нужно комьюнити. Внутреннее сообщество, пусть и небольшое, позволяет решать многие проблемы быстрее и проще. И из него в итоге легче выходить в большое профессиональное сообщество.

Как мы сделали «Яндекс 360» более узнаваемым

Когда я пришёл в Яндекс 360, внутри компании и тем более за её пределами не понимали, чем именно мы занимаемся. Хотя мы разрабатывали действительно крутые решения. Наши технологии влияли на миллионы пользователей, как бы это пафосно не звучало, но мы об этом не рассказывали. Представляете, какая упущенная возможность не только для позиционирования, но и для привлечения новых талантов, обмена опытом и участия в профессиональном сообществе? Именно поэтому мы решили развивать внутреннее и внешнее комьюнити, чтобы открыто делиться своими разработками, решениями и челленджами.

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

Мы сделали ставку на несколько ключевых направлений:

1. Выступления на конференциях. Мы не просто участвовали, а формировали присутствие Яндекс 360 как технически сильной команды. Выступали с докладами про Kotlin Multiplatform, архитектурные решения, CI/CD-процессы, продуктивность разработки и многое другое.

2. Подготовку качественного контента. Мы не ограничивались докладами, а писали статьи, организовывали митапы и записывали подкасты. Это помогало продвигать наши идеи на широкую аудиторию.

3. Сценарное развитие докладчиков. Мы не просто готовили отдельных спикеров, а системно развивали культуру публичных выступлений. Помогали коллегам оформлять мысли, правильно выстраивать повествование, делать доклады более живыми и увлекательными. Одним из самых удачных форматов стали «Смузи-доклады». Мы превратили технические презентации в выступления, стараясь разбавить сложный технический контент живыми историями, юмором и интерактивом. Это помогало доносить сложные темы в доступной форме, запоминаться и вызывать эмоции у более широкой аудитории.

Самое интересное, оказалось, что развитие комьюнити 一 это не только PR, а возможность развиваться самому и помогать расти другим. У нас получилось создать активное и профессиональное сообщество, и мне приятно, что я могу быть полезен ещё большему количеству людей. Поэтому я и вошёл в состав программного комитета новой конференции по мобильной разработке Apps Conf. Хотя это уже не просто личная инициатива, а стратегический подход к развитию технологий и сообщества) И тут очень важно, не только готовить базу, но и двигаться с опережением — планировать то, что, возможно, произойдёт, представлять, куда будет двигаться всё направление в целом.

Тренды, вызовы и новые возможности мобильной разработки

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

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

Как работать сейчас, чтобы потом не пришлось в панике адаптироваться к новым реалиям?

Среди технических трендов самые интересные направления:

• Искусственный интеллект. Автоматизация и AI-инструменты, например, для генерации кода, тестирования, оптимизации пользовательского опыта и CI/CD становятся не просто удобным дополнением, а необходимостью. Поэтому, логично, что разработчики, которые научатся интегрировать AI в свои продукты, получат серьёзное преимущество.

• Эволюция кроссплатформенных решений. А один из главных векторов развития 一 объединение платформ и рост эффективности. Компании ищут способы сократить время разработки, уменьшить дублирование кода и оптимизировать ресурсы. JetBrains упразднили отдельное IDE Fleet для кроссплатформенных проектов в пользу интеграции тех же инструментов в Android Studio.

На самом деле, подобные изменения происходят везде. К примеру, Kotlin Multiplatform (KMP) постепенно становится стандартом для кроссплатформенной мобильной разработки, несмотря на вызовы, связанные с производительностью и интеграцией с iOS. Хотя его всё ещё сложно назвать зрелым решением, будет интересно наблюдать, как индустрия адаптируется.

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

• Рост автономных систем и офлайн-режима. Чем больше данных обрабатывается на устройстве без обращения к серверу, тем лучше. Это касается ML-моделей, работы с видео и персонализации контента.

• Новые подходы к UI/UX. Jetpack Compose и SwiftUI доказали свою состоятельность, но продолжают развиваться. Бэкенд для фронтенда (BFF) и server-driven UI набирают популярность, позволяя мобильным приложениям быстрее адаптироваться к изменениям. Возможно, мы увидим новый стандарт UI-разработки, основанный на декларативном подходе.

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

Несмотря на развитие технологий, в мобильной разработке остаются незакрытые вопросы, которые активно обсуждаются в мировом комьюнити. Среди них производительность кроссплатформенных решений. Несмотря на все успехи KMP и Flutter, они всё ещё уступают нативным решениям по скорости и интеграции с платформенными API.

А ещё сейчас в Android и iOS разработке нет единого «золотого стандарта». Кто-то использует MVI, MVVM, VIPER, кто-то — чистую архитектуру или свои кастомные решения. Это приводит к тому, что каждая команда фактически изобретает велосипед.

Какие фундаментальные знания и технологии важно изучать, чтобы оставаться востребованным?

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

В Яндексе, например, мы видим четкую тенденцию. Разработчик должен не просто писать код, но глубже понимать, зачем он это делает. Софт-скиллы и проджект-менеджмент становятся важнее. Даже синьоры наравне с тимлидами учатся управлять процессами, анализировать требования и предлагать лучшие пути реализации. Поэтому ни для кого не станет страшным секретом, что успешными разработчиками будут те, кто сможет адаптироваться и учиться новому.

Если говорить о минимальном техническом стеке, сейчас мобильному разработчику надо знать:

• Для Android: Kotlin, Jetpack Compose, архитектурные паттерны (MVI, MVVM), многопоточность и асинхронные операции (Coroutines, Flow).

• Для iOS: Swift, SwiftUI, Combine, глубокое понимание работы системы и многозадачности.

• Общие навыки: CI/CD, оптимизация производительности, работа с сетевыми запросами, адаптация UI под разные платформы.

• Глубокое понимание платформенных API и работы системы — оптимизация производительности, энергопотребление.

Но ключ к успеху – это не просто знание инструментов, а понимание принципов разработки. Чем глубже залезаешь в основы — тем проще адаптироваться к любым изменениям в индустрии. Поэтому начинать прокачиваться лучше с базовых источников: «Effective Kotlin» – Марцин Москальский, «Clean Code» – Роберт Мартин, Документация по KMP, Jetpack Compose и SwiftUI.

А ещё посещать профессиональные мероприятия как Apps Conf. Это всегда помогает быть в курсе актуальных проблем отрасли, разбираться в трендах и чувствовать, чем живёт индустрия! Плюс приятно и полезно найти новых коллег или работодателей, послушать про опыт других команд, вдохновиться и найти решения для собственных проектов. Поэтому приглашаю на конференцию!