Тема розкриє наступні тези з тематики обробки відео:
- Вирішення проблеми композиціі відео та аудіо в iOS
- Синхронізація інтерфейсу з таймлайном композіціі
- Труднощі при роботі з AVFoundation

Grab Passenger is a SupperApp. There are 2M+ lines of code, 200+ engineers supporting multiple teams, and millions and millions of users depending on Grab daily. The codebase growth is quite rapid and build time has been growing at a similar rate. We decided to migrate to a scalable alternative build system - Bazel. We planned an incremental migration where 2 build systems live in harmony and continue to migrate while keeping uncompromising developer experience. We would like to share how we made incremental adaptation possible.

Здається, священна війна Інтерфейс Білдера проти Інтерфейсу з Коду триває вічно. У червні 2019-го Apple перетворила цю дуель на мексиканську, випустивши Swift UI. Ми спробуємо розібратися у цьому протистоянні та знайти відповіді на одвічні питання: хто правий і що робити з легасі кодом?

- Підходи до інтерфейсу: IB vs. Code vs. Swift UI.
- Пишемо підтримуваний UIKit код.
- Додаємо WYSIWIG у код на UIKit за допомогою Swift UI Previews.
- Розбираємось у реалізації Swift UI Previews, щоб прискорити гаряче оновлення.

У рішеннях з ізольованим глобальним стан часто з'являється проблема контролю складності цього стану з його зростанням. Одним із стандартних рішень в такому випадку вважається нормалізація стану і надання шару селекторів, які працюють з нормалізованим станом. Недолік даної практиці полягає в її епізодичній структурі - селектори додаються не для всіх даних, часто команди дублюють селектори не знаючи про те що частину логіки вже реалізовано в інших селекторах. Протягом останнього року ми почали використовувати граф-систему як альтернативу селекторам. Досвід використання виявився вкрай позитивним і я вирішив поділиться цим підходом зі спільнотою. Граф-система являє собою тонкий шар поверх нормалізованого стану, який надає інтерфейс до нормалізованого стану у вигляді графа сутностей. Цей граф дозволяє інкапсулювати деталі імплементації стану, логіку селекторів, і логіку мутації. В результаті використання граф-системи підвищується зручність використання моделі даних кодом додатку.

- Що все ж таки тестувати?
- Я пишу код без багів, нащо мені тести?
- Еволюція коду
- Труднощі з интеграцією тестів у великий проект
- Як зробити проект трішечки тестованим
- Проблеми з "тестами не на часі"

Grab serves millions of users across South East Asia. There are hundreds of engineers supporting our mobile applications. And given the scale of the codebase, the build time became a bottleneck demanding strategic changes. And migration to Bazel was a matter of time and the time has come. Now we aim for a fast and correct build. Though how we got to this decision and what obstacles we had to overcome is the story itself which we'd like to share.

Рано чи пізно, працюючи над продуктом, кожен розробник повинен перейти зі стану "я тут щоб писати код" до "я тут щоб писати робочий код, який зробить мій проєкт краще", тож, в решті решт, усі шляхи ведуть до UX.
Ми розберемось що це за птах, а також чому нам, розробникам, треба у це занурюватись
Поговоримо про конкретні дії, які допоможуть нам в цьому (і проговоримо про те, як точно не треба робити).
Розберемо реальні кейси продукту-мільйонника та подивимося на те, які показники бізнесу вдалося збільшити через них.

Вадим продемонструє чотири техніки, які дозволять робити ваші тести кращими, а саме:
- Як мокати асинхронні залежності у синхронний спосіб?
- Signaling з використанням XCTestExpectation
- Перевірка значення до/після виконання
- Використання busy assertions

Ми звикли до того, що тестабельний додаток – це додаток, що покрито юніт тестами. Швидкість, зручність, і дуже часто навіть сама можливість протестувати щось у ручному режимі в додатку, як правило, вже не цікавлять программістів. У своїй доповіді ми розповідатимемо який value дає планування тестування додатку на етапі розробки, і як це може стати фундаментом для просунутих тестів у майбутньому. А на "десерт" поділимось своїм досвідом та напрацюваннями.

Що таке продуктове мислення і чому для кар'єри інженера воно важливе так само, як і технічні навички? Як воно допомагає розвивати бізнес?

Поговоримо про кілька прийомів продуктового мислення, які ви зможете одразу застосовувати у вашій роботі:
* Опрацювання системи цінностей у продуктовому підході до роботи
* Налагодження ефективної комунікації з менеджером продукту
* Формування емпатії до користувачів та розуміння їхніх проблем
* Вивчення конкурентів продукту та індустріальних трендів
* Робота з даними: пошук відповідей на продуктові запитання.

В рамках цього унікального онлайн-воркшопу ви матимете можливість разом з професійними розробниками з Wix створити свій перший крос-платформений додаток з використанням ReactNative. Протягом воркшопу ви працюватимете у групах з ментором, який допоможе з вирішенням можливих проблем протягом розробки додатку. Кількість місць обмежена - обов'язкова попередня реєстрація у формі:
План воркшопу:

1. Інтро. Налаштування оточення для розробки з ReactNative. Створення проекту
2. Навігація у додатках, виконаних за допомогою ReactNative
3. Життєвий цикл та отримання даних
4. Розмітка інтерфейсу та відображення даних
5. Процесс публікації
6. Q&A Секція

At Wix, we are ~120 mobile developers, from 40 different teams spread across 3 countries, building, with React Native, the official Wix app used by millions of users across the world. Scaling a production-grade application without compromising on performance and dev velocity, brought us to a unique multi-module architecture that allows each team to work fully independently and in the end integrate their code into the main Wix app. In this talk, we will start from an overview of company structure and see how it is reflected in our mobile architecture, following that we will go over the basic React-Native concepts and understand how it fits multi-module architecture while going over the full development process when working at scale, through testing, building and releasing the app to the stores.