iOS Broadcast

📱 Топ 10 обновлений SwiftUI с WWDC26 Информации после WWDC конкретно про SwiftUI много, но что действительно изменилось? Собрал свои хайлайты на основе сессий и статьи: 1. Новый внешний вид Liquid Glass Стандартные компоненты получают обновлённый вид почти бесплатно. Можно просто собрать проект в Xcode 27 и посмотреть, что изменилось в реальном интерфейсе 2. Больше контроля над кастомным Liquid Glass Для своих glass-элементов теперь можно явно указать, что они интерактивные. Особенно актуально для iPad и macOS, где интерфейс живёт не только под пальцем, но и под курсором 3. appearsActive для окон Наконец-то можно нормально реагировать на активное и неактивное окно. Маленькая штука, но для iPadOS и macOS это тот самый штрих, который делает приложение менее айпадным на большом экране 4. Toolbars стали взрослее Появились приоритеты видимости, отдельное overflow-меню, возможность закреплять важные действия и автоматически сворачивать navigation bar при скролле. То есть меньше попыток угадать, что спрячется на маленьком экране и где окажется кнопка Share. 5. Новый Document API SwiftUI серьёзно прокачали для document-based приложений. Асинхронное чтение и запись, работа с большими файлами, прогресс операций, несколько сценариев создания нового документа. Для заметок, редакторов, графических приложений и любых файловых историй это прям вау 6. Drag & Drop без танцев Теперь можно добавлять reordering не только в List, но и в сетки, стеки и кастомные layout. И всё это одним подходом на разных контейнерах. 7. Swipe Actions не только внутри List Swipe actions теперь можно использовать в произвольных scrollable layout. Кажется мелочью, пока не надо добавить знакомое iOS-взаимодействие в кастомную ленту или карточный интерфейс 8. Confirmation dialogs и alerts стали ближе к sheets Появился нормальный item-based подход. Положили объект в binding, SwiftUI сам показывает нужный диалог. Меньше булевых флагов вида isShowingDeleteDialog, меньше шансов случайно открыть не тот alert. 9. AsyncImage начал уважать HTTP cache SwiftUI теперь использует стандартное HTTP-кеширование по умолчанию и учитывает cache headers сервера. Это один из тех апдейтов, которые работают сами из коробки, проверьте что на беке хедеры настроены. 10. @State для классов стал ленивым Объекты, созданные внутри @State, больше не пересоздаются впустую при каждом обновлении view. Меньше лишних аллокаций, меньше странных сайд-эффектов в init, чуть спокойнее профайлер. Полезные ссылки: 🔵 What’s new in SwiftUI, WWDC26 🔵 SwiftUI guide, WWDC26 🔵 SwiftUI updates в документации Apple 🔵Build powerful drag and drop in SwiftUI

➕ «В Яндекс я попал только с третьего раза!». Побывали в офисе Яндекс Еды, потрогали самурайский меч и поговорили со старшим iOS-разработчиком Львом Бондаренко — обсудили его любимые проекты, тренды мобильной разработки и алгоритмы на собеседованиях. ↘️ Это «1х1» — формат, в котором яндексоиды проводят с вами личную встречу на работе. Смотрите здесь, на YouTube и в VK Видео. 👀 Присоединяйтесь к нашей команде

🕸 HTTP QUERY: наконец-то GET с body без нюансов HTTP стандарт, обновился и на этот раз добавили новый метод, QUERY. Поражает, конечно что это случилось только сейчас, с учетом какие танцы проводила вся it индустрия. Давайте на примере, какой метод выбрать для метода поиска? 🟡GET метод с аргументами в query мараметрах выглядит сложно и имеет ограничение по-длинне, а лимиты у прокси еще меньше по факту чем в стандартах 🟡POST метод с аргументам в теле запроса не будет кешироваться cdn и будет создавать доп. нагрузку на ваш сервер. Не говоря о том что даже в стандарте этот метод не для этого и является не идемпотентным 🟡GET метод чисто по спеке тоже может иметь тело, но значительная часть прокси его игнорируют или перетирают Вот и получается что есть 3 стула и все с нюансами. Новый метод QUERY, опубликованный как RFC 10008, закрывает именно эту дыру. Его смысл простой: это безопасный и идемпотентный запрос, который может нести тело.

QUERY /feed HTTP/1.1
Content-Type: application/json

{"q":"swift","limit":20,"sort":"-published"}

QUERY говорит серверу, клиенту, CDN, прокси, SDK и будущему человеку в коде: это запрос данных, он не должен менять состояние целевого ресурса, его можно безопасно повторить после сетевого сбоя, и его ответ в принципе может кэшироваться. Пока рано радоваться, блеснуть этим знанием можно разве что на собесе, стандарту нет еще и месяца и aboption произойдет в лучшем случае через год.

