EasySwift iOS🍏

TLS certificate validation on iOS

ℹ️ Если вы не знаете, что такое TLS и проверка сертификатов - не страшно: iOS почти всегда делает это за вас. Статья объясняет, какие проверки выполняет система при подключении по HTTPS: совпадение с хостом, срок действия, возможность использования для серверной аутентификации, подписи в цепочке и достижение корневого сертификата из Root Store Apple. Отдельно отмечены требования Certificate Transparency и то, что URLSession использует встроенную проверку, пока вы явно не добавите собственную обработку доверия.

⚙️ Разбор цепочки сертификатов и практические шаги. Сертификат сервера обычно подписан промежуточным центром, а тот - корневым; часто проблема - отсутствующий промежуточный сертификат на сервере. Статья показывает, как инспектировать цепочку через openssl s_client и openssl x509, какие поля смотреть (SAN, даты, ключевые расширения, SHA‑256 отпечаток) и как читать вывод. Важный момент: успешная проверка в OpenSSL не гарантирует, что iOS того же набора корней и путей доверия - всегда сверяйте с Apple Root Store и тестируйте на целевых версиях iOS и на реальных устройствах.

При проблемах:
➡️ Проверьте SAN, сроки действия, наличие всех промежуточных, совместимость корневого с Root Store нужной версии iOS
➡️ не забудьте про пиннинг и кастомную логику доверия - они изменяют поведение приложения и могут стать причиной разрыва связи.

✏️ Простая последовательность действий: получить цепочку через openssl, зафиксировать subject/issuer, даты и отпечатки, найти возможный trust
anchor и сверить с Root Store, затем протестировать на чистой установке целевых iOS.

Rich Push Notifications в iOS: Notification Service Extension, Notification Content Extension и неочевидные детали

Хороший и объемный туториал, который объясняет различие между Notification Service Extension и Notification Content Extension. Есть даже демо приложение, где можно понять, как связать их через категорию уведомления и payload, чтобы реализовать rich notifications (предзагрузка картинок и кастомный UI).

Основные практические выводы:
➡️ category обязательно должен лежать внутри aps
➡️ для запуска Service Extension нужен флаг “mutable‑content”: 1
➡️ attachments надо сохранять как локальные файлы и добавлять в UNMutableNotificationContent
➡️ время работы Service Extension ограничено (обработать дедлайн в serviceExtensionTimeWillExpire())


В Демо‑проекте предусмотрены две категории:
➡️ pushWithImageCategory - скачиваем small и big, добавляем UNNotificationAttachment; Content Extension явно ищет attachment по идентификатору “big-image” и подстраивает preferredContentSize
➡️ eventCategory (без media; Content Extension читает верхнеуровневые поля eventDate/eventLocation и переключает лейаут)

Есть еще пару практических советы:
➡️ регистрировать категории в основном приложении
➡️ правильно настроить UNNotificationExtensionCategory в Info.plist (строка → массив для нескольких категорий)
➡️ при кодовом UI указывать NSExtensionPrincipalClass
➡️ не забывать о согласовании Minimum Deployment для таргетов расширений

Применение gRPC при разработке приложений под iOS

❓ Хороший туториал по gRPC. В целом рассматривается тут как альтернатива REST: меньше лишних данных в ответах, бинарная сериализация через Protocol Buffers и более эффективный транспорт на базе HTTP/2 - это даёт меньше трафика и удобнее для систем с частыми или долгоживущими соединениями.

🖥 Много практической части: показано, как поднять локальный сервер на Swift с использованием grpc‑swift и swift‑protobuf, как описать контракт в .proto и сгенерировать исходники. Есть даже рабочий пример сервера и iOS‑клиента: SPM‑зависимости, команда генерации файлов, простой GreeterProvider на сервере и GreeterClientService с вызовом из SwiftUI.

Для перехода на gRPC статья даёт всё необходимое минимум: инструменты, пример .proto и работоспособный код, чтобы быстро получить опыт. Ну или вы сможете понять, что вам это все еще не нужно. 🔧

Letting AI See SwiftUI: Xcode Preview MCP in Practice — Pitfalls and Hopes

🆕 В Xcode 26.3 и 27 Apple открыла часть своих внутренних возможностей через MCP и это позволило автоматизировать рендеринг SwiftUI превью для CI/AI воркфлоу.

