Многозадачность и управление приоритетами

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

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

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

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

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

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

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

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

Часто вышестоящие менеджеры могут забывать о законе Брукса, стремясь увеличить производительность команд с помощью расширения количественного состава:

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

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

Да и вообще, написание кода - это лишь верхушка айсберга в продуктовой разработке.

😃 iOS Dev

Как работать с шейдерами

Дэн Холлик выпустил новую главу в своей книге Making Software, посвященную шейдерам, фундаментальным принципам и математике.

Хотя напрямую статья не относится к iOS-разработке, но настолько изумительно все описано, что я не могу не поделиться.

Дэн подошёл к теме основательно, и начал аж с того, как работает GPU, описал графический пайплайн (и про vertex shading, про растеризацию и fragment shading) и снабдил все качественными иллюстрациями.

Есть инфа и про апи Microsoft (которая всем нам знакома как DirectX) и их HLSL, но и Apple с Metal не остались в стороне.

📖 Рекомендую сохранить себе статью не только для общего развития, но и чтобы узнать, как в целом создавать крутую графику, зная только x и y-координаты.

Напомню, что в iOS IQ можно посмотреть на большую подборку необычных анимаций (и узнать несколько советов).

🔗 Warp-эффект на metal-шейдере
🔗 Beauty infinite loop
🔗 Огненный шейдер

Код всех реализаций есть 💰 тут и ⭐️ тут, не забывайте про Black Friday.

😃 iOS Dev

Вышло обновление лекций Стэнфорда для iOS-разработчиков

Этот курс - в целом одна из лучших бесплатных точек входа для iOS-разработчиков, и буквально недавно вышло большое обновление из 6 лекций: от основ SwiftUI до демонстрации работы с данными.

📖 Курс целиком доступен здесь (обещают выложить новые лекции в ближайшем будущем).

😃 iOS Dev

Иконка App Store в реальном мире

Безусловно, иконки приложений (или в данном случае целого стора) могут или меняться часто, или оставаться прежними на протяжении долгих лет.

Но вот недавно я увидел обсуждение, в котором разработчики (да и пользователи тоже) на полном серьезе спорили, что из себя представляет современный вариант иконки app store (раньше там было более понятное изображение).

Один из вариантов, который предложил Кристиан (про его историю и инди-разработку я писал когда-то вот тут), заключается в том, что логотип App Store сделан из трёх наклонённых иконок приложений.

И он пошёл дальше, и сделал целую модель (которую вы видите прямо сейчас).

🖨 Кстати, если у вас есть 3D-принтер и вы немного в теме - то вот тут можно распечатать свою собственную фигурку, например для рабочего стола.

😃 iOS Dev

Создание таббара с анимацией в стиле телеграма в iOS 26

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

📺 В этом видео автор поделился способом, как сделать так, чтобы существующий дефолтный таббар содержал анимированные эффекты SF-символов с помощью SwiftUI.

📖 А в этом посте можно посмотреть на большое справочное руководство по использованию SF-символов в целом.

😃 iOS Dev

🏆 iOS Контест от телеги с призовым фондом в $ 50 000

Дедлайн: 23:59 по времени Дубая 26 декабря 2025 года
Кто может участвовать: все желающие

📱 Только вчера показывал один из вариантов реализации анимации в таббаре, а уже сегодня Telegram стартанул конкурс, цель которого — внедрить эффекты Liquid Glass в старые версии iOS.

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

Требования:
– Минимальный таргет iOS 18.
– Никаких сторонних либ.
– Решение должно быть интегрировано в кодовую базу телеги (их наработки можно и нужно использовать).
– Изменения не должны аффектить стабильность и быстродействие (обещают замерять батарейку).

✈️ Детали конкурса - в официальном посте.

Всем участникам удачи!

😃 iOS Dev

Улучшение проверки регистрации в SwiftUI с использованием Key Paths

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

😃 iOS Dev

Одно приложение SwiftUI, шесть архитектур

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

Интересно, что он затрагивает и разницу между архитектурой и дизайн-паттернами, в которой многие путаются до сих пор.

В его примерах можно посмотреть на использование MVC, MVVM, VIPER, TCA и посмотреть на любопытный поинт, что чистая архитектура не что иное, как философия (без отсылок к Роберту Мартину не обошлось).

📖 А какие выводы он сделал - почитайте сами.

P.S. Он не скрывает, что использовал ИИ для помощи (хотя и без подсказок это считывалось), но в любом случае ещё один взгляд на обсуждаемую в программировании тему не будет лишним.

😃 iOS Dev

Какие настройки компилятора важны для Swift Concurrency?

📖 В своей статье Мэтт Массикотт проходится по существующим опциям и описывает рекомендуемые настройки для проектов, использующих Swift 6.

А ещё он пытается ответить на вопросы о том, какие режимы можно просто включить, а о которых можно даже не думать.

😃 iOS Dev

❄️ Снежинки на вашем рабочем столе c помощью Metal

Вышло в релиз приложение Макса Гришутина, в котором можно воссоздать эффект снегопада на вашем маке.

Классно, что есть обработка эффекта таяния снега на границах окон и возможность настройки.

⬇️ Приложение доступно в App Store.

🛠 А так как оно ещё и в опенсорсе, то можно чекнуть исходный код в этом репозитории.

А тут можно посмотреть на эффект гирлянды.

😃 iOS Dev

SwiftUI Animation Playground - интерактивное приложение для изучения анимаций

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

Можно посмотреть сразу 9 типов анимаций: .spring, .smooth, .snappy, .bouncy, .easeIn, .easeOut, .easeInOut, .linear и .interpolatingSpring.

Есть и опции по настройке: duration, bounce, stiffness, damping и другие.

Затестить можно на разных типах фигур (или добавить свои, все же это опенсорс).

🛠 А здесь ссылка на github-репозиторий.

😃 iOS Dev

Актуальный вопрос к читателям

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

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

Но вот какая проблема у меня, моих коллег на протяжении последних года-двух это точно:

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

При этом я не против использования ИИ для написания кода кандидатами - но я прошу понимать написанное.

Какие вы дадите советы, стоит ли с этим бороться вообще? Если стоит, то как именно?

Например, лично я добавляю небольшую 20/30-минутную часть по изменению кода в процессе собеса.

А что ещё посоветуете?

😃 iOS Dev

Парадоксальный способ ускорить SwiftUI Preview

Хранимые свойства - неоптимальный вариант, так как Xcode перекомпилирует файл каждый раз, когда меняется значение.

А вот если менять значения в вычисляемых свойствах, то обновление будет мгновенным.

Аксель Ле Пеннек даже отправил запрос на этот счет в радар, и получил официальное подтверждение Apple на счет предположения.

😃 iOS Dev