🎯 Apple официально депрекейтит ImageCreator ImageCreator больше не будет работать в iOS/iPadOS/macOS/visionOS 27. На форумах тема болезненная: у кого уже была кастомная AI-image UX, остаётся ImagePlaygroundViewController или внешний сервис. Программная генерация картинок через системную on-device модель больше не должна быть частью вашего production-кода. И тут важно не само слово deprecated. Мы все привыкли, что deprecated API может жить годами, иногда почти как домашний питомец в legacy-коде. Здесь история жёстче. В beta OS код ещё будет компилироваться, но Xcode начнёт показывать warnings. При этом TestFlight-сборки с ImageCreator уже не будут нормально работать и могут падать в runtime. А на public-релизах iOS 27+ такой код вообще перестанет компилироваться. Что я бы проверил в проекте: 🟢Есть ли прямое использование ImageCreator в app target, extensions, внутренних SDK или feature modules 🟢Не спрятана ли генерация картинок за абстракцией вроде AIImageService, AvatarGenerator, StickerGenerator 🟢Есть ли fallback для пользователей на iOS 27+, если генерация картинок была частью ключевого сценария Apple меняет границу контроля: вместо того чтобы приложение программно просило систему "сгенерируй мне картинку", разработчику предлагают показывать Image Playground sheet — системный, управляемый Apple компонент. Это заметная разница для продукта. Sheet — это безопаснее, консистентнее и понятнее для App Review. Но это хуже для тех сценариев, где нужна полностью кастомная генерация: аватары, стикеры, обложки, onboarding, игровые ассеты, автоматические превью. Если такой контроль нужен, Apple прямо оставляет второй путь: интегрировать другой image generation service. Перевод с apple-ского: теперь это ваша инфраструктура, ваши лимиты, ваши moderation rules, ваша стоимость запросов и ваши edge cases.

Apple официально депрекейтит ImageCreator ImageCreator больше не будет работать в iOS/iPadOS/macOS/visionOS 27. На форумах тема болезненная: у кого уже была кастомная AI-image UX, остаётся ImagePlaygroundViewController или внешний сервис 🧵 Apple выключает ImageCreator: AI-картинки теперь не просто API Вот это хороший пример новости, которая выглядит маленькой строкой в Apple Developer News, а на практике может сломать вполне реальную фичу в приложении. Apple объявила, что ImageCreator из Image Playground framework прекращает работу в iOS 27, iPadOS 27, macOS 27 и visionOS 27. То есть программная генерация картинок через системную on-device модель больше не должна быть частью вашего production-кода. И тут важно не само слово deprecated. Мы все привыкли, что deprecated API может жить годами, иногда почти как домашний питомец в legacy-коде. Здесь история жёстче. В beta OS код ещё будет компилироваться, но Xcode начнёт показывать warnings. При этом TestFlight-сборки с ImageCreator уже не будут нормально работать и могут падать в runtime. А на public-релизах iOS 27+ такой код вообще перестанет компилироваться. То есть Apple фактически говорит: если вы успели встроить ImageCreator как «тихий» API для генерации картинок внутри своего UX — пора перепроектировать сценарий. Что я бы проверил в проекте: 🟢 есть ли прямое использование ImageCreator в app target, extensions, внутренних SDK или feature modules; 🟢 не спрятана ли генерация картинок за абстракцией вроде AIImageService, AvatarGenerator, StickerGenerator; 🟢 проходят ли TestFlight-сборки на iOS 27 beta без runtime-сюрпризов; 🟢 есть ли fallback для пользователей на iOS 27+, если генерация картинок была частью ключевого сценария; 🟢 не обещает ли onboarding, paywall или marketing screen фичу, которая теперь зависит от удалённого сервиса или системного sheet. Главная мысль Apple не просто убирает класс. Она меняет границу контроля: вместо того чтобы приложение программно просило систему «сгенерируй мне картинку», разработчику предлагают показывать Image Playground sheet — системный, управляемый Apple experience. Это заметная разница для продукта. Sheet — это безопаснее, консистентнее и понятнее для App Review. Но это хуже для тех сценариев, где нужна полностью кастомная генерация: аватары, стикеры, обложки, onboarding, игровые ассеты, batch generation, автоматические превью. Если такой контроль нужен, Apple прямо оставляет второй путь: интегрировать другой image generation service. Перевод с apple-ского: теперь это ваша инфраструктура, ваши лимиты, ваши moderation rules, ваша стоимость запросов и ваши edge cases. Почему это актуально сейчас: 🟡 iOS 27 ещё в beta, но TestFlight уже важен: именно там такие вещи обычно всплывают перед релизом, когда «ну мы потом поправим» внезапно превращается в блокер; 🟡 это хороший сигнал по Apple Intelligence API в целом: не стоит строить продуктовую фичу так, будто любой новый AI-класс Apple навсегда станет стабильным headless API; 🟡 если AI-фича влияет на монетизацию или core UX, её нужно закрывать feature flag’ом, аналитикой, fallback-экраном и отдельным smoke-тестом под новые OS. Мой вывод простой: ImageCreator стоит искать в коде уже сейчас, даже если фича экспериментальная. Apple оставляет Image Playground как пользовательский системный сценарий, но забирает у разработчика удобный программный рычаг. Для маленького pet feature это неприятно. Для production-фичи с paywall — уже миграционный план, а не новость на потом.