Автор подробно описывает практические проблемы:
➡️ нельзя явно задать модель устройства для рендера через MCP/инструменты рендера (поэтому приходится возвращаться к устаревшему PreviewProvider, если нужен конкретный iPhone)
➡️ рендер возвращает старый скриншот даже после изменения кода - из‑за частичных сборок или кэширования, особенно заметно при Swift пакетах.

Еще там есть набор проверенных обходов:
➡️ отмечать предпросмотр типом отпечатком (fingerprint) в коде, чтобы заставить компилятор пересобирать нужный файл и проверять совпадение отпечатка с возвращённым JSON
➡️ переключать активное устройство через XcodeSwitchRunDestination для более широкой поддержки семьёй устройств
➡️ рекомендации по стилю #Preview (писать не в одну строку). Автор перечисляет ещё ряд мелких граблей - краши хоста превью при hot‑replace, задержки при добавлении/удалении файлов в headless‑режиме и т. п.

👀 Если вы автоматизируете снимки интерфейса для CI или интегрируете превью в AI‑инструменты, учитывайте эти ограничения и держите отдельный набор preview‑файлов для автоматизации. Полезны приёмы с встраиваемым fingerprint и контрольным JSON, а также осторожность с выбором рабочего формата проекта (SPM vs .xcodeproj) и последовательностью операций при рендере.

Backporting SwiftUI APIs

❓ Как безопасно «доделать» новые SwiftUI API из iOS 27.1 для старых таргетов с помощью паттерна backport?
Два подхода:
➡️ отдельный namespaced тип Backport (через .backport)
➡️ расширение View с пометками @available и префиксом ported
Оба варианта делают availability проверку за вас - на новых платформах вызывается нативный modifier toolbarVerticalBehavior, на старых просто возвращается исходный view (или можно добавить собственную реализацию).

👀 Код показывает реализацию Backport<Content> и функцию toolbarVerticalBehavior, которая внутри использует if #available(anyAppleOS 27.1, *) и вызывает нативный modifier только при поддержке. Второй вариант помечен @available(iOS, introduced: 26.0, deprecated: 27.1, obsoleted: 28.0) - это полезно, потому что компилятор будет предупреждать вас, когда портируемая версия станет ненужной и её можно удалить.

✔️ Это подходит для небольших API, которые можно безопасно игнорировать на старых версиях или эмулировать простым поведением. Если поведение критично отличается на старых ОС, придётся реализовать совместимый код

ArrangementView: Think Before You Arrange

👀 Автор пробует новый ArrangementView в Xcode 27.1 и приходит к следующей мысли - API полезен, но не для всего подряд. Он не просто размещает два произвольных вида; это контейнер, который объявляет правила отношений между ними и решает, что показать и где, опираясь на доступное пространство, соотношения сторон и специальные области устройства (например, разделитель у iPhone Duo). Поэтому важно сначала продумать семантику контента - кто у вас «главный», кто - «второстепенный», какие данные или взаимодействия могут временно скрываться и как их восстановить.

🟢 Во-первых, понятия primary/secondary меняют смысл в split и в overlay: в split primary - тот, что остаётся видимым при сжатии, а в overlay primary - тот, что сверху. Это может привести к несоответствию ожиданий при переключении режимов.

🔴 Во-вторых, контейнер даёт только фрагменты информации о финальном расположении (ось сплита, z индекс, зарезервированные области), но не единое состояние «что пользователь видит сейчас», поэтому приложению иногда придётся самому реконструировать логику видимости и состояния.

ℹ️ И наконец, у ArrangementView есть «сладкое место» - сложные сценарии с разделителями и складными экранами (iPhone Duo): там он избавляет от громоздких ручных вычислений. Но если отношения между видами не ясны или переключение режимов - важная часть продукта, проще начать с HStack/VStack/ZStack или навигационных контейнеров.

Swift 6.4 Released

😮 А между тем Swift 6.4 подкрался незаметно!

➡️ Swift Build стал дефолтным в SwiftPM
➡️ Subprocess вышел на 1.0
➡️ расширена интероперабельность с C++20(!) и Java
➡️ поддержка WebAssembly и Android упростилась

✏️ Про чтения кода и безопасность:
➡️ синтаксис стал чище - optional some/any больше не требует скобок
➡️ появился @diagnose для управления предупреждениями на уровне исходников
➡️ можно вызывать async в defer и защищать финализацию от отмены через withTaskCancellationShield

