iOS Broadcast

🐥 Immediate Tasks в Swift Concurrency
Сначала кажется, что это просто ещё один новый API в Swift 6.2. А потом понимаешь, что Task.immediate это уже не про синтаксис, а про момент старта async-работы. Обычный Task создаётся и ставится в очередь на выполнение позже.
Task.immediate начинает выполняться сразу в текущем execution context, пока не упрётся в первый настоящий suspension point.

То есть разница маленькая по формулировке, но вполне реальная по последствиям.

Где это полезно:

🟢когда у вас короткая операция и лишняя задержка на scheduling уже чувствуется
🟢когда код уже находится на нужном actor и не хочется лишнего перехода
🟢когда важно сделать старт async-операции максимально предсказуемым

На практике это:
🟢меньше лишней задержки на запуск задачи
🟢больше контроля в performance-sensitive местах
🟢более точное поведение в некоторых UI и concurrency-сценариях

Но это как раз тот случай, где новая возможность легко превращается в красивую переоптимизацию:
🟡Task.immediate не должен становиться новым дефолтом вместо обычного Task
🟡если у вас нет измеримой проблемы, скорее всего обычного Task достаточно
🟡чем тоньше контроль над concurrency, тем выше шанс усложнить код без реальной пользы

🈸 Apple добавила рассрочку для годовой подписки
Я сначала не понял а потом как понял. Apple анонсировала новый вариант подписки: теперь можно продавать подписку с ежемесячной оплатой, но с обязательством на 12 месяцев. Это уже можно настраивать в App Store Connect и тестировать в Xcode:
🟢можно сделать оффер дешевле на год вперед со скидкой
🟢появляется новый формат для A/B‑тестов подписок и стратегии ценовой политики
🟢придётся аккуратно объяснять commitment в UI, иначе легко словить недоверие и просадку в конверсии и отмену подписки через оспаривание

Что важно помнить:
🟡пользователь платит каждый месяц, а не сразу за год
🟡отменить можно в любой момент, но подписка не продлится только после выполнения уже взятых платежей
🟡Apple будет показывать, сколько платежей уже прошло и сколько осталось
🟡для пользователей заработает с выходом iOS 26.5 / iPadOS 26.5 / macOS 26.5 / tvOS 26.5 / visionOS 26.5 в мае

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

🐥 SwiftFormat 0.61.0: небольшое приятное обновление
Добрался до обновления зависимостей проектов, оказывается вышел SwiftFormat 0.61.0
Что нового в релизе:
🟢добавили wrapCaseBodies
🟢добавили redundantEmptyView
🟢добавили preferSwiftStringAPI
🟢улучшили sortImports
🟢поправили ряд багов для современного Swift, включая:
🟢MainActor closures
🟢nonisolated(nonsending)
🟢Swift Testing
🟢conditional imports
🟢formatting raw string literals

Круто что SwiftFormat становится лучше адаптирован под современный Swift.
Если у вас в проекте уже много concurrency, macro-like конструкций, test utilities и более сложный синтаксис, риск сломал код/читабельность при форматировании становится ниже.
Новые правила вроде redundantEmptyView и preferSwiftStringAPI убирают мелкий визуальный шум и помогают держать стиль кода стабильным

🐥 Swift выходит за пределы Xcode. Что это меняет для iOS‑разработчика
Официальный Swift extension доступен через Open VSX, а значит Swift можно нормально использовать не только в Xcode, но и в Cursor, VSCodium, AWS Kiro, Google Antigravity и других совместимых редакторах. Новость не новая, но только сегодня опробовал на практике. На первый взгляд это мелкая новость, на практике гораздо больше - Swift всё заметнее встраивается в AI-assisted workflows, где IDE становится не просто окном для кода, а средой для навигации, рефакторинга, генерации шаблонов и агентных сценариев. Xcode сильно отставал от стандартов других IDE, а теперь рынок меняется:
🟢Swift официально приходит в экосистему Open VSX. Это снижает трение при работе в альтернативных IDE и делает поддержку менее экспериментальной
🟢Появляется нормальная база для AI‑воркфлоу вокруг Swift. Если IDE умеет жить поверх Open VSX и LSP, в неё уже проще встраивать AI‑ассистентов для объяснения кода, генерации boilerplate, навигации по проекту и рефакторинга
🟢Swift‑разработка становится менее привязанной к одному инструменту. Для части задач Xcode остаётся незаменим, но ежедневная работа с кодом, поиском, review и рефакторингом всё чаще может происходить вне него

Ложка дегтя в том что Xcode всё ещё остаётся центром мира для задач:
🔴Запуска и отладки iOS‑приложений на симуляторах и девайсах;
🔴Подписи, capabilities, provisioning
🔴Инструменты, профайлинг
Xcode не умер и не умрёт в обозримом будущем. Но он перестаёт быть единственной точкой входа в Swift‑разработку.

