Расскажу о том, как мобильные разработчики живут с дизайн-системой. Аудитория узнает о повседневном опыте из разных областей:

— взаимодействие с продуктовыми командами;
— дежурство в чате;
— новые инструменты дизайн-системы (передовой инструмент для дизайн-ревью прямо на девайсе);
— создание дизайн-системы с нуля на Jetpack Compose;
— сбор метрик перформанса Compose;
— отладка верстки PixelPerfect;
— синхронизация дизайна и кода;
— и многое другое!

Посмотрим, как может выглядеть Unidirectional Data Flow архитектура под iOS.
Взглянем на тулбокс, с помощью которой будем организовывать UDF
Разберем, один из способов организации проекта с использованием Service Oriented Architecture, Redux и SwiftUI

Android Runtime Resource Overlay -- крутая, но совсем не распиаренная тема. Технология позволяет приложению модифицировать собственные ресурсы и ресурсы других приложений прямо в рантайме, на лету. В основном RRO пользуются разработчики мобильных ОС для создания системных оверлеев для системных приложений. Однако и обычные приложения могут воспользоваться преимуществами оврлеев ресурсов, и для этого не требуются какие-либо специальные разрешения от пользователя.

Почему тема не очень популярна среди обычных приложений? Тут есть несколько мыслей, которые образуют ответ. Во-первых, self-targeting оверлеи, которые могут создать и применять обычные, не системные приложения появились относительно недавно, с Android API 34. Второй момент -- отсутствует документация, так что данное API можно вполне назвать незадокументированным. Разработчики привыкли полагаться на проверенные официальные источники и гайдлайны, а здесь буквально нужно читать код ОС, чтобы понять что к чему.

Я, как исследователь операционной системы Андроид, практически все время провожу за изучением кода ОС и проверке гипотез, которые могли бы повлиять на безопасность системы. И когда я обнаружила такой функционал, очень удивилась, что он вообще никак не задокументирован. Мне кажется, это может быть связано с тем, что тема достаточно новая, и есть еще ряд сырых моментов в ее имплементации. Уверена, Google со временем сможет опубликовать данный API и сделать его полноценным.

Что расскажу в своем докладе:

1. Android Runtime Resource Overlay: обсудим сперва в общих чертах, что это, как это работает и зачем оно нужно, где применяется.

2. Разберем виды оверлеев ресурсов. Бывают системные оверлеи и self-targeting оверлеи. Также бывают приложения-оверлеи, когда источником ресурсов выступает отдельный APK (статический оверлей), а также бывают fabricated overlays (фабрикованные оверлеи), которые создаются на лету, их можно создавать прям в рантайме (динамический оверлей ресурсов).

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

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

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

6. Бонус-chapter. Разберу технические детали найденных мною уязвимостей в Android Auto. Но пока жду решения Google по багам.

Обсудим, как сейчас выглядит процесс разработки виджета рабочего стола на Android, а также с какими трудностями предстоит столкнуться

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

Что вас ждет:
1. Kotlin Compiler: За кулисами
- Краткий разбор архитектуры компилятора: от AST до генерации байткода.
- Как плагины вмешиваются в этапы компиляции и меняют код.
2. Создаем свой Kotlin Compiler Plugin
- Как написать свой плагин.
- Разберем основные методы и базу необходимую для создания плагина.
3. Пишем свой Kotlin Compiler Plugin самостоятельно
🛠 Напишем свой плагин KCP
💻 Готовый код на GitHub: Участники заберут шаблоны для своих проектов.

Что такое CI/CD и как он работает? Какие отечественные инструменты вам помогут? Пайплайны, артефакты, релизы - пишем код, чтобы не делать работу руками. Релизим в RuStore нажатием кнопки!

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

На данный момент основной стек разработки под Аврору – это Qt/QML 5.6 и C++. И хотя помимо базового стека доступна также разработка на фреймворке Flutter, мой воркшоп будет посвящен разработке приложения на Qt/QML.

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

