Всем привет! Меня зовут Саша, я iOS-разработчик компании Ozon. Я занимаюсь разработкой и развитием мобильного приложения продавца. Сегодня хотел бы поделиться опытом нашей команды по кастомизации онбординга для вашего мобильного приложения.

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

- Как представить новую фичу пользователю?

- Как сделать так, чтобы пользователь не пропустил добавленный функционал?

- Как повысить количество взаимодействий с новым функционалом?

Также возникает вопрос упущенного этапа продажи новой фичи — подача обновления пользователю.

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

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

- Делать свою или взять готовую? Прыг.

- Платформенная или универсальная? Прыг.

- Версионировать компоненты или всю библиотеку? Прыг...

И ещё много таких «прыгов».

Давайте подготовимся к сложному контенту. Закроем глаза, успокоимся и представим идеальную дизайн-систему. Представили? Умные компоненты, продуманные паттерны, подробная документация. Автоматическая генерация кода. Кайф? А то! Только такая дизайн-система оставит нас без работы.

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

Спойлер - нет! Ну, не совсем. Мы привыкли воспринимать UI как визуальную составляющую, но ведь UI – это User Interface. Так вот, интерфейс – это то, с помощью чего пользователь взаимодействует с нашим приложением. В случае с графическим интерфейсом пользователь его видел и воспринимает информацию. Однако он статичный и, когда пользователь хочет взаимодействовать с ним, он использует другие интерфейсы: тачскрин, клавиатуру или мышку. Да, это тоже интерфейсы. И UIKit как раз таки отвечает не за графический интерфейс, а за распознавание пользовательских жестов и их обработку.

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

Так как же он устроен? У нас же есть базовый класс UIView и куча его стандартных наследников. Мы можем сами создавать свои вью и как угодно их кастомизировать. И все это видим на экране. Почему тогда UIKit и UIView – это не про графический интерфейс? Давайте разбираться.

Всем привет! Меня зовут Андрей, и я делаю iOS-приложение для продавцов Ozon Seller. Наша команда поставляет фичи, красит кнопки, работает над перформансом и  всячески улучшает пользовательский опыт работы продавцов на Ozon.

Нашим приложением активно пользуются юзеры из разных стран, и поэтому день Х, когда мы решим добавить поддержку разных языков, был неизбежен. В этой статье я расскажу про стандартный процесс локализации iOS-приложения, про то, с какими трудностями мы столкнулись и как их решили. Разберём системный алгоритм определения языка и объясню, почему он нам не подошёл. Сделаем перевод приложения «на лету», а также посмотрим, как изменился наш флоу работы со строками.