🐥 lazy var в SwiftUI
Простой пятничный пост про lazy. В SwiftUI view это struct и пересоздается чаще чем вы думаете. В статье разбирается почему lazy который отлично работает в классах начинает вести себя странно в SwiftUI и какие замены безопаснее.
🔵lazy требует мутации при первом доступе а body у View не mutating поэтому lazy прямо внутри SwiftUI view в лоб либо не компилируется либо приводит к не тому кэшированию
🔵Даже если вы обойдете компилятор смысл lazy как кэша ломается потому что view value type и может пересоздаваться часто и не обязана жить достаточно долго чтобы сохранить кэш
🔵lazy не thread safe по-умолчанию, а SwiftUI активно ходит по состояниям на разных фазах рендера и вы легко получите race condition если дергать из конкурентного кода

Типичный анти пример - хотим лениво создать DateFormatter в View. В итоге либо компилятор ругается либо форматтер пересоздается снова и снова и вы наоборот ухудшаете performance. Что можно сделать:
🟢Для простых вещей держать объект в @State чтобы он жил как состояние а не как поле пересоздаваемой структуры
🟢Для сервисов и зависимостей выносить в ссылочные типы и хранить в observable контейнере и уже там применять lazy где это уместно
🟢Помнить про main thread - lazy откладывает работу но если она случится в момент first render вы получите лаг в UI
🟢lazy это инструмент про lifecycle и ownership. В SwiftUI lifecycle принадлежит не вашему struct а системе поэтому кэшировать надо там где действительно есть стабильная жизнь объекта а не там где удобно написать keyword

🎯 Apple Foundation Models на практике: встраивание локальных AI фичей в Swift
Я продолжаю внимательно следить за реальным адопшн локального AI и пока применений сильно меньше чем хайпа вокруг. Почему так? Все еще не все устройства это поддерживают, а те что поддерживают скорее превращают телефон в греку для рук чем делают что-то полезное. Но тут представлен практический кейс с Apple Foundation Models. Без очередного LLM в iPhone, а с нормальным разбором того, как это можно встроить в продукт. Автор в VinylCrate повесил на on-device модель сразу 4 сценария: summary коллекции, поиск insights, анализ конкретного альбома и персональные рекомендации. Все локально — без API keys, без платы за токены и без отправки пользовательских данных на сервер.
🟢Сильный буст UX почти без инфраструктуры.
🟢 Локальные summary, теги, объяснения, рекомендации, персональные подсказки как обычный слой интерфейса

Мои выводов из статьи:
🔵availability надо проектировать как отдельное состояние продукта, а не как один bool
🔵prompt приходится жестко ужимать из-за маленького контекстного окна
🔵on-device inference все равно требует кэша, потому что цена теперь не в токенах, а в latency и батарее
🔵рекомендации лучше строить гибридно: модель предлагает гипотезу, внешний API валидирует детали

Понравился сам подход: по сути это попытка делать AI-фичи по-эппловски. Собрали контекст локально, обработали на устройстве, показали пользователю результат, а тяжелые или сетевые шаги можно откладывать до момента, когда приложение снова активно или когда система даст окно на фоновые задачи. У Apple для этого есть Background Tasks, а у BGProcessingTaskRequest даже есть requiresNetworkConnectivity. Обычные приложения не могут поднять свой постоянный демон, который гарантированно проснется ровно в момент появления сети и пойдет прогонять модель в фоне. На iOS background execution по умолчанию не гарантирован: backgrounded apps обычно suspended, а фоновые задачи запускаются тогда, когда это решит система. То есть системные приложения Apple могут выглядеть почти магически, но публичный SDK для сторонних apps заметно строже. Эффекта как у Photos с анализом пока телефон стоит на зарядке не достичь
И вот это, кажется, главный вывод. Foundation Models — это не убийца облачных LLM, а очень сильный новый слой для приватных, частых и хорошо ограниченных AI-сценариев внутри приложения. Для многих инди-проектов этого уже достаточно, чтобы заметно поднять UX и вообще не заходить в историю с токенами, серверами и передачей пользовательских данных наружу

Тесты в iOS — это не “для галочки”. Это способ убрать хаос из разработки.

Без тестов любые изменения превращаются в лотерею: что сломается, где и когда — неизвестно.

На открытом уроке разберём, как Юнит‑тесты (Unit-тесты) помогают держать качество под контролем и делать изменения предсказуемыми:
🔵какие инструменты тестирования есть в iOS SDK
🔵чем отличаются тесты в Xcode и Swift Testing
🔵как начать писать тесты без лишней сложности