Долгие годы во всех проектах Туту мы использовали Cocoapods как основной менеджер зависимостей. Однако наша цель как Core-команды — давать инженерам из продуктовых команд возможность беспрепятственно развивать и улучшать наши продукты, и с Cocoapods это стало проблемой. Становится больше фреймворков, дистрибуция которых осуществляется только через SPM, с некоторыми мы столкнулись лично. Сам проект Cocoapods вошел в режим поддержки, этап активного развития завершен. Тем временем Apple активно развивает SPM, на него-то мы и решили переехать.

Нам удалось перевезти все наши вспомогательные фреймворки и 4 публикуемых в стор приложения за 3 месяца и убрать все блокеры, которые были у нас на Cocoapods. А бонусом мы получили снижение размера наших приложений на 30-50%, ускорение запуска приложений на 40%. Кроме того переезд прошел практически бесшовно для всех iOS-разработчиков компании.

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

Что нужно, чтобы развивать и выпускать несколько приложений и SDK на основе одной кодовой базы? Многомодульность!

А что если мы ходим:
- Переиспользовать не только отдельные классы, а целые фичи, с разным UI, зависимостями, навигацией, но с той же логикой.
- Поставлять зависимость, просто подключив модуль, но не меняя код в других местах.
- Организовать модули так, чтобы не запутаться, не толкаться и иметь возможность быстро масштабировать фичу на другие приложения.

Опыт трансформации Кинопоиска в этом докладе

Расскажу о том, как мы построили целую систему, которая включает в себя разметку кода в iOS/Android приложениях владельцами, умеет собирать информацию о техдолге в различных командах, отправлять ее на наш Golang микросервис, а также доставлять командам для удобного планирования работы с техдолгом

Шейдерные анимации позволяют ускорить генерацию графики за счёт использования ресурсов GPU и реализовывать самые смелые задумки дизайнеров. На Android существует несколько технологий, с помощью которых можно их реализовать. Начнём с классической реализации пиксельных шейдеров на OpenGL. Затем рассмотрим Vulkan, высокопроизводительный графический API, который Google активно продвигает в последних версиях Android. В заключение обратимся к возможностям шейдеров на AGSL, поддержка которых появилась в Android 13 и встроена в графический пайплайн. Посмотрим на преимущества и ограничения каждой из технологий и сравним результаты.

- Точно ли нужно переезжать если итак всё работает?
- Как приложение с Fragments на MVP перевезти на Compose, стратегии переезда;
- Что делать с архитектурой;
- Дизайн система;
- Как не просесть по перфомансу
- Что делать с навигацией
- Обучение разработчиков

Периодически у каждого iOS-разработчика возникает соблазн поручить написание всех unit-тестов GPT, DeepSeek или Qwen. Но в этой «эхо-камере», где модели подтверждают собственные предположения, часто теряются нюансы архитектуры и моков, а критический анализ упускается из виду. Главная проблема — донести до нейросетей полный контекст проекта. Если он окажется некорректным, вместо экономии времени нас ждёт дополнительная доработка.

В своём докладе я расскажу, как заставить AI справляться с рутинными и шаблонными частями работы: быстро создавать каркас теста, который мы адаптируем и наполняем нужными деталями. Поделюсь, как сохранять контроль над качеством, не погружаясь в бесконечную ручную генерацию, и кто из тройки — GPT, DeepSeek или Qwen — справляется с этим лучше остальных.

Наконец, объясню, почему «написать все unit-тесты, не написав ни одного» — лишь метафора.

1. Как всё начиналось:
Погрузимся в историю процессов мобильного тестирования в нашей компании. Какие подходы мы использовали раньше и с какими вызовами столкнулись.

2. Почему пришло время меняться:
Что заставило нас пересмотреть существующие процессы? Реальные кейсы, которые показали, что старые методы больше не работают.

3. Исследование рынка: что предлагает мир тестирования?
Обзор инструментов и решений, доступных на рынке. Какие из них мы рассматривали и почему многие не подошли под наши задачи.

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

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