🎯 iOS 27, Your App, and Siri Вот это уже не про вау, Siri наконец-то сможет ответить на вопрос из старой переписки. Для разработчика интереснее другое: если новая Siri действительно начинает работать с личным контекстом и данными приложений, то приложение должно заранее объяснить системе, какие сущности у него есть, как их искать и что сейчас показано на экране. Главная мысль Jordan Morgan: лето перед iOS 27 стоит потратить не на гадание про магию AI, а на скучную, но важную инвентаризацию App Intents/App Entities. Для себя вижу схему работы примерно в следующем: 🔵Какие модели должны быть видны Siri, Shortcuts и системному поиску 🔵Есть ли для них легковесные AppEntity, а не попытка тащить доменную модель целиком 🔵Можно ли просто сделать сущность IndexedEntity, чтобы система сама индексировала данные 🔵Попадает ли ваша модель в готовый Apple App Schema. Если да — это почти всегда лучший путь 🔵Есть ли привязка текущего экрана к сущности через NSUserActivity или view annotations 🔵Нужен ли Transferable, чтобы Siri могла передавать ваши данные дальше: например, отправь эту тренировку по почте Отдельно важный сниппет: App Schemas выглядят как самый ценный слой. Apple уже обучает Siri понимать эти домены, их свойства и follow-up вопросы. Если приложение попадает в готовую схему — сообщения, контакты, медиа, события и т.п. — лучше использовать ее, а не изобретать свой полусамодельный смысловой слой. Где пока мутно Самый неприятный вопрос: что делать приложениям, чьи данные не ложатся в заранее заданные App Schemas? В статье честно отмечено, что это пока не до конца понятно. @Property(indexingKey:), IntentValueQuery, IntentValueRepresentation и прочие приятные механики сильнее всего раскрываются там, где система уже знает тип данных. Мой вывод: для iOS 27 подготовка к Siri — это не «добавить AI-фичу». Это привести модель данных к виду, в котором система может ее понять: AppEntity, IndexedEntity, схемы, экранный контекст и экспорт через Transferable. Начинать стоит с одного-двух ключевых пользовательских сценариев, где фраза вида "Siri, что я недавно делал в этом приложении?" реально имеет смысл. После подготовки, это все обложить аналитикой и следить какие сценарии пользуются спросом и добавить их в регресс вашего приложения

📦 Swift Package Index присоединился к Apple Отличная новость для всего swift сообщества! Это не просто сайт, где удобно искать Swift-пакеты. SPI давно стал нормальным рабочим фильтром перед тем, как тащить зависимость в проект: посмотреть совместимость с платформами, версии Swift, документацию, активность, состояние пакета и вообще понять, живое это что-то или археология с красивым README. И теперь Apple забирает эту часть экосистемы ближе к себе. В официальном посте аккуратно говорят: для разработчиков и авторов пакетов прямо сейчас ничего не меняется. Пакеты индексируются как раньше, документация хостится как раньше, проект остаётся open source, а инженеры Apple будут участвовать в развитии вместе с комьюнити. Самая интересная часть — в том, что они прямо называют будущие направления: discovery, security, reliability, package signing и identity. То есть Swift Package Index постепенно может стать не просто поиском по пакетам, а более официальным слоем доверия вокруг Swift-зависимостей. Если вы не использовали SPI до этого но используете swift package, самое время проверить: 🟢какие SPM-зависимости у вас живут в проектах 🟢есть ли у них нормальная поддержка актуальных Swift/iOS/macOS версий 🟢есть ли DocC или хотя бы внятная документация 🟢кто автор, как часто выходят релизы, реагируют ли на issues 🟢насколько критична зависимость для production-кода 🟢сможете ли вы быстро заменить её, если пакет заброшен или сломается на новом SDK. SPI уже сейчас помогает отвечать на эти вопросы. А если Apple дальше добавит identity/signing, такие проверки могут стать частью нормального инженерного процесса.

👨🏻‍💻 Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса. Хороший интерфейс получается там, где есть хороший промпт. Точность на входе = качество на выходе. 🗓 На открытом вебинаре 2 июля в 20:00 МСК: ➡️ Разберем, как формулировать задачи для Lovable, чтобы получать предсказуемый результат с первой попытки. ➡️ Поговорим о структуре системного промпта, ключевых словах, которые помогают превратить текст в качественный интерфейс. ➡️ Рассмотрим способы доработки результата через встроенный редактор и повторные запросы. ➡️ Обсудим, как управлять компонентами, просить нейросеть переиспользовать элементы и сохранять единый визуальный стиль. Бесплатный вебинар курса «Вайб-кодинг: создание цифровых продуктов с ИИ» 🔗 Записаться: по ссылке Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

📳 SensoryFeedback в SwiftUI: маленький параметр, который мог раздуть cache Иногда самые интересные изменения SwiftUI выглядят вообще не как новая фича. Вот пример: SensoryFeedback.impact(..., intensity:). Снаружи всё выглядит безобидно: есть тип haptic feedback, есть intensity, можно подвязать его к слайдеру, прогрессу или жесту и менять силу отклика. Но в старой реализации SwiftUI была неприятная деталь: intensity жил прямо внутри FeedbackType. А этот FeedbackType использовался как ключ для cache UIFeedbackGenerator. То есть для кода вроде такого:

Slider(value: $intensity, in: 0...1)

Button("Trigger") {
    trigger.toggle()
}
.sensoryFeedback(
    .impact(weight: .medium, intensity: intensity),
    trigger: trigger
)

SwiftUI мог видеть не один и тот же feedback с разной силой, а много разных ключей:

.impactWeight(.medium, 0.10)
.impactWeight(.medium, 0.11)
.impactWeight(.medium, 0.12)

Для UIKit это странно. Генератор здесь один и тот же:

let generator = UIImpactFeedbackGenerator(style: .medium)
generator.impactOccurred(intensity: intensity)

style определяет, какой генератор нужен. intensity определяет, как сыграть конкретное срабатывание. Это разные уровни жизни значения. Одно должно быть cache identity, другое — runtime payload. Что поменялось в iOS 27: Apple, судя по dump’ам SwiftUI, поправила именно модель:

struct SensoryFeedback {
    var type: SensoryFeedback.FeedbackType
    var payload: SensoryFeedback.Payload
}

Теперь стабильная часть feedback лежит в FeedbackType, а intensity вынесен в Payload:

enum Payload {
    case intensity(Double)
    case empty
}

Это правильнее архитектурно: cache больше не должен раздуваться из-за произвольного Double, который меняется во время drag gesture или slider interaction. Если вы поддерживаете iOS 17–26, это значит что не нужно передавать в intensity бесконечно плавные значения напрямую из жеста или слайдера, лучше хотя бы квантовать:

let quantizedIntensity = (intensity * 10).rounded() / 10

Button("Trigger") {
    trigger.toggle()
}
.sensoryFeedback(
    .impact(weight: .medium, intensity: quantizedIntensity),
    trigger: trigger
)

Или ещё лучше — триггерить haptic feedback только на смысловых порогах: смена состояния, snap point, достижение лимита, успешное действие, ошибка.

📱 SwiftUI после WWDC26: Apple постепенно убирает старые костыли Кажется, одно из самых практичных изменений в SwiftUI WWDC26 — не Liquid Glass и не очередной визуальный эффект, а то, что Apple наконец начала развязывать поведение, которое годами было прибито к List. Раньше хочешь нормальные swipe actions — бери List Хочешь reorder — снова думай через List, EditMode, drag/drop или кастомную механику Хочешь кастомный layout, но с системными жестами — готовься к компромиссам Теперь SwiftUI двигается в более взрослую сторону: контейнеры становятся не магическими списками со спецвозможностями, а обычными строительными блоками, к которым можно добавлять нужное поведение. Например, swipe actions теперь можно использовать не только в List, но и в ScrollView, lazy stacks и даже кастомных layout’ах:

ScrollView {
    LazyVStack {
        ForEach(items) { item in
            ItemRow(item)
                .swipeActions {
                    Button("Delete", role: .destructive) {
                        delete(item)
                    }
                }
        }
    }
}
.swipeActionsContainer()

Это маленькая строчка .swipeActionsContainer(), но смысл большой: больше не нужно выбирать List только потому, что тебе нужны системные свайпы. Что стоит проверить в своих проектах: 🟢Экраны, где List используется только ради swipe actions 🟢кастомные списки на ScrollView + LazyVStack, где свайпы были самописными 🟢reorder-логику, которую теперь можно заменить на reorderContainer и .reorderable() 🟢toolbar’ы, где на компактных экранах кнопки сейчас ведут себя непредсказуемо 🟢AsyncImage, если раньше приходилось городить отдельный слой кэширования Пример с reorder теперь тоже выглядит сильно чище:

struct ContentView: View {
    @State private var landmarks: [Landmark] = []

    var body: some View {
        VStack {
            ForEach(landmarks) { landmark in
                LandmarkView(landmark)
                    .reorderable()
            }
        }
        .reorderContainer(for: Landmark.self) { difference in
            difference.apply(to: &landmarks)
        }
    }
}

Постепенно можно удалять локальные костыли там, где SwiftUI теперь даёт системное поведение из коробки. Особенно интересно это выглядит на фоне resizable iPhone-приложений на iPad и более гибких оконных сценариев. Чем меньше экран завязан на конкретный контейнер вроде List, тем проще адаптировать UI под реальное доступное пространство, а не под старые эвристики