В итоге станет понятно, как тесты:
🟢документируют код
🟢 помогают ловить ошибки раньше
🟢делают разработку стабильнее и спокойнее

🗓 20 апреля в 20:00 МСК

Встреча перед стартом курса «iOS‑разработчик. Продвинутый уровень».

➡️ Записывайтесь на вебинар и начните контролировать качество кода, а не догонять ошибки!

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

😌 Как телеграмм планирует обходить цензуру
В последнем посте мы начали обсуждать как именно iOS приложения могут выявлять VPN. Но как с другой стороны приложения планируют бороться с блокировками? В последнем посте Павел поделился новостями про цифровое сопротивление 2.0 и то как именно он планирует бороться с блокировкой телеграмм. Чтобы в этом разобраться, давайте разберемся как работает DPI:

DPI — это не просто блокировка по IP, а система, которая смотрит глубже в сам трафик: как именно клиент начинает соединение, какие байты отправляет первыми, какие TLS extension указывает, какой длины поля, в каком порядке они идут. Упрощенно: если обычный файрвол смотрит на адрес конверта, то DPI еще и на почерк, формат письма и даже на то, как именно заклеен конверт. Именно поэтому можно резать не весь интернет, а узнавать конкретный тип трафика по сигнатуре. В кейсе Telegram речь шла как раз не столько про адреса серверов, сколько про узнаваемый fingerprint хэндшейка TLS. C 1 апреля iOS-клиенты через MTProto/MTProxy на российских сетях получают handshake timeout, при этом desktop и некоторые другие сценарии работали. Это хорошо совпадает с версией, что DPI начал узнавать Telegram не по IP, а по шаблону fake-TLS/ClientHello. В обсуждениях прямо пишут, что этот fingerprint у российских DPI/TSPU был помечен как TELEGRAM_TLS и начал блокироваться.
После черго разработчики телеграмм, наконец, подправили транспортный слой маскировки, чтобы трафик MTProxy выглядел менее палевно для DPI.

Самый конкретный и подтвержденный фикс такой:
🟢extension type 0xfe02 заменили на 0xfe0d
🟢размер случайных данных увеличили с 20 до 32 байт

Это назревало - 0xfe02 в обсуждениях называется невалидным или как минимум аномальным extension для такого ClientHello, а 20 байт там, где обычно ждут 32-байтный X25519 key share, тоже делает рукопожатие подозрительно телеграмным. Android PR описывает это совсем прямым текстом: старый fingerprint ловился как TELEGRAM_TLS, а замена на 0xfe0d и 32 байта делала ClientHello ближе к реальному браузерному TLS-профилю.

🧰 Что с Android
На Android есть очень показательный PR DrKLO/Telegram#1949, где эти две правки описаны буквально строка в строку. Там же отдельно отмечено, что 12.6.4 Android beta уже содержала proposed client hello fix, подтвержденный community-анализом pcap. То есть для Android цепочка выглядит почти полностью публичной.

🔨 Что с iOS
С iOS картина менее прозрачная. В публичном PR Telegram-iOS#2089 предлагали приблизить MTProtoKit ClientHello к актуальному Safari-профилю: убрать deprecated 3DES и TLS 1.0/1.1 из supported_versions. Позже в обсуждениях писали, что 12.6.2 iOS stable уже вышел и community подтверждает рабочий TLS ClientHello fix для MTProto-EE. Но сам PR в итоге закрыли с формулировкой Closed in favor of an internal implementation, а в tdlib/td#3635 один из участников прямо пишет, что все нужные изменения уже сделаны в private TDLib version. То есть на iOS фикс, похоже, реально был выкачен, но его точный финальный diff не весь виден в публичном GitHub сразу.

📁 В Desktop PR #30528 пошли уже дальше базового hotfix:
🟢рандомизировать padding ClientHello
🟢убрать фиксированный размер TLS records
🟢делать packet coalescing с небольшой случайной задержкой

Зачем это нужно: даже если DPI перестал узнавать конкретный ClientHello, он может продолжать искать характерный поведенческий паттерн трафика — одинаковые размеры чанков, одинаковые burst-пачки маленьких пакетов, статичную длину рукопожатия. Этот PR как раз про то, чтобы убрать такие вторичные сигнатуры. Но это уже похоже на следующий этап, а не на тот минимальный фикс, который Дуров имел в виду в своем посте. Больше всего удивляет что исправление вышло так поздно

🕸Минцифры попросило крупнейшие в России цифровые площадки помочь с блокировкой VPN
В ходе обсуждения в чатах, задался вопросом, а как iOS приложения могут отслеживать наличие включённого VPN. Если в случае с Android все максимально надежно ConnectivityManager - прямой сигнал через NetworkCapabilities.TRANSPORT_VPN. То с iOS только только косвенные возможности через NWPathMonitor и usesInterfaceType(.other). Если же VPN включен на уровне роутера, отследить на уровне приложения не возможно.

