👨‍💻 Почему новые фичи убивают приложение на слабых устройствах и как это исправить.

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


Когда улучшения становятся проблемой:

Представьте типичный сценарий: команда внедряет красивую, ресурсоемкую фичу: детализированную 3D-графику, сложную анимацию, работу с большими данными в реальном времени. A/B-тесты показывают, что пользователям нравится. Но параллельно растет метрика аварийных завершений. Причем не равномерно, а взрывно на определенном сегменте устройств.

Анализ показывает, что проблема в Out of Memory (OOM). Приложение перестает помещаться в оперативную память, и система его завершает. Оказывается, для 10% пользовательских сессий (чаще всего на устройствах с 2-3 ГБ ОЗУ) новые фичи становятся неподъемными. Эти 10% сессий генерируют до 90% всех OOM-крашей.


От диагностики к архитектурному решению:


Шаг 1. Поиск точки невозврата:

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

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

Шаг 2. Отказ от универсальности:

Традиционный подход «одно приложение для всех» перестает работать, когда разброс характеристик устройств слишком велик. Устройство с 2 ГБ ОЗУ и устройство с 8 ГБ - это по сути разные вычислительные среды. Невозможно писать код, одинаково эффективный в обоих случаях.

Решение: явное разделение аудитории по классам памяти (RAM-классам). Устройства группируются не по марке или году выпуска, а по реально доступному объему оперативной памяти. Это создает основу для адаптивного поведения.

Шаг 3. Система адаптивной функциональности:

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

🔵Автоопределение: приложение само при старте определяет свой RAM-класс на основе системных API. Никаких опросов пользователей или загрузок конфигов вслепую.

🔵Централизованное управление: набор доступных функций для каждого класса управляется через удаленные конфиги. Это позволяет быстро реагировать на проблемы и гибко тестировать границы.

🔵Честные A/B-тесты: эксперименты с тяжелыми фичами изначально настраиваются так, чтобы не доходить до устройств, которые заведомо не потянут новую функциональность. Это защищает метрики стабильности и не портит опыт слабым устройствам.


Шаг 4. Новые метрики для нового подхода:

С внедрением RAM-классов картина стабильности перестала быть общей. Теперь команда отслеживает ключевые метрики (OOM-краши, потребление памяти, Crash-Free сессии) в разрезе каждого класса. Это позволяет принимать взвешенные решения: «Эта фича добавляет 10% к памяти на классе 3. Готовы ли мы поднять для него минимальные требования?».


🔗 Ссылка на подробную статью


💡 Вывод:

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

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 🪟 Swift на Windows: очередной выход Swift за пределы экосистемы Apple.

Swift больше не довольствуется ролью языка для техники Apple. Создание официальной рабочей группы Windows - это переход от экспериментов к планомерному захвату чужой территории. Теперь у языка есть боевой штаб для системной атаки на крепость Microsoft.


Что было раньше:

До 2026 года Swift на Windows существовал в режиме «кто во что горазд». Компилятор работал, но ключевые библиотеки (Foundation, Dispatch) были нестабильны. Сборка и дистрибуция приложений превращались в квест.


Что изменилось сейчас:

Создана официальная структура с конкретными целями:

🔵Стабильные сборки: обеспечить рабочий дистрибутив Swift для Windows.

🔵Адаптация ядра: заставить Foundation и Dispatch работать по-человечески на Windows.

🔵Стратегия: определить, как Swift будет развиваться на этой платформе.

🔵Интеграция: найти способы связать Swift с Win32 API и COM.


Почему это важно:

🔵Для iOS-разработчиков: появится возможность писать нативные инструменты и утилиты для Windows, не переучиваясь на C#.

🔵Для компаний: Swift сможет претендовать на проекты в корпоративной среде, где доминирует Windows.

🔵Для языка: это шаг к статусу по-настоящему кроссплатформенного языка, а не нишевого решения для Apple.


Главный вызов:

Проблема не в компиляции, а в экосистеме. Swift должен научиться жить в мире WinAPI, COM-объектов и .NET. Нужны мосты, аналогичные JNI для Android, но для Windows.


🔗 Ссылка на пост в блоге


💡 Вывод:

Создание рабочей группы - это не про улучшение сборок. Это декларация войны с C# и C++ на их собственном поле. Swift перестает быть гостем на Windows и начинает борьбу за место под солнцем. Успех этой операции покажет, сможет ли язык от Apple стать реальной силой в мире разработки под Windows или останется экзотическим выбором для Windows-энтузиастов.


➡️ Подписаться на канал
Мобильный трудоголик

💻 VS Code для iOS-разработки: добавляем просмотр .xcassets как в Xcode.

Тренд на миграцию iOS-разработчиков с Xcode на VS Code или Cursor набирает обороты. Однако переход часто упирается в потерю специфичных инструментов Apple-экосистемы. Один из самых болезненных моментов - работа с Asset Catalogs (.xcassets). В Xcode это интуитивный визуальный редактор, в VS Code - папка с JSON-файлами. Разработчики из сообщества решили проблему, создав расширение, которое буквально переносит знакомый интерфейс Xcode в новый редактор.


Суть проблемы - JSON вместо интерфейса:

Файл .xcassets - это не просто папка с картинками. Это структурированный каталог, содержащий:

🔵Наборы изображений (Image Sets) для разных разрешений и устройств.

🔵Цветовые палитры (Color Sets) с поддержкой тем и контрастности.

🔵Иконки приложений (App Icon Sets).

🔵Данные (Data Sets).

🔵Анимации Lottie.

В Xcode разработчик видит удобное древовидное представление с превью. В голом VS Code - только сырые Contents.json файлы и изображения, что делает навигацию и проверку мучительно медленной.


Решение- Asset Catalog Viewer:

Расширение полностью копирует трехпанельную логику интерфейса Xcode:

🔵Левая панель: иерархическое дерево ассетов с папками и миниатюрами.

🔵Центральная панель: детальное превью выбранного ассета со всеми его вариантами (разрешения, темы, устройства).

🔵Правая панель: инспектор свойств - показывает метаданные, цветовые пространства, размеры файлов.


Установка:

Расширение устанавливается стандартно через каталог расширений VS Code или Cursor. После установки оно добавляет в контекстное меню (по правому клику на папке .xcassets) пункт «Open Asset Catalog Viewer». Также можно открыть каталог через Command Palette. Расширение работает локально, не требуя отправки данных.


🔗 Ссылка на расширение


💡 Вывод:

Пока Apple сохраняет Xcode как единственную официальную, но тяжелую и не всегда стабильную IDE, сообщество берет инициативу в свои руки, выборочно перенося лучшие ее части в более современные и гибкие редакторы: VS Code и Cursor.

Этот тренд важен: он дает разработчикам реальный выбор. Больше не нужно мириться со всеми недостатками Xcode ради работы с ассетами или, наоборот, отказываться от удобства ради скорости и стабильности VS Code. Теперь можно собрать идеальный стек инструментов под свои задачи. Asset Catalog Viewer - это убедительный аргумент в пользу того, что будущее iOS-разработки может быть не за монолитной IDE, а за модульной средой, где каждую функцию можно выбрать и улучшить независимо.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 UIKit встречает Liquid Glass: как адаптировать гибридное приложение к iOS 26.

С выходом iOS 26 и нового дизайна Liquid Glass многие команды столкнулись с неочевидными вызовами. Особенно сложная ситуация складывается у проектов с гибридной архитектурой, где UIKit и SwiftUI соседствуют годами. Адаптация - это не просто замена цветов и добавление размытий. Это переосмысление навигации, модальностей и даже базовых компонентов интерфейса. На примере приложения Grow, получившего признание редакции App Store в 173 странах, разберем, какие решения работают на практике, а какие оказываются тупиковыми.


Двойная стратегия - совместимость и прогрессивность:

Первое и главное правило успешной адаптации - сохранение работоспособности для пользователей старых версий iOS. В Grow выбрали стратегию условной компиляции и проверки доступности API через #available(iOS 26.0, *). Это позволяет:

🔵Оставлять проверенные интерфейсы для iOS 18 и ниже.

🔵Предлагать новый визуальный опыт пользователям iOS 26.

🔵Постепенно мигрировать компоненты не поломав существующую логику.


Навигация - от кастомных решений к нативным компонентам:

Исторически сложилось, что многие проекты заменяли UINavigationBar кастомными view для сложных UI-элементов. Liquid Glass требует обратного подхода - возврата к нативным компонентам. В Grow провели рефакторинг:

🔵Заменили кастомные панели навигации на UINavigationController.

🔵Настроили navigationItem для размещения элементов управления.

🔵Использовали Auto Layout для правильного позиционирования scroll-контейнеров.

Ключевой момент: нативные компоненты лучше адаптируются к системным эффектам морфинга и анимациям Liquid Glass.


Модальные представления:

Адаптация UISheetPresentationController оказалась одной из самых простых задач. Для активации эффектов Liquid Glass достаточно:

🔵Убрать кастомные фоновые view.

🔵Использовать системные API для управления размытием краев.

🔵Настраивать ToolbarItem для контроля Scroll Edge Effect.

Более интересной задачей стала реализация морфинг-меню в формате popover. Вместо чисто SwiftUI-решений команда выбрала гибридный подход через UIPopoverPresentationController:

🔵SwiftUI-view упаковывается в UIHostingController.

🔵Контроллер привязывается к UIBarButtonItem через popoverPresentationController?.sourceItem.

🔵Делегат UIPopoverPresentationControllerDelegate решает проблемы приоритета жестов и предварительной настройки контента.


Расширение возможностей - стеклянный текст:

Один из наиболее креативных аспектов адаптации - создание кастомных стеклянных эффектов. Используя Core Text, можно преобразовывать глифы шрифтов в CGPath, а затем применять к ним эффект glassEffect(_:in:). Это открывает возможности для:

🔵Текстовых элементов с эффектом жидкого стекла.

🔵Произвольных форм, выходящих за рамки геометрических примитивов.

🔵Динамических эффектов, зависящих от контента.


🔗 Ссылка на подробную статью


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔨 Xcode 26.3: добавлена поддержка Claude, Codex и MCP агентов.

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


Новая парадигма - от инструкций к целям:

Раньше работа с ИИ напоминала разговор с очень умным, но слепым помощником: «напиши функцию для парсинга JSON», «создай вью с такими-то свойствами». В Xcode 26.3 подход меняется. Вы формулируете цель: «Добавь в приложение прогноз погоды на семь дней с использованием WeatherKit и стилем Liquid Glass».