🎯 Foundation Models в iOS 27: Apple превращает локальный LLM в нормальную AI-платформу Сделал большой обзор основной темы этого года - Foundation Models. Если в прошлом году Foundation Models выглядел как аккуратный способ позвать системную on-device модель из Swift, то в iOS 27 Apple явно расширяет ставку. Теперь это уже не просто локальный LLM для подсказок в приложении, это слой, через который приложение может работать с разными моделями, разными источниками контекста и разными режимами выполнения — локально, через Private Cloud Compute или даже через сторонних провайдеров. 🟢Новая on-device модель Apple говорит, что модель стала сильнее в логике и tool calling. Плюс появились API для context size и token counting — то есть приложение может адаптироваться под конкретное устройство, а не молиться, что prompt влезет. 🟢Vision в Foundation Models Теперь в prompt можно передавать изображения: UIImage, CGImage, CIImage, pixel buffers, file URLs. Модель может отвечать по картинке, а размер изображения влияет на токены и latency. Наконец-то мультимодальность выглядит не как демо, а как API для реальных фич. 🟢Private Cloud Compute как модель внутри того же API Появляется PrivateCloudComputeLanguageModel: больше контекст, reasoning, более тяжёлые задачи. Для разработчика это выглядит почти как обычная LanguageModelSession, но модель уже не локальная. 🤩 Важная деталь: Apple обещает отсутствие API keys, отдельной авторизации и cloud API costs для разработчиков с менее чем 2 млн first-time downloads. Звучит очень по-Apple: меньше DevOps, больше платформенной магии. 🟢Единый LanguageModel protocol Вот это, возможно, главный сдвиг. SystemLanguageModel, PrivateCloudComputeLanguageModel, Core AI, MLX и сторонние модели могут жить за общей абстракцией. То есть downstream-код приложения может не знать, кто именно отвечает: локальная Apple-модель, PCC, Anthropic, Google или свой серверный backend. 🟢System tools: Vision и Spotlight Apple добавляет встроенные инструменты вроде OCR, barcode reader и Spotlight-powered поиск. Последнее особенно важно: локальный RAG поверх Spotlight index — это прямой путь к AI-фичам, которые работают с персональным или доменным контекстом без отправки всего подряд наружу. 🟢Dynamic Profiles для agentic apps Вместо ручного пересоздания сессий можно декларативно описывать режимы: например, один профиль анализирует картинку локальной моделью, другой переключается на PCC с reasoning для генерации идей. Это уже не просто чатик в приложении. Это примитив для маленьких агентов внутри приложения. 🟢Evaluations framework Apple наконец признаёт неприятную правду: LLM-фичи недетерминированы, поэтому их надо не только попробовать руками, а измерять. Новый Evaluations framework нужен, чтобы проверять качество prompt/tool/model изменений статистически, а не на ощущениях после трёх запусков. По сути это тесты для AI iOS 27 делает Foundation Models серьёзнее. Если вы уже думали, как добавить AI в приложение, этот доклад стоит смотреть одним из первых. Не ради хайпа, а чтобы правильно выбрать границы: что держать на устройстве, что отдавать в PCC, а что вообще не стоит строить на LLM.

📱 SwiftUI navigation transitions в iOS 27 В iOS 27 SwiftUI получил маленькое, но очень практичное обновление для навигационных анимаций. До этого NavigationTransition уже позволял управлять переходами в NavigationStack, sheets и full-screen covers, но встроенных вариантов было мало: по сути .automatic и .zoom(sourceID:in:). Теперь появилось две полезные вещи: 🟢 .crossFade Новый transition для случаев, где у экрана нет нормального visual source. zoom хорошо работает, когда пользователь тапнул карточку, картинку или ячейку. Но если экран открылся из deep link, notification, App Intent или программного состояния, zoom часто выглядит натянуто. crossFade даёт спокойный fade-переход без необходимости придумывать искусственный source.

.sheet(isPresented: $showInfo) {
    LandmarkInfo()
        .presentationDetents([.medium])
        .navigationTransition(.crossFade)
}

🟢AnyNavigationTransition Вторая новинка позволяет выбирать transition динамически. Один и тот же экран может открываться по-разному: 🟡из tap по карточке — .zoom(...) 🟡из уведомления или deep link — .crossFade / .automatic Раньше это упиралось в то, что .navigationTransition(_:) ждёт один конкретный тип. Теперь можно завернуть transition в AnyNavigationTransition и передавать его как значение. Навигация в iOS-приложениях давно не только про тапнул в списке → открыл экран. Есть widgets, notifications, Spotlight, App Intents, Siri, universal links. Разные входы в один экран должны ощущаться по-разному. Кастомные NavigationTransition всё ещё не поддерживаются, но iOS 27 уже убирает часть странных компромиссов в SwiftUI-анимациях 🥂

▶️ Что нового в Swift Сессии по Swift традиционно не являются сюрпризом для тех кто следит за развитием языка в опенсорс. На сессии нам показали вектор - Apple двигает Swift сразу в двух направлениях: 1. Убрать мелкую боль из обычного app-кода 2. предоставить безопасные инструменты там, где раньше приходилось уходить в unsafe, C-style трюки или ручную дисциплину Swift 6.4 убирает часть странностей: 🔵any P? и some P? теперь можно писать без лишних скобок 🔵async-вызовы разрешены внутри defer 🔵компилятор лучше предупреждает, если Task молча теряет thrown error 🔵weak let помогает с Sendable-классами 🔵~Sendable позволяет явно сказать: этот тип не должен быть Sendable 🔵После выравнивания версий Apple OS новая availability-платформа выглядит очень логично:

@available(anyAppleOS 27, *)