Можно пойти со стороны бека, но бекенд почти никогда не видит VPN как системный факт. Он видит exit IP и строит выводы по IP-разведке: VPN, proxy, hosting, Tor, relay, provider name и похожие признаки. Нельзя определить где стоит туннель: на телефоне, на домашнем роутере, на корпоративном шлюзе или на другом промежуточном узле. Скорее всего NWPathMonitor, тип .other на iOS будет считаться как подозрение и уже на сервере дополнительно определяться. Но отличить фактический VPN от путешествия будет невозможно.
Apple достаточно хорошо охраняет приватность пользователей и не дает другим приложениям лишней информации, ни о других установленных приложениях, ни о состоянии сети. Даже антифрод фреймворк DeviceCheck не дает информации о деталях пути.

🈸 Что творится с ревью в AppStoreConnect?
Зависшие ревью приложений - тема с которой сейчас сталкиваются многие iOS разработчики. Теорий было много, я постепенно собирал данные из разных источников и похоже что причин сразу несколько.
По данным Appfigures, в 2025 году App Store получил около 557 тысяч новых сабмитов, что на 24% больше, чем в 2024-м, и это первый по-настоящему сильный разворот вверх с 2016 года. Более свежие отчеты говорят уже о росте почти до 600 тысяч за 2025 год и о 235,8 тыс. новых приложений только за Q1 2026. В App Store вернулся supply-side growth. Рост предложения со стороны создателей приложений. То есть пользователей в целом не стало драматически больше, но создавать приложения стало намного проще и экономически осмысленнее.

Почему это произошло:
1. AI резко снизил стоимость входа в разработку.
В 2025 случился разворот, вызванный сочетанием AI-инструментов, понятной монетизации и новых каналов дистрибуции. Всплеск с agentic/vibe coding инструменты вроде Claude Code и Codex позволяют непрофессионалам собирать рабочие приложения по промптам

2. В рынок массово пришли не студии, а индивидуальные создатели приложений
Вот это, мне кажется, самая важная часть роста приложений. Дешевле сделать MVP, проще протестировать спрос, легче выйти в дистрибуцию через TikTok/Instagram, а подписочная модель делает даже маленькие приложения потенциально жизнеспособным микробизнесом

3. Подписки и AI-категория дали людям ощущение, что маленькое приложение может зарабатывать
На AI-приложения в 2024 пользователи потратили $1,4 млрд, а в 2025 сегмент шел к $2+ млрд. Это важный сигнал: рынок увидел, что даже относительно простые AI-обертки и utility-приложения могут монетизироваться, и это подстегнуло волну новых запусков.

Теперь к самому больному месту — почему все жалуются на review.
Официально Apple продолжает говорить, что 90% сабмитов рассматриваются менее чем за 24 часа. Но в параллельных комментариях для прессы компания уже формулирует это мягче: 90% в пределах 48 часов, более 200 тыс. сабмитов в неделю за последние 12 недель, при среднем review time 1,5 дня, и с использованием AI-инструментов внутри самой модерации. При этом в публичных обсуждениях видно, что часть разработчиков действительно сталкивалась с заметно более длинными очередями, особенно в январе-марте 2026. У многих ожидание уходит в недели. Средняя публикация остается быстрой, а хвост сложных или подозрительных сабмитов — резко удлинился.

Apple страдает не только от объема, но и от смены типа риска.
Раньше App Review в основном отсеивал баги, неполные сборки, приватные API, контентные нарушения. Сейчас у него появилась новая проблема: приложения, которые с помощью AI генерируют или исполняют код, меняющий функциональность после публикации. А это конфликтует с Guideline 2.5.2: приложение не может скачивать, устанавливать или выполнять код, который меняет функции приложения. Именно по этому правилу Apple блокировала или снимала vibe-coding приложения. Из-за этого App Review теперь проверяет не превращается ли приложение в рантайме в конструктор других приложений или оболочку для динамически исполняемого функционала. Это сильно дороже в ручной модерации и почти неизбежно создает узкие места именно на новых типах AI-продуктов.

В 2025-2026 App Store переживает не просто новый цикл роста, а переход к эпохе массового инди-паблишинга. Барьер обучиться программированию больше не обязателен. Достаточно уметь формулировать задачу, собрать MVP с AI, быстро завернуть его в подписку и протестировать органический канал привлечения. Именно поэтому взлетели не только серьезные AI-продукты, но и длинный хвост персональных микроприложений, соло-проектов и нишевых утилит. Рынок становится жестче: новых приложений больше, внимание пользователя — нет