Система, используя интеграцию с Claude Agent SDK и другими движками через Model Context Protocol (MCP), берет на себя всю остальную работу:

🔵Анализ проекта: агент изучает структуру файлов, существующие модули и зависимости.

🔵Планирование: определяет, какие файлы нужно создать или изменить, какие права добавить, какую архитектуру использовать.

🔵Исполнение: пишет код, добавляет ресурсы, настраивает проект.

🔵Верификация и итерация: запускает сборку, анализирует ошибки компиляции, использует Xcode Previews для визуальной проверки интерфейса и вносит правки, пока результат не будет соответствовать задаче.


Ключевое отличие - закрытие цикла обратной связи:

Самая мощная часть новой системы - способность агента видеть результат своей работы. Через интеграцию с Xcode Previews агент может сделать скриншот собираемого интерфейса, проанализировать его и понять: «Текст не помещается», «Отступы не соответствуют макету», «Цвета выглядят не так». Это позволяет ему самостоятельно итерироваться, не требуя постоянного вмешательства разработчика.


Что это меняет для разработчика:

🔵Роль смещается. Теперь разработчик формулирует задачи на естественном языке, а не пишет каждую строчку. Основное время уходит на проектирование фич, их постановку для агента и ревью результата. Фокус на архитектуре и видении продукта.

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

🔵Агенты помогают с легаси-кодом. Они могут анализировать устаревшие модули, предлагать план рефакторинга и даже генерировать часть миграционного кода.

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


🔗 Ссылка на подробную статью


💡 Вывод:


Выход Xcode 26.3 - это не просто обновление с новыми ИИ-фичами. Это фундаментальное изменение архитектуры самой IDE. Apple превращает Xcode из инструмента для написания кода в платформу для оркестрации автономных агентов, которые понимают структуру проекта, умеют его собирать и даже визуально проверять результат через Previews.

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

Это задает вектор развития инструментов для разработки на следующие годы. Теперь преимущество будет не у того, кто лучше пишет код, а у того, чья IDE эффективнее управляет агентами.


➡️ Подписаться на канал
Мобильный трудоголик

🔨 Universal Links: что скрыто за простым AASA-файлом.

Universal Links в iOS кажутся простой технологией: добавил AASA-файл на сервер, прописал домен в entitlements и глубокие ссылки работают. Эта иллюзия разбивается о реальность масштабных проектов, где десятки доменов, локализации и регулярные обновления превращают поддержку Universal Links в сложную инженерную задачу. Проблема не в том, чтобы «завести» ссылки, а в том, чтобы они стабильно работали для миллионов пользователей после каждого обновления.

Когда пользователь кликает на Universal Link, iOS проверяет не ваш сервер напрямую. Система обращается к CDN Apple (app-site-association.cdn-apple.com), где кешируются AASA-файлы со всего мира. Ваш файл на сервере - лишь источник для этого кеша. Обновление в CDN происходит с задержкой до нескольких часов, и пока изменения не распространятся, часть пользователей будет видеть старую конфигурацию.


Критическая проблема - неявные ошибки конфигурации:

AASA-файл - это JSON, но не любой JSON подойдет. Большинство валидаторов проверяют только базовый синтаксис и доступность файла. Однако файл может быть технически валидным JSON, но содержать логические ошибки:

🔵Неправильные wildcard-паттерны (*, ?, ?*).

🔵Ошибки в substitution variables для локализаций.

🔵Конфликтующие правила исключений (exclude).

🔵Некорректные пути для query-параметров или фрагментов.

iOS не сообщает об этих ошибках. Ссылки просто перестают открываться в приложении, падая в Safari.


Стратегия надежного деплоя - четыре уровня защиты:

🔵Валидация схемы (JSON Schema) в CI. Прежде чем файл попадет на сервер, автоматика проверяет его структуру. Это отлавливает опечатки в названиях полей, неправильные типы данных, отсутствие обязательных секций. Схема описывает не только applinks, но и опциональные разделы вроде webcredentials.

🔵Сравнение с CDN Apple. После деплоя скрипт сравнивает файл на вашем сервере с тем, что вернул CDN Apple. Расхождения означают, что обновление еще не применилось. Эта проверка должна быть частью мониторинга.

🔵Регрессионное тестирование ссылок. Для каждого домена ведется файл-конфигурации, который нужно тщательно тестировать.

🔵Стендинг-окружение с реальными доменами. Тестировать на локальном localhost или симуляторе недостаточно. Нужны настоящие домены с HTTPS, зеркалирующие прод. В debug-сборках приложения указываются эти тестовые домены, что позволяет проверять изменения без риска для пользователей.


Wildcard-паттерны - собственная математика Apple:

Синтаксис *, ? и ?* в AASA - это не стандартные regex. Нужно понимать их преобразование:

* -> .* (ноль или больше символов)

? -> . (ровно один символ)

?* -> .+ (один или больше символов)

Самый сложный случай - substitution variables для локализаций:

"substitutionVariables": {
  "menu": ["speisekarte", "menu", "carte"]
}