@diagnose даёт более взрослую модель управления предупреждениями компилятора: 🔵временно подавить deprecated warning в одном месте 🔵включить strict memory safety для чувствительного участка 🔵превратить future Swift errors в ошибки уже сейчас Улучшения внутри стандартной библиотеке: 🔵withTaskCancellationShield - короткая зона, где cancellation checks возвращают false 🔵mapKeyedValues - mapValues, но mapping closure получает и key, и value 🔵новый FilePath в standard library - более правильная работа с путями между платформами Swift Testing: миграция становится менее драматичной 🔵severity для Issue.record 🔵динамическая отмена тестов через Test.cancel 🔵repeat-режимы для флакающих тестов в swift test 🔵XCTest assertions теперь могут репортиться как Swift Testing issues 🔵#expect можно использовать из XCTestCase Большой блок сессии посвящён не iOS-экранам, а interop и portability: 🔵@C позволяет экспортировать Swift-функции обратно в C 🔵Swift/C++ interop лучше работает со span 🔵Swift-Java поддерживает async/throwing Swift functions из Java 🔵Появился официальный Swift SDK for Android 🔵Swift компилируется в WebAssembly 🔵JavaScriptKit стал безопаснее и быстрее 🔵Embedded Swift расширяет поддерживаемый subset языка Пример Goodnotes из сессии здесь очень показательный: существующий Swift-код можно компилировать в Wasm для web-интерфейса, не переписывая core logic на другой язык. Самый недооценённый кусок сессии - ownership и performance tuning: 🔵@inline(always) - принудительный inline, когда вы измерили пользу 🔵@specialized - специализация generic-функций под важные конкретные типы 🔵новый Iterable 🔵borrow / mutate accessors - computed property без лишнего копирования 🔵UniqueBox, UniqueArray, Ref, MutableRef — стандартные безопасные версии паттернов, где раньше легко было скатиться в unsafe Важно что Apple не предлагает писать весь app-код как low-level библиотеку. Обычный Swift должен оставаться обычным Swift. Что стоит проверить в вашем swift-проекте: 🟢заменить длинные availability-аннотации на anyAppleOS 🟢пересмотреть локально подавленные warnings и часть из них оформить через @diagnose 🟢найти Task { try ... }, где ошибка могла теряться 🟢проверить старые concurrency-компромиссы вокруг Sendable, weak, defer 🟢в тестах начать смешанную миграцию Swift Testing + XCTest, а не ждать идеального момента 🟢в флакающих тестах попробовать repeat-режимы swift test 🟢в shared packages посмотреть на новый FilePath и mapKeyedValues 🟢в performance-коде измерить копирования, ARC и generic overhead перед использованием @inline(always), @specialized, Iterable, borrow/mutate

🔨 Xcode 27: Apple встраивает агента не в чат, а в весь цикл разработки В этом году вопроса "с чего бы начать просмотр сессий с WWDC" не стояло, начинаем с "Что нового в Xcode 27"! Главная мысль из сессии - агент становится частью IDE, а IDE частью цикла разработки приложения. От идеи и прототипа до локализации, тестов, Device Hub, production-метрик, Instruments и Xcode Cloud. Ide залезает как на этап Discovery по работе с гипотезами, так и на этап приемки, тестирования и поддержки. Ключевые изменения: 🟢Агенты живут прямо в редакторе 🟢Команда /plan позволяет сначала попросить агента собрать контекст и предложить план без изменений в коде 🟢Изменения, артефакты и скриншоты агента видны рядом, пока он работает с проектом 🟢Device Hub становится отдельным рабочим окном для симуляторов и физических устройств 🟢iPhone Mirroring в macOS 27 можно ресайзить, и Apple прямо говорит: проверяйте, как iPhone-приложение живёт в новых размерах окна 🟢Агент может подготовить проект к локализации: пройтись по строкам, создать String Catalog, перевести UI strings и использовать контекст проекта + специфические правила конкретного языка 🟢Organizer теперь не просто показывает что что-то сломалось, а пытается подсказать, что чинить 🟢Instruments получил Top Functions - быстрый способ увидеть, где приложение реально тратит время, особенно когда дорогая операция выполняется много раз Apple явно не стремится заменить разработчика агентом. Скорее наоборот: Xcode 27 подталкивает к роли, где разработчик задаёт рамки, ревьюит план, проверяет результат и принимает инженерные решения. Агент забирает на себя грязную рутину: подготовить локализацию, собрать контекст, предложить фикс, найти дорогую функцию, помочь провести регресс. Полезная мысль: если проект хаотичный, без тестов, без нормальных сценариев проверки и без метрик, агенту тоже будет не на что опереться. Xcode 27 делает AI-разработку практичной только там, где уже есть инженерная дисциплина. Подумайте о том как выглядит разработка в вашем продукте, есть ли у вас все этапы? Чем лучше проект описывает сам себя через тесты, локализации, метрики, логику сборки и пользовательские сценарии, тем эффективнее в нём будет агент

