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

Описать метериал через шейдер сложно, а создать динамичный эффект — ещё сложнее. В этой статье разберём пару примеров: переливающийся диск и нашумевший NameDrop в iOS 17.

В мобильной разработке мы постоянно имеем дело с векторной графикой: ячейки — прямоугольные, аватарки — круглые, текст — это векторные формы. В пиксели это всё превращается без нашего ведома и как-то само.

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

В iOS 17 пришло значимое обновление — теперь добавить шейдер можно к любой View, а значит, вся интеграция стала проще и растровых эффектов появится больше.

Давайте разбираться, что за чудо-код надо написать, как это подключить и как в целом погрузиться в тему. Начнём с простых градиентов, а закончим сложным примером «как в Air Drop на iOS 17».

Apple показала Vision Pro – устройство, которое по максимуму использует все наши ощущения и погружает в прямое управление интерфейсом руками, голосом и движением головы.

Вот только не все могут видеть, слышать, двигать руками или говорить. Как будут работать очки для них? Неужели Apple придумала альтернативные способы управления для всего?

Да, придумала. Будущее невероятно.

Первое, что люди спрашивают про доступность: а может ли она принести денег, ведь там немного пользователей? Популярное искажение в том, что они выделяют одну группу (ну сколько там незрячих на миллион?) и не оценивают картину в целом (45% на iOS и 59% на Android включают хотя бы одну настройку доступности).

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

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

Одна из санкций, которая досталась России, — запрет на выдачу и продление SSL-сертификатов. Это приводит к тому, что у некоторых компаний сертификат может протухнуть и сайты перестанут открываться.

Основных решений два:

Использовать российский Яндекс.Браузер или Атом.

Поставить на компьютер сертификат или профиль от минцифры.

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

Например, 15 февраля 2023 года у Сбера истечёт действие сертификата и надо переходить на самоподписанный. Если этого не сделать, то эквайринг через Сбер может перестать работать. SberPay будет работать как и раньше.

В статье покажу, что делать разработчикам приложений, чтобы экраны c 3-D Secure открывались и эквайринг продолжал работу.

3 года назад я загорелся тем, что хочу эргономичную клавиатуру. Готовых вариантов было немного, Keyboard Model 1 оказалась одной из них, но была слишком дорогой. И тут её переиздают на кикстартере, где собирают почти миллион долларов. Страдаю, жду полтора года производства и вот она у меня.

Кофе — продукт, который можно покупать и пить несколько раз в день. Заказ в приложении Дринкит должен быть супер-пупер быстрым. В идеале, чтобы можно было даже не запускать его, а заказывать из виджета на домашнем экране.

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

Часто слышу мнение, что unit-тесты не нужны для мобильной разработки: в приложении должно быть минимум логики, основная работа с UI, а его сложно тестировать, да ещё и тесты отнимают время, которое можно было бы потратить на написание фич. 

За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать. 

Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов. 

Когда-то давно я думал, что вот напишу приложение, выложу, а дальше оно как-нибудь само наберёт популярность, взлетит в чарт, принесёт денег. Так бывает, но готовиться нужно к тому, что придётся заниматься «выводом на рынок и продвижением», и на это потребуются время и силы.

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

Для продвижения нужен хоть какой-то план. О том, что делать в теории, уже написано много раз. Давайте посмотрим, что получилось на практике.

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

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

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

Праздничные дни для Додо Пиццы — настоящий хайлоад. К ним мы готовимся заранее и заводим специальные правила.

Самое жаркое время — в декабре: много корпоративов, заказы становятся больше, прибыль выше. Во многих городах плохая погода — где-то выпал снег и дороги не расчищены, где-то очень холодно. Всё вместе это создаёт нагрузку и на IT, и на бизнес. От нагрузки может сломаться что угодно: то очередь задач переполнится, то печь выйдет из строя. Чтобы быть готовыми, мы регулярно проводим нагрузочные тестирования, повышаем закупки ингредиентов, распределяем заказы по пиццериям и много чего ещё.

Для мобильных разработчиков конец года раньше тоже был особенный: с 23 по 27 декабря App Store закрывался на рождественские праздники, приложения не проверялись, опубликовать что-то было невозможно.

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

Раньше я считал, что написать книгу — это история длиной в жизнь. Год назад я бы рассмеялся, если бы кто-то сказал, что к стольки-то годам напишу книгу на 250 страниц. Но с фактом не поспоришь: вот книга «Про доступность на iOS».

Рассказываю, как случайности и хорошая подготовка нашли друг друга.

Компьютерный стол у меня появился на два года раньше компьютера, в 2004 году. Это был обычный стол, у которого даже были полки для монитора и клавиатуры. За ним я научился всему, а спустя 17 лет он всё так же стоит у моих родителей.

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

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

Уже сто пятьдесят лет никто не решается массово заредизайнить клавуа, у Эпл последняя выглядит вот так. Давайте немного подвигаем кнопки и посмотрим как можно сделать лучше.

Если вы работаете в IT, то о легаси вы слышите часто — обычно с множеством негативных коннотаций. Понятно, что это не «хороший код», но какой? Может старый, может не поддерживаемый или не обновляемый, а может просто чужой? Есть ли «полноценное» определение «легаси», на которое можно ссылаться? А когда разберемся — что нам делать с легаси? Попробуем разобраться.

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

Мы тоже использовали Realm — 3 года подряд. Сначала он помогал, потом раздражал, пару раз выстрелил и в конце чуть не вогнал команду в депрессию. В итоге мы удалили Realm из проекта. Это сложный инструмент — простота интеграции обманчива, а за все удобства придётся расплачиваться.