6. Финал: как мы начали экономить без потери качества:
К чему мы пришли в итоге? Как нам удалось оптимизировать процессы тестирования, сократить затраты и при этом повысить эффективность.

LLM обладают огромным потенциалом, но текущий подход к их использованию сталкивается с существенными вызовами: высокая стоимость вычислений, уязвимости при передаче бизнес-данных сторонним компаниям и т. д.
Современные устройства Apple с интеграцией технологий Apple Neural Engine (ANE), Metal Performance Shaders и Core ML, способны эффективно запускать LLM локально, решая проблемы, приватности и безопасности данных, закладывая фундамент для будущих возможностей локальных ИИ агентов. Это может привести к снижению серверных расходов и разработке бизнес-приложений нового типа, например, обработка изображений, распознавание данных и многое другое.

Внедрение ИИ-решений в приложения становится трендом. Многие компании разработали и представили собственные LLM в виде AI-ассистентов и помощников, как в веб, так и встраиваемом в IDE решениях.
Рассмотрим практические примеры использования различных готовых сетей при разработке KMP-приложения. Обсудим, какие подводные камни могут встретиться в работе и как применять такие инструменты корректно и безопасно. Также посмотрим, как подготовить свое решение на основе открытой LLM.

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

В процессе разработки новых функций и модификации существующих мы часто сталкиваемся с ограничениями текущих API, что подталкивает нас к необходимости создания более гибких и универсальных решений.
В своем докладе я продемонстрирую этот процесс на примере супераппа Yandex Go, где мы пришли к использованию BDUI, а также расскажу о нашем опыте в стартап-сервисе Межгород.
Сделаю анализ трейдоффов между нативными решениями, ad hoc BDUI подходами и сложными системными решениями, такими как DivKit.

Будут рассмотрены такие вопросы, как Android Platform, Android Build Process, AOSP, Bytecode modification, Screenshot Testing with Robolectric.

📌 How can AI improve without compromising privacy?

As AI becomes integral to mobile experiences, privacy concerns continue to rise. Traditional machine learning requires sending user data to the cloud, raising security risks. But what if we could build smarter AI without ever exposing personal data?

This is where Federated Learning on iOS transforms mobile AI. Instead of transferring raw data, models train directly on devices, and only encrypted updates are shared—aligning with Apple’s privacy-first vision.

In this session, we’ll deep dive into Federated Learning, covering:
✔️ How Federated Learning is shaping the future of AI on iOS
✔️ Implementing privacy-preserving machine learning using Swift, Core ML, and Create ML
✔️ Performance optimizations for real-world applications

This talk is for developers, architects, and AI enthusiasts looking to integrate on-device AI while maintaining data privacy, security, and efficiency.

Join us to explore this game-changing shift in iOS AI development and learn how to build the next generation of privacy-first, AI-powered applications. 🚀

Максимум действия и минимум теории!

Деловая игра на понимание бизнес-команды при переговорах о разработке.

Наша цель – начать разбираться в людях со стороны бизнеса и в том, как влиять на них при переговорах.

Мы сосредоточимся на следующем:
1. Понять кто участвует в переговорах, чего хочет, как с ним/с ней разговаривать.
2. Что важно для меня и что важно для членов бизнес-команды в разработке и переговорах.
3. Как работать со "странными" требованиями и как аргументировать мою позицию как эксперта каждому члену команды со стороны бизнеса.
4. Как быстро и адекватно реагировать на предлагаемые изменения

В докладе я расскажу:
• Как разработчик может менять процессы и почему софт-скиллы важны не меньше технических навыков.
• Как через маленькие изменения можно прийти к большим улучшениям: кейс про стандартизацию UIKit и выстраивание взаимодействия в команде.
• Как мы превратили фрустрацию в драйв: что делать, если никто не хочет менять процессы, а работать в хаосе уже невозможно?
• Ошибки на пути изменений: сопротивление команды, сложности в коммуникации и как их преодолевать.
• Как правильно презентовать идеи и внедрять их в команду так, чтобы это не вызывало отторжения.
• Почему навыки убеждения и адаптации важны даже в технических ролях и как их развивать.