🎹 Platforms State of the Union: Apple собирает AI-стек для разработчиков Если keynote был про смотрите, у нас теперь AI, то Platforms State of the Union — про то, как Apple хочет встроить AI прямо в рабочий цикл разработки 🟢Foundation Models framework Новое поколение Apple Foundation Models доступно через расширенный framework. Пока приложение не популярное - для разработчика бесплатно 🟢On-device AI стал серьёзнее Модели на устройстве научились мультимодальности и работе с изображениями. Небольшие image-модели можно запускать прямо на телефоне 🟢Private Cloud Compute Подписчики iCloud+ получат расширенный доступ к серверным моделям через Private Cloud Compute 🟢Core AI Новый framework для запуска моделей на устройствах. Плюс RAG на основе данных из Spotlight 🟢Динамические профили Prompt + model + depth reasoning под разные задачи. По сути — имитация разных агентов внутри одного workflow 🟢App Intents + Siri Достаточно описать entity и intent-схемы. Пользователь говорит Siri свободной формой, а framework сам мапит запрос на возможности приложения 🟢Agentic Coding в Xcode Теперь это не просто "напиши мне код". Apple раскладывает процесс по стадиям: 🔵discovery — обсуждаем идею с агентом прямо в Xcode 🔵plan — агент создаёт Markdown-план, его можно править руками 🔵development — агент пишет код по согласованному плану 🔵verification — тесты, API, user flows на симуляторе, отчёт 🔵crashes — анализ prod crash, воспроизведение, описание и фикс 🟢Плагины Всё это работает через плагины. Часть написана инженерами Apple, но Apple явно ждёт, что разработчики будут добавлять свои 🟢Xcode стал практичнее MCP / Agent Client Protocol, интеграции с популярными агентами, кастомный toolbar, загрузка проектов до 30% быстрее, надёжнее debug и меньший размер 🟢DeviceHub Simulator заменили новым DeviceHub: в одном месте симуляторы со всеми настройками и физические девайсы 🟢Локализация в Xcode Перевод теперь можно делать прямо в IDE. Важно: Xcode смотрит не только на строки, но и на контекст, где они используются 🟢SwiftUI снова продают как будущее В том числе как путь для переписывания web-приложений через agentic coding. Появились .reorderContainer, swipe-действия для элементов контейнера и ощущение дежавю: примерно это же когда-то красиво продавали в UICollectionView 🟢SwiftUI performance @State сделали ленивым, AsyncImage получил кеширование. Это должно ускорить SwiftUI-приложения без доработок Из важного: 🟡Платформенный сдвиг Intel Mac — всё. Теперь только Apple Silicon 🟡iPhone Mirroring В iOS 27 можно менять размер iOS-приложения на Mac и iPad при использовании iPhone Mirroring

🎹 Keynote highlights WWDC26 получилась больше похожа на Google IO, все вокруг.. Для разработчиков главное начнётся на Platforms State of the Union. То что хоть немного меня зацепило: 🟢iOS 27. Поддерживает все модкли, начиная с iPhone 11, запуск приложений до 30% быстрее 🟢Детские аккаунты. Больше контроля: покупки, сайты, контакты, сообщения и лимиты по категориям контента 🟢Apple Intelligence. Главный акцент — приватность: on-device, Private Cloud Compute и внешние модели там, где нужно 🟢Siri AI. Отдельное приложение, больше контекста, Visual Intelligence и сценарии поверх приложений 🟢App Intents. Самый важный пункт для разработчиков: приложения должны стать понятными новой Siri 🟢Foundation Models. Apple + Gemini: гибридная AI-архитектура вместо попытки делать всё в одиночку 🟢Shortcuts. Вайбкодинг для автоматизаций: описываешь задачу, система собирает сценарий 🟢Xcode. Agentic coding со сторонними моделями: Codex, Claude и Gemini. Ждём деталей по тестам, правкам и границам доступа 🟢DeviceHub. Новое приложение для управления устройствами. Интересно, дадут ли API и intents 🟢Остальные платформы. iPadOS, macOS, watchOS, tvOS и visionOS тоже обновились, но главный разработческий разбор — после SDK и сессий Мой вывод такой - Keynote дал направление, а не ответы. Теперь смотреть Platforms State of the Union, Xcode, App Intents, AI API и первые developer betas 🍿

Чуть больше чем через час уже начнется трансляция WWDC26 Keynote! Давайте попробуем ввести немного интерактива в этот WWDC Keynote, делитесь в комментариями фото мест просмотра Keynote, мыслями что ждете от Apple в этом году, а в процессе ивента и после обсудим первые впечатления о новинках Apple. Вот так, например мы организовали офис в Воронеже под просмотр Keynote. Мои мысли уже в комментариях

🧑‍💻 WWDC26 Сегодня начинается WWDC26, полезные ссылки: 🍏 Трансляция на сайте Apple 🈸 Трансляция в приложении Apple Developer 🎞 Трансляция на YouTube 🎞 Get ready for WWDC26 — короткое видео Apple о том, как выжать максимум из недели 📅 Расписание WWDC26 🖼 WWDC26 wallpapers - новые обои для Mac, iPad и iPhone 🎧 WWDC26 Hello playlist - плейлист Apple Music для настроения 💬 Apple Developer Forums - место, где обычно быстро всплывают первые вопросы по новым SDK 📦 Downloads — сюда идем после анонсов за beta SDK, Xcode и сопутствующими инструментами Время UTC+3 / московская тайм-зона: 20:00 Apple Keynote 23:00 Platforms State of the Union Сессии и материалы будут доступны в Apple Developer, на сайте и на YouTube. Нас ждёт самая насыщенная неделя для iOS-разработчиков: новые SDK, Xcode, SwiftUI, Apple Intelligence и всё то, что завтра придётся аккуратно приносить в реальные проекты 🥂