Паттерн /$(lang)/$(menu)/* должен корректно матчиться на /de/speisekarte/restaurant и /en/menu/restaurant. Реализация собственного парсера, который раскрывает переменные и преобразует паттерны - необходимость для нетривиальных проектов.


Особые случаи поведения iOS:

🔵Первая установка: если пользователь установил приложение по Universal Link, данные о ссылке могут не передаться в первый запуск.

🔵Холодный vs теплый запуск: поведение может отличаться в зависимости от того, было ли приложение в памяти.

🔵Developer Mode: для отладки можно добавить ?mode=developer к домену в entitlements, чтобы iOS брала файл напрямую с сервера, минуя CDN.


🔗 Ссылка на подробную статью


💡 Вывод:

Работа с Universal Links в крупном проекте - это не про добавление файла на сервер, а про построение полного жизненного цикла конфигурации. От валидации схемы и тестирования паттернов до мониторинга расхождений с CDN Apple.

Проблемы Universal Links редко проявляются сразу. Они накапливаются. Единственный способ избежать этого - относиться к AASA не как к статическому файлу, а как к критическому компоненту инфраструктуры со своим пайплайном деплоя, тестирования и мониторинга.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Новый стандарт Apple: async/await вместо Combine.

В файле репозитория, который содержит системные подсказки и документацию из Xcode 26.3 явно указано: «Избегайте использования фреймворка Combine, вместо этого предпочтительнее использовать async/await версии API». Это заметил Артем Новичков и сообщил в своем посте.

Это не приговор, а четкий сигнал от Apple о приоритетах для нового кода. Combine - зрелый и мощный фреймворк, но для большинства современных задач (сетевые запросы, работа с файлами, обновленные системные API) async/await предлагает более простую, читаемую и интегрированную в язык модель.


Что это означает:

🔵Новые проекты: логично стартовать с async/await как основного инструмента для асинхронности.

🔵Существующие проекты на Combine: не нужно срочно все переписывать. Combine остается отличным выбором для сложной реактивной логики UI или работы с легаси.

🔵Общая тенденция: Apple планомерно обновляет свои API, добавляя async/await альтернативы. Со временем это станет стандартом де-факто для новых разработок.


💡 Вывод:

Combine остается рабочим инструментом, но для всех новых разработок без сомнений выбирайте async/await - это официальный вектор развития от Apple.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Обратная миграция: почему крупные проекты смотрят в сторону UIKit.

Последние несколько лет SwiftUI позиционировался как будущее разработки под Apple-экосистему. Однако в 2024-2025 годах наметился парадоксальный тренд: все больше разработчиков и компаний сознательно возвращаются к классическому стеку - UIKit. Это не просто ностальгия по старым методам, а стратегическое переосмысление выбора инструментов в новых условиях.


Смена приоритетов - от скорости написания к скорости чтения и контролю:

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

Однако с повсеместным внедрением ИИ-инструментов (Copilot, Cursor, Claude Code) парадигма сместилась. Писать код становится проще, а читать и поддерживать - сложнее. И здесь UIKit с его императивным, явным стилем выигрывает.

🔵Прямолинейность UIKit: архитектура MVC/MVVM задает четкую структуру. Вы точно знаете, где искать логику жестов (UIGestureRecognizer во viewDidLoad), где обновляется layout (viewDidLayoutSubviews), и как данные попадают в представление. Это предсказуемо и легко читается как человеком, так и ИИ-ассистентом.

🔵Магия SwiftUI: мощные property wrappers (@State, @Binding, @EnvironmentObject) и модификаторы создают сложные, неочевидные связи данных. Чтобы понять поток информации в нетривиальном экране, часто приходится «разматывать» цепочки зависимостей, что замедляет ревью и рефакторинг.


Архитектура как скелет приложения:

SwiftUI поощряет минималистичные архитектуры вроде Model-View (MV), где бизнес-логика, состояние и представление часто перемешаны в одном файле. Это отлично для простых экранов, но превращается в кошмар для сложных, долгоживущих проектов.

UIKit, со своей «многословной» архитектурой, вынуждает к дисциплине. Разделение ответственности между ViewController, Model и Router/Coordinator создает каркас, который:

🔵Масштабируется. Новые разработчики быстрее входят в проект, понимая стандартные места для разных типов кода.

🔵Облегчает работу ИИ. Четкий запрос вроде «добавь обработку свайпа в делегат коллекции в CollectionViewController» дает более точный и интегрируемый результат.

🔵Дает полный контроль. Прямой доступ к жизненному циклу view (viewWillAppear, viewDidDisappear), нативным делегатам (UIScrollViewDelegate, UICollectionViewDelegate) и методам анимации (UIView.animate) остается незаменимым для создания сложных взаимодействий.


🔗 Ссылка на подробную статью


💡 Вывод:

Выбор между UIKit и SwiftUI больше не является линейным путем «от старого к новому». Это стратегическое решение, основанное на контексте проекта:

🔵Выбирайте SwiftUI, если: вы создаете MVP, простые кроссплатформенные приложения (с SwiftUI на macOS/watchOS) или внутренние инструменты, где скорость создания важнее тонкой настройки и долгосрочной поддержки.

🔵Выбирайте UIKit, если: вы строите большое, сложное приложение с требованием к нативной производительности, кастомными, сложными взаимодействиями, долгим циклом жизни и командой, где читаемость и поддерживаемость кода - приоритет.

SwiftUI не умирает, он находит свою нишу. Но ренессанс UIKit доказывает, что проверенные, явные и контролируемые технологии часто побеждают в долгосрочной перспективе, особенно когда на сцену выходят инструменты, меняющие саму природу программирования с «написания» на «чтение и композицию».


➡️ Подписаться на канал
Мобильный трудоголик

🔢 От хаоса к порядку: Swift делает поведение nonisolated функций предсказуемым.

Swift Concurrency продолжает эволюционировать, и одно из ключевых изменений - пересмотр логики работы nonisolated асинхронных функций. Сейчас они ведут себя противоречиво: синхронные nonisolated методы выполняются в контексте вызывающей стороны (например на акторе), а асинхронные - всегда переключаются на внешний executor, что вызывает неожиданные ошибки типов и усложняет архитектуру.


Суть проблемы - разрыв между ожиданием и реальностью:

Когда вы вызываете nonisolated асинхронный метод из актора, компилятор вынужден применять строгие Sendable-проверки ко всем аргументам, даже если метод по своей природе не должен покидать контекст актора. Это приводит к ложным ошибкам, особенно в библиотечном коде, где автор API может не предусмотреть такой сценарий. Даже стандартная библиотека Swift Concurrency сталкивалась с этой проблемой.


Решение - явное управление изоляцией через новые модификаторы:

Предложение SE-0461 вводит два новых инструмента для точного контроля:

🔵nonisolated(nonsending) - явно указывает, что асинхронная функция должна выполняться в контексте вызывающего актора (унаследовать его изоляцию). Это поведение становится предсказуемым и аналогичным синхронным функциям.

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

class NotSendable {
  nonisolated(nonsending)
  func performAsync() async {
    // Работает в контексте вызывающего актора
  }
}

actor MyActor {
  let item = NotSendable()
  
  func call() async {
    item.performSync() // OK
    await item.performAsync() // Теперь тоже OK, ошибки типов нет!
  }
}

Макрос #isolation и работа с замыканиями:

Для продвинутых сценариев, таких как создание оберток (например withResource), расширяется функциональность макроса #isolation. Теперь он может корректно передавать контекст изоляции в nonisolated(nonsending) функции, что делает написание высокоуровневых асинхронных API значительно проще и безопаснее.

Важное уточнение: неструктурированные задачи (Task { }), созданные внутри таких функций, по-прежнему не наследуют изоляцию, что соответствует принципам предсказуемости.


Практический смысл - баланс между безопасностью и удобством:

Это изменение - не просто синтаксический сахар. Оно решает фундаментальную проблему: делает поведение nonisolated функций последовательным и интуитивно понятным. Разработчики получают явный контроль:

🔵Хотите, чтобы функция работала в том же контексте и не требовала Sendable? Используйте nonisolated(nonsending).

🔵Нужно гарантированно переключиться для параллельной работы? Явно укажите @concurrent.


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Swift: профессиональные методы отладки сложного кода.

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


Трюк с контекстом - почему ваши логи должны быть умнее print:

Стандартный print оставляет вас в неведении: где именно сработал этот вывод? Вместо этого используйте встроенные литералы компилятора для автоматического контекста:

func debugLog(
  _ message: String, 
  file: String = #file, 
  function: String = #function, 
  line: Int = #line
) {
  let fileName = URL(fileURLWithPath: file).lastPathComponent
  print("[\(fileName):\(line)] \(function) — \(message)")
}

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


Зеркало в runtime - когда нужно увидеть то, что скрыто:

Swift - статически типизированный язык, но это не значит, что мы не можем исследовать объекты в рантайме. Mirror - ваш портал для интроспекции. Допустим, у вас сложная ViewModel с десятком @Published свойств, и вы не понимаете, какое именно вызывает неожиданное обновление UI:

func inspectObject(_ object: Any) {
  let mirror = Mirror(reflecting: object)
  for child in mirror.children {
    print("\(child.label ?? "Unknown"): \(type(of: child.value)) = \(child.value)")
  }
}

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


dump() против print - анатомия сложных структур:

Когда print выдает что-то вроде User(address: __lldb_expr_123.Address(street: "...", ...)), пора переходить к dump(). Эта функция рекурсивно обходит всю структуру объекта, показывая его реальное дерево:

struct Project {
  let title: String
  let contributors: [Developer]
  let settings: Configuration
}

let activeProject = fetchCurrentProject()
dump(activeProject) // Полное дерево со всеми вложенными объектами

Вы увидите не просто «есть массив разработчиков», а каждого разработчика со всеми его полями, и каждое поле конфигурации. Это спасение при работе с Core Data (исследование графа объектов), сложными JSON-ответами API или глубокими иерархиями UIView.


CustomDebugStringConvertible - создание отладочной документации:

Реализация CustomDebugStringConvertible - это не про красивый вывод. Это про создание специализированного отладочного представления для ваших типов, которое показывает именно ту информацию, которая важна для диагностики:

class NetworkRequest: CustomDebugStringConvertible {
  let id: UUID
  let endpoint: URL
  var state: State
  var metrics: [Metric]
  
  var debugDescription: String {
    """
    Request \(id.uuidString.prefix(8))... 
    to \(endpoint.path) 
    is \(state.rawValue)
    last metric: \(metrics.last?.description ?? "none")
    """
  }
}

Теперь, логгируя или используя po в LLDB, вы мгновенно видите статус запроса, а не просто его адрес в памяти. Это особенно эффективно для массивов или словарей таких объектов.


🔗 Ссылка на подробную статью


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Тихий режим для push-уведомлений: обход системных ограничений iOS.

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


Архитектурная головоломка и ее решение:

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

Ключ к решению - App Groups. Это технология, позволяющая выделить область общей памяти, доступную для нескольких компонентов одного приложения (основной таргет и экстеншены). Настройка происходит через добавление кастомной capability в оба таргета и использование идентичного suiteName для инициализации UserDefaults(suiteName:).


Сердце системы - Notification Service Extension:

Этот extension - единственная точка в системе iOS, где можно программно модифицировать контент удаленного уведомления до его показа пользователю. Он активируется системой при получении пуша, имеет строго ограниченное время на выполнение (порядка 30 секунд) и должен вызвать contentHandler. Логика работы экстеншена:

🔵Получить входящий контент (UNNotificationRequest).

🔵Проверить в общих UserDefaults (через App Group), активен ли звук в настройках приложения.

🔵Если звук отключен - удалить свойство .sound из UNMutableNotificationContent.

🔵Передать модифицированный контент в contentHandler.

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


Синхронизация состояния - менеджер настроек:

В основном приложении необходим менеджер, который будет записывать значение настройки звука одновременно в стандартные UserDefaults (для быстрого доступа в самом приложении) и в общие UserDefaults App Group (для доступа extension). Это гарантирует консистентность данных независимо от того, запущено ли основное приложение в момент прихода пуша.


Обработка в foreground - делегат центра уведомлений:

Extension работает только для уведомлений, пришедших, когда приложение в фоне или заблокировано. Для случая, когда приложение активно, модификацию необходимо проводить в методе userNotificationCenter(_:willPresent:withCompletionHandler:). Здесь, основываясь на тех же настройках, мы определяем, передавать ли в completionHandler опцию .sound.


Критически важные детали реализации:

🔵Членство в таргетах (Target Membership): файлы, которые должны быть доступны и основному приложению, и extension (например кастомный звуковой файл или GoogleService-Info.plist для Firebase), должны быть отмечены галочками в обоих таргетах.

🔵Точность идентификатора App Group: строка-идентификатор в .entitlements файлах должна быть абсолютно идентичной в основном таргете и в таргете extension. Чувствительна к регистру.

🔵Ограничение времени: код в didReceive extension должен быть максимально эффективным. Если обработка не успевает, система вызовет serviceExtensionTimeWillExpire, где нужно отдать хотя бы исходный контент.


🔗 Ссылка на подробную статью


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Как работает UUID() в Swift и почему он никогда не повторяется.

Когда вы пишете let id = UUID(), кажется, что это просто генерация случайного набора символов. На деле Swift запускает целый конвейер: собирает случайные данные из множества аппаратных датчиков: от колебаний напряжения в процессоре до микрозадержек при доступе к памяти, превращает их в непредсказуемые числа через сложные криптоалгоритмы и упаковывает результат в формат по международному стандарту. И все это происходит быстрее, чем вы успеваете моргнуть.


Три стратегии, одна цель:

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

🔵Версия 1 (таймстемп + MAC). Самый старый подход. Берет текущее время с точностью до 100 наносекунд, добавляет MAC-адрес сетевой карты и номер такта на случай отката времени. Гарантия уникальности абсолютная, но есть нюанс: MAC-адрес светит железо, на котором сгенерирован UUID. Для распределенных систем это допустимо, для пользовательских приложений - потенциальная угроза приватности.

🔵Версия 4 (полностью случайная). Это то, что делает стандартный UUID() в Swift. Никакого времени, никакого железа - только 122 бита криптостойкой случайности. Шесть бит зарезервировано под версию и вариант, остальное - энтропия. Вероятность коллизии настолько мала, что ее можно игнорировать даже при генерации миллиардов идентификаторов в секунду.

🔵Версия 7 (время + случайность). Новейший стандарт, который пока не встроен в Swift напрямую, но уже активно обсуждается. Берет миллисекундный timestamp и добивает случайными битами. Главное преимущество - монотонность: такие UUID можно сортировать по времени создания, что критично для баз данных и событийных логов.


Откуда берется «достаточно случайно»:

Случайность бывает разная. arc4random() - быстрая, но предсказуемая, если знать состояние генератора. UUID требует другого уровня - CSPRNG (Cryptographically Secure PseudoRandom Number Generator). В Apple-экосистеме за это отвечает Security.framework, который собирает энтропию буквально из всего:

🔵Квантовый шум транзисторов CPU (тепловые флуктуации электронов).

🔵Джиттер тактовых частот между ядрами.

🔵Вариации времени доступа к RAM и кешу.

🔵Тайминги нажатий на экран (для iOS) или движений мыши (для macOS).

🔵Шум сенсоров (акселерометр, гироскоп, тепловые датчики).

🔵Сетевые пакеты и их интервалы.

Все это смешивается в системном пуле энтропии, через который прогоняется криптопримитив (например, ChaCha20 или Fortuna), и только потом отдается в UUID().


Почему это не тормозит:

Несмотря на сложность, генерация UUID в Swift - одна из самых быстрых операций. На современном железе: 2-5 миллионов идентификаторов в секунду. Секрет в том, что пул энтропии поддерживается постоянно, а CSPRNG просто выдает из него уже готовые случайные байты. Тяжелая работа (сбор физического шума) происходит в фоне, а ваш UUID() забирает готовый результат.


🔗 Ссылка на подробную статью


💡 Вывод:

UUID в Swift - это не просто рандомайзер. Это прослойка между вашим кодом и физическими процессами внутри чипа, которые фундаментально непредсказуемы. Каждый вызов UUID() - маленькое чудо инженерной мысли, где квантовая механика встречается с RFC-стандартами, а результат умещается в 36 символов. Шанс, что два UUID совпадут, настолько мал, что вы скорее встретите медведя в метро, чем поймаете коллизию.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 SwiftUI: разница между some View и AnyView о которой важно знать.

В SwiftUI постоянно встречаются два похожих, но работающих по-разному подхода: some View и AnyView. Для новичка разница незаметна: и там и там возвращается View. Но для SwiftUI это две совершенно разные истории, которые влияют на то, как фреймворк будет обновлять интерфейс и потреблять ресурсы.


Что скрывается за some View:

Когда вы объявляете var body: some View, происходит нечто похожее на контракт с компилятором. Вы обещаете, что свойство будет возвращать значение конкретного типа, соответствующего протоколу View, но сам тип остается неназванным. Компилятор это устраивает, он самостоятельно определит тип на основе того, что вы написали внутри.

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


Как работает AnyView:

AnyView работает иначе. Он стирает тип и оставляет от конкретной вьюхи только факт, что она соответствует протоколу View. Для SwiftUI это означает потерю информации: он больше не знает, что внутри: текст, изображение или целый стек. Все, что остается - черный ящик.

Типичная ситуация, когда хочется использовать AnyView: возврат разных типов в зависимости от условия:

func content(isLoggedIn: Bool) -> some View {
  if isLoggedIn {
    return HomeView()
  } else {
    return LoginView()
  }
}

Компилятору это не понравится: типы разные, а some View требует один конкретный. Самый простой, но неправильный способ починить: обернуть оба варианта в AnyView. Код скомпилируется, но SwiftUI потеряет информацию о структуре и не сможет нормально оптимизировать обновления.


Правильный подход - ViewBuilder:

Вместо ручного возврата и стирания типов SwiftUI предлагает использовать @ViewBuilder. Этот атрибут превращает набор View в единое выражение с типом ConditionalContent:

@ViewBuilder
func content(isLoggedIn: Bool) -> some View {
  if isLoggedIn {
    HomeView()
  } else {
    LoginView()
  }
}

Тип остается конкретным и известным компилятору, просто он умеет описывать условную структуру. Все преимущества оптимизации сохраняются.


Когда AnyView все-таки нужен:

Есть ситуации, где без стирания типа не обойтись:

🔵Массив вьюх разного типа.

🔵Инъекция вьюхи во время выполнения, когда тип заранее неизвестен.

🔵API, где нельзя использовать дженерики.

Например, список разнородных ячеек, которые приходят из конфигурации:

let cells: [AnyView] = [
  AnyView(ProfileCell()),
  AnyView(SettingsCell()),
  AnyView(NotificationCell())
]

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


Простое правило:

Если SwiftUI может узнать тип на этапе компиляции - используйте some View. Если тип становится известен только во время выполнения - используйте AnyView.

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


🔗 Ссылка на подробную статью


💡 Вывод:

Разница между some View и AnyView - это разница между статической типизацией с возможностью оптимизации и динамической диспетчеризацией с потерей производительности. SwiftUI спроектирован так, чтобы максимально использовать информацию о типах на этапе компиляции. Любое стирание типов заставляет фреймворк работать вслепую, что рано или поздно скажется на плавности интерфейса. Хорошая привычка - всегда сначала пробовать some View и только в крайнем случае опускаться до AnyView, четко понимая цену такого решения.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Почему .xcstrings ведет себя в Swift Packages не так, как в основном приложении.

Формат .xcstrings вышел достаточно давно, но его поведение в Swift Packages до сих пор удивляет даже опытных разработчиков. В основном приложении все просто: добавил файл, вызвал String(localized:) и строка подхватилась. В пакете та же схема может не сработать. Строки возвращают ключи вместо перевода, вообще ничего не возвращают или требуют писать bundle: .module в каждом вызове. А если вы рассчитывали на автогенерацию статических переменных, то ее просто нет.


Что такое .xcstrings и при чем тут версии iOS:

.xcstrings - это формат файлов локализации, который пришел на смену старым .strings и .stringsdict. Один файл вместо десятка, визуальный редактор, поддержка плюральных форм. Формат появился в Xcode 15 и не привязан к версии iOS - его можно использовать в проектах, которые работают на iOS 13 и выше.

Но когда этот файл попадает в Swift Package, могут возникнуть проблемы.


Первая проблема - поиск бандла:

В основном приложении String(localized:) автоматически находит нужные ресурсы. В пакете - нет. Там файлы локализации лежат в бандле самого пакета, и системе нужно явно сказать, где искать. Самый распространённый способ - писать String(localized: "key", bundle: .module). Это работает, но раздражает, когда локализации много.

Если поднять минимальную версию iOS в пакете до 16, проблема уходит. Начиная с iOS 16 String(localized:) в пакетах по умолчанию смотрит в правильный бандл. Без лишних параметров.


Вторая особенность - автогенерация статических ключей:

Xcode умеет создавать статические переменные для всех ключей локализации. Вместо "profile_title" вы пишете LocalizedStringResource.profileTitle. Удобно, безопасно, с автодополнением.

Но эта фича завязана на версию iOS. Если минимальная версия пакета - iOS 15 или ниже, Xcode просто не предложит сгенерировать статические ключи. Они становятся доступны только при iOS 16 или новее.


💡 Вывод:

Работа с .xcstrings в Swift Packages накладывает определенные ограничения, которые важно учитывать при выборе минимальной поддерживаемой версии iOS. Начиная с iOS 16 локализация работает предсказуемо и удобно: статические ключи генерируются автоматически, а бандл подхватывается без лишних указаний. На более старых версиях требуются дополнительные действия: ручное добавление bundle: .module и самостоятельное создание ключей. Это не делает локализацию невозможной, но добавляет рутины и повышает риск ошибок. Выбор версии определяет не столько саму возможность использовать .xcstrings, сколько уровень комфорта при работе с ними.


➡️ Подписаться на канал
Мобильный трудоголик

Привет, друзья! Хочу посоветовать классный канал про мобильную разработку (Android/iOS): @dolgo_polo_dev

Вот несколько интересных постов, которые стоит изучить:

🌐 Как сделать свою систему рекомендаций как у ТикТока — короткий гайд

🧬Насколько отличается производительность самого слабого смартфона от флагмана?

🎃🤖 Android AppLink / iOS Universal Link

📱 PWA на iOS: почему веб-приложения на iPhone до сих пор чувствуют себя чужими.

Когда речь заходит о Progressive Web Apps, заказчики часто рисуют красивую картину: один код, все платформы, никаких магазинов приложений. Но как только дело доходит до реального запуска на iOS, эта картина начинает трещать по швам. Не потому что технология плохая, а потому что платформа, на которой она работает, просто не заинтересована в вашем успехе.


Главный фильтр - как PWA попадает на iPhone:

В 2026 году большинство пользователей iOS за пределами Евросоюза по-прежнему живут в мире, где Safari - единственный браузер с полным доступом к системным API. Формально Apple разрешает устанавливать PWA на домашний экран. Неформально - делает все, чтобы пользователь об этом забыл.

Никакого нативного баннера с кнопкой «Установить». Вместо этого - стрелочка в меню «Поделиться» и надежда, что пользователь догадается. Конверсия в установку на iOS ниже в разы просто потому, что процесс спрятан глубже, чем хотелось бы.


Семь дней тишины - как iOS стирает ваши данные:

Самая неприятная особенность Safari - Intelligent Tracking Prevention. Она задумывалась как защита приватности, но для PWA работает как медленный убийца. Если пользователь не заходил на ваш сайт семь дней, браузер может просто удалить все данные: localStorage, IndexedDB, кэш сервис-воркера.

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


Пуш-уведомления - работают, но с условием:

Web Push на iOS наконец-то стабилизировался. Но есть нюанс: подписка работает только если PWA уже добавлено на домашний экран. Пользователь просто зашел на сайт в Safari - пуши не получит, даже если согласился.

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


Глубокие ссылки - бесшовность только на словах:

Ссылки, ведущие в PWA - тема отдельной боли. Формально механизм работает: можно настроить ассоциацию домена через файл на сервере, и установленное PWA будет открывать ссылки из почты или мессенджеров.

Но на практике iOS часто упрямо открывает Safari, показывая сверху маленькую плашку «Открыть в приложении». Пользователь должен заметить ее и нажать. Никакого автоматического редиректа, как на Android. Это не баг, это сознательное решение Apple сделать опыт чуть менее удобным.


Когда PWA все-таки можно использовать:

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

🔵Внутренние инструменты компании. Обновления без App Store, доступ с любого устройства.

🔵Ивент-приложения. Живут неделю, не требуют установки через магазин.

🔵Сервисы с редким использованием. Раз в месяц оплатить счет - не повод качать сотни мегабайт.


Когда PWA превращается в проблему:

🔵Фоновая геолокация. Как только экран гаснет, доступ к координатам теряется.

🔵Сложная работа с камерой. WebRTC в Safari греется и вылетает.

🔵Биометрия. WebAuthn работает, но выглядит как попап на сайте, а не нативный диалог FaceID.

🔵Офлайн с большими данными. Риск, что iOS почистит кэш, слишком велик.


🔗 Ссылка на подробную статью


💡 Вывод:

PWA на iOS в 2026 году - это технология, которая существует вопреки платформе, а не благодаря ей. Каждая фича требует обходных путей, каждый сценарий - проверки на настроение Safari. Apple построила экосистему, где веб-приложения могут работать, но никогда не будут работать слишком хорошо. Если вы выбираете этот путь, готовьтесь к тому, что значительная часть усилий уйдет не на функциональность, а на борьбу с ограничениями, которые намеренно не документированы и не исправляются годами.


➡️ Подписаться на канал
Мобильный трудоголик