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

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

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

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

Этот воркшоп — симуляция работы проектной команды, которая создает мобильное приложение «с нуля». Участники примеряют на себя роли PM, TL, разработчиков и проходят через весь цикл: от сбора требований до «визуальной» реализации. Формат сочетает в себе веселый квест с настоящими управленческими и инженерными задачами, показывая ценность слаженной командной работы и четкой коммуникации.

В ходе игры вы не только погрузитесь в вашу роль, но и во все аспекты разработки: от сбора требований до проведения демо.
А дополнительные внешние события помогут (или нет) справиться (или нет) быстрее.
Кроме этого, вы прочувствуете ценность тайм-менеджмента и коммуникации

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

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

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

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

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

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

Можно ли с нуля переписать большой модуль, от которого зависит большая часть банковского приложения, когда само приложение живет в AppStore 24 часа? Да, и не только!

В докладе я расскажу:
* как зародился критически важный для бизнеса нефинансовый модуль в СберБанк Онлайн;
* как мы поняли, что прошли точку невозврата;
* как выглядела архитектура «до» и «после»;
* как мы писали новые фичи, пока переписывали старые;
* как выводили рефакторинг в пром;
* какие были сделаны выводы.

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

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

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

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

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

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

Приносите с собой ноутбуки - будет несколько практических заданий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📌 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. 🚀

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

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

В рамках доклада мы разберем:
* как работают оверлеи ресурсов под капотом;
* рассмотрим, как изменять ресурсы приложения на лету без необходимости повторной компиляции;
* реализуем обфускацию ресурсов приложения;
* разберем возможные векторы атак на мобильные приложения с использованием оверлеев ресурсов;
* поисследуем ОС и рассмотрим, как можно запретить установку своего приложения на определенных устройствах;
* разберем баг в ОС, позволяющий удалять свое приложение без взаимодействия с пользователем.

Нам всем приходится релизить наши приложения, в разных компаниях мы часто сталкиваемся с одними и теми же проблемами/вопросами касательно самого процесса. Как эти проблемы решены в крупных компаниях, где есть сильная платформенная команда, которая постоянно работает над улучшением developer experience? В своем докладе расскажу, как выстроен весь процесс релиза наших приложений от написания кода до 100% раскатки во всех сторах.

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

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

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

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

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

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

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

Нетворкинг-столы будут работать в холле 1-го этажа согласно расписанию, опознавательный знак — табличка с названием темы.

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

Нетворкинг-столы будут работать в холле 1-го этажа согласно расписанию, опознавательный знак — табличка с названием темы.

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

Нетворкинг-столы будут работать в холле 1-го этажа согласно расписанию, опознавательный знак — табличка с названием темы.

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

Нетворкинг-столы будут работать в холле 1-го этажа согласно расписанию, опознавательный знак — табличка с названием темы.

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

Нетворкинг-столы будут работать в холле 1-го этажа согласно расписанию, опознавательный знак — табличка с названием темы.