🐥 Swift в браузере: кейс Goodnotes, который стоит прочитать iOS‑командам Иногда кроссплатформенность звучит как "давайте перепишем всё на что-нибудь универсальное и будем страдать одинаково везде". Кейс Goodnotes интереснее: команда взяла большой Swift-код iPad-приложения и вынесла его в web через WebAssembly, не превращая продукт в демо ради конференции. По цифрам там всё серьёзно: 2,2 млн строк Swift в web-версии, из них 1,47 млн строк общего кода. Общими оказались не кнопочки, а дорогая часть: движок рендера, модель документов, распознавание рукописного ввода, индексации, ViewModel-и. UI и платформенные интеграции остались разными. Если бизнес-логика, I/O и concurrency прибиты гвоздями к UIKit, GCD и конкретной платформе, то никакой WebAssembly, server-side Swift или будущий SDK вас красиво не спасёт. О чем я бы задумался: 🟢где доменная логика зависит от UIKit/SwiftUI/Foundation API без реальной причины 🟢есть ли абстракции для network, storage, analytics, feature flags и clock 🟢не спрятаны ли DispatchQueue, locks и callbacks внутри кода, который можно перевести на async/await 🟢нет ли предположений вроде Int всегда 64-bi» в форматах, индексах, offsets и persisted data Портируемость начинается не с платформы, а с границ Хороший маленький тест: можно ли прогнать core-логику в обычном Swift Package без симулятора и без UIApplication? Если нет, проблема обычно не в WebAssembly, а в архитектуре

protocol NotesAPI {
    func document(id: DocumentID) async throws -> Document
}

struct DocumentIndexService {
    let api: NotesAPI
    let clock: any Clock<Duration>

    func rebuild(id: DocumentID) async throws -> SearchIndex {
        let document = try await api.document(id: id)
        return SearchIndex(document: document)
    }
}

Этот код скучный, зато именно такая скука потом позволяет запускать тесты быстро, менять transport без переписывания core и аккуратно выносить части продукта в другие окружения. AI-generated code часто усиливает старые архитектурные привычки: если в проекте всё связано со всем, агент будет быстро генерировать ещё больше такого же кода

🧵 Swift в браузере: кейс Goodnotes, который стоит прочитать iOS‑командам Иногда кроссплатформенность звучит как «давайте перепишем всё на что-нибудь универсальное и будем страдать одинаково везде». Кейс Goodnotes интереснее: команда взяла большой Swift-код iPad-приложения и вынесла его в web через WebAssembly, не превращая продукт в демо ради конференции. По цифрам там всё серьёзно: 2,2 млн строк Swift в web-версии, из них 1,47 млн строк общего кода. Общими оказались не кнопочки, а дорогая часть: rendering engine, document model, распознавание рукописного ввода, indexing, view models. UI и платформенные интеграции остались разными. Для iOS-разработчика главный вывод не «срочно пишем сайт на Swift». Главный вывод: если бизнес-логика, I/O и concurrency прибиты гвоздями к UIKit, GCD и конкретной платформе, то никакой WebAssembly, server-side Swift или будущий SDK вас красиво не спасёт. Что я бы проверил в проекте: 🟢 где доменная логика зависит от UIKit/SwiftUI/Foundation API без реальной причины; 🟢 есть ли абстракции для network, storage, analytics, feature flags и clock; 🟢 не спрятаны ли DispatchQueue, locks и callbacks внутри кода, который можно перевести на async/await; 🟢 нет ли предположений вроде «Int всегда 64-bit» в форматах, индексах, offsets и persisted data. Портируемость начинается не с платформы, а с границ Хороший маленький тест: можно ли прогнать core-логику в обычном Swift Package без симулятора и без UIApplication? Если нет, проблема обычно не в WebAssembly, а в архитектуре.

protocol NotesAPI {
    func document(id: DocumentID) async throws -> Document
}

struct DocumentIndexService {
    let api: NotesAPI
    let clock: any Clock<Duration>

    func rebuild(id: DocumentID) async throws -> SearchIndex {
        let document = try await api.document(id: id)
        return SearchIndex(document: document)
    }
}

Этот код скучный, зато именно такая скука потом позволяет запускать тесты быстро, менять transport без переписывания core и аккуратно выносить части продукта в другие окружения. Это стало особенно актуально сейчас: 🟡 до WWDC26 остаётся меньше недели, и новые SDK почти наверняка снова поднимут вопрос границ между app code, tooling, AI-assisted workflows и платформенными API; 🟡 AI-generated code часто усиливает старые архитектурные привычки: если в проекте всё связано со всем, агент будет быстро генерировать ещё больше такого же кода. Я бы вынес отсюда практичный шаг на эту неделю: выбрать один важный сервис и попробовать собрать его как отдельный Swift Package с тестами. Не ради моды на кроссплатформенность, а ради более понятной, проверяемой и живучей iOS-кодовой базы.