🆕 Появились новые коллекции и типы (UniqueArray, UniqueBox, Ref/MutableRef, Iterable) для работы с не копируемыми значениями без лишних аллокаций и копий, а также безопасные API для временных буферов и загрузки сырых байт.

⚙️ Инструменты и тестирование:
➡️ лучшее отладочное представление модулей и меньшие dSYM
➡️ единая система сборки между IDE
➡️ SBOM-генерация в SwiftPM
➡️ расширенный Swift Testing (XCTAssert в Swift Testing, повтор тестов, кастомные представления при падениях)

AI-агент вместо ручного регресса: или bottom-up инициатива, которая смогла

💎 В AI-центре я в основном занимаюсь B2C-продуктами. И на одном из них мы тесно работали с VLM (Visual Language Model) — моделью, которая умеет «видеть» интерфейс и понимать его примерно как человек.

🔥 Параллельно мы брейнштормили AI-based инициативы, которые могли бы ускорить и упростить нашу работу. И подумали: а что, если дать VLM изображение с симулятора, научить её тапать, свайпать и скроллить, а затем обогатить тест-кейсами из Allure? Так и появился прототип AI-агента для автоматизации регресса.

✏️ Сейчас проект уже вышел за рамки MVP: мы активно его развиваем и интегрируем в другие команды. Что получилось, с какими сложностями столкнулись и как их решали — рассказываем в статье.

❗️ А еще автор статьи и человек, который тащит этот инструмент пообещал ответить на все ваши вопросы. Так что закидывайте вопросы — с радостью обсудим то, что осталось за кадром.

New Hashable conformances in Swift 6.4

❓ В Swift 6.4 добавил Hashable к нескольким типам стандартной библиотеки, которые уже можно было сравнивать, но нельзя было использовать как ключи словаря или элементы Set.

⚠️ Главное по изменениям:

➡️ Dictionary.Keys теперь Hashable. Можно хранить view ключей прямо в Set или использовать как ключ словаря, равенство и хеширование основаны на множестве ключей (порядок и значения не важны). Когда порядок важен, явно сортируйте ключи или превращайте их в массив.

➡️ CollectionOfOne и EmptyCollection получили условные Equatable/Hashable. Это в основном повышает согласованность стандартной библиотеки и помогает в обобщённых алгоритмах.

➡️ UnownedTaskExecutor стал Hashable. Это удобно для реализации пулов и маппинга ресурсов на исполнители — теперь можно O(1) поиск в словаре вместо линейного поиска по массиву. Однако стоит помнить: UnownedTaskExecutor по‑прежнему не удерживает исполнитель, поэтому нужно вручную очищать записи при завершении исполнителя, иначе словарь будет содержать «висячие» ключи.

Running iOS Background Tasks Reliably, Part 1

🖥 Автор делится практическими наблюдениями по использованию BGTaskScheduler в iOS 26 на примере своего приложения для синхронизации календарей. Ключевая мысль: фоновые задачи на iOS нельзя воспринимать как cron - система даёт только возможности, а не гарантии. Тем не менее при аккуратной настройке - регистрация обоих типов задач (BGAppRefreshTask и BGProcessingTask), ограничение времени выполнения, защита от гонок при завершении и агрессивная, но осмысленная перезапись задач - можно получить достаточную надёжность для большинства сценариев.

❗️ Пару важных моментов:
➡️ ставьте короткие таймауты (примерно 3 с для обновлений и ~25 с для тяжёлой обработки)
➡️ используйте token/lock, чтобы вызывать setTaskCompleted(success:) ровно один раз
➡️ не переотправляйте задачу при каждом срабатывании (сравнивайте existingEarliest и desiredEarliest и привязывайтесь к lastRun)
➡️ учитывайте требования requiresExternalPower/Network
➡️ форсируйте ресабмит после перезагрузки или обновления ОС.

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

From Using AI to Delegating Work to AI (Part 2): What I Mean by Delegability

В продолжении прошлого поста про делегирование задач ИИ.

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

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

✔️ Оформляйте задачи как контракт - цель, критерии «готово», ограничения и требуемые артефакты (коммит, тесты, чек-лист). Такой подход дороже по времени и токенам, но даёт стабильный, воспроизводимый поток работы с ИИ и подходит для сложных задач, где важна надёжность результата.

From Using AI to Delegating Work to AI (Part 1): Why I No Longer Wait for Stronger Models

🔍 Интересная статья-размышление на тему: не «какой AI лучше», а про то, почему даже сильные модели пока не решают задачу полноценной передачи работы на автопилот. Автор пишет, что у AI есть разные удобные режимы: чат для обсуждения, встроенная помощь в приложении для быстрых подсказок и агент для более длинных цепочек действий. Но главный вывод другой: способность модели выполнить задачу еще не значит, что ей можно спокойно доверить весь процесс без постоянного контроля.

🔴 В реальной разработке мало просто сгенерировать код или получить ответ на вопрос, нужно еще четко задать границы задачи, критерии готовности, проверки и правила передачи между этапами. Автор подчеркивает, что это плохо держать только в голове модели или в длинном промпте: правила лучше выносить во внешние инструменты и явные шаги, чтобы они не «плыли» по ходу работы. Иначе даже хороший агент начнет терять контекст, путать временные решения с финальными и делать работу не так, как ожидалось.

ℹ️ AI полезен не как заменитель разработчика, а как помощник в обсуждении, черновой реализации и проверках. Чем сложнее задача, тем важнее разбивать ее на этапы, фиксировать цель, ограничения и критерий завершения, а также понимать, где решение должно вернуться человеку. Это хороший трезвый взгляд на AI в разработке: не ждать «магической» модели, а строить процесс так, чтобы он был надежным уже сейчас.

Modern iOS Performance: Episode 2

⚠️ Переход на Swift Concurrency и другие современные абстракции не делает приложение автоматически быстрее - они упрощают код, но могут невольно сериализовать параллельную работу, переместить тяжёлые вычисления на главный поток или скрыть расходы времени выполнения. Компилятор примет код, но это не гарантирует корректной модели конкуренции: важно явно понимать, кто запускает, отменяет и к какому состоянию имеет доступ асинхронная задача.

⚙️ Автор разбирает расходы абстракций - протоколы, type-erasure, actors, AnyView/AnyPublisher и т.п. - особенно на «горячих» путях (скролл, рендер, частые обновления). Цель - не убрать абстракции, а понять, где их стоимость платится и действительно ли это критично. Отдельно - влияние статической и динамической линковки, менеджеров зависимостей и модульности на время запуска; большой граф зависимостей часто скрыто тянет старт приложения.

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

How Do You Build a Mutex That Works with async/await ?

🔍 Автор столкнулся с задачей запретить одновременный запуск async метода и показал, почему ни actor, ни Mutex не подходят. Решение - библиотека TaskGate (AsyncGate и AsyncRecursiveGate): это асинхронный «турникет», который допускает только одну задачу внутрь и при этом безопасно позволяет await внутри секции.

❓ Внутреннее состояние - два состояния (.unlocked и .locked(queue)) и простой NSLock для защиты этих маленьких синхронных обновлений. Первая задача просто «заходит» и оставляет дверь закрытой; последующие регистрируют свою continuation как билет в очередь и «паркуются» без блокировки потока. Когда владелец выходит, он не открывает ворота всем сразу, а передаёт продолжение следующему - handoff, честная FIFO-очередь, никакой толкучки.

✔️ Этот подход подход даёт нужную семантику асинхронной взаимной исключённости и решает проблему priority inversion — при поддержке ОС библиотека эскалирует приоритеты ожидающих задач, прокидывая bump по очереди.

❌ Из минусов - AsyncGate не Sendable и предназначен жить в одном акторе (во избежание ошибок), а вход в тот же gate из той же задачи приведёт к дедлоку - для этого есть AsyncRecursiveGate.

🧭 Podlodka iOS Crew: разработка с AI

С 14 по 18 сентября пройдет новый сезон Podlodka iOS Crew. В этот раз в центре внимания авторов конференции то, как AI меняет iOS-разработку.

Что ждёт участников:

🍏 Стратегия внедрения терминальных ИИ-агентов и MCP-интеграции в ежедневную iOS-разработку

🍏 AI как экзокостюм мобильного разработчика: harness, skills, CLI, orchestration, validation и evals

🍏 Знания о том, как запускать локальные модели на Apple Silicon

🍏 Готовые скрипты, которые можно забрать в свой проект: шаблон рабочего пространства агента, примеры скиллов и MCP, пайплайн от Jira-задачи до Merge Request.

И это ещё не всё! Подробности о сезоне смотрите на сайте, и там же есть билеты по early-bird цене.

👉 Билеты на Podlodka iOS Crew

А по промокоду swift_ioss получите скидку🎁