🐥🧰 Первый взгляд на Swift SDK for Android
Давайте разберемся, что же нам представили. Swift продолжает выходить за пределы Apple-эко­системы: представлена Nightly Preview версии SDK для Android.
🔵SDK поставляется как часть инсталлятора для Windows или как отдельная загрузка для Linux / macOS.
🔵Опубликован Getting Started guide и пример-репозитории Swift for Android Examples, показывающие end-to-end workflow (Swift код на Android)
🔵Более 25 % пакетов в Swift Package Index уже сборочно поддерживают Android.
🔵В рамках SDK предусмотрена межъязыковая интероперабельность через проект swift‑java: библиотека + генератор биндингов Java ⬅️➡️ Swift.

Как это работает:
🟢SDK подключается к Android NDK / Gradle через toolchain Swift.
🟢Swift-модули компилируются в .so-библиотеки и вызываются из Java.
🟢UI-слой остаётся нативным — Compose / View.
🟢Предполагается использование стандартного Swift-компилятора, адаптированного для Android-платформы (через Android NDK и соответствующие архитектуры).
🟢SDK пока в preview/nightly статусе — то есть инструментальная цепочка и CI ещё на стадии активной доработки.
🟢Swift-пакеты, которые уже поддерживают Android-таргеты, можно переиспользовать без переписывания на Kotlin/Java — особенно слои бизнес-логики, модели данных, алгоритмы.
🟢UI-слой пока остаётся нативным на Android (Compose/View)
🟢Проект swift-java: автоматически генерируются биндинги, это значит: можно в существующем Android-проекте подключить Swift-модуль, либо начать приложение в Swift, но обращаться к Android API/библиотекам.
🟢Альтернатива Kotlin Multiplatform (KMP). В KMP логика пишется в Kotlin и используется на iOS; здесь — логика в Swift и используется на Android. Зависит от того, на каком ЯП логика уже написана

Текущие проблемы:
🔴SDK в превью: не рекомендуется для production-релизов — возможны баги, нестабильности, отсутствие обратной совместимости
🔴Интеграция SwiftUI с Android пока даже не анонсирована — основной фокус на логике.
🔴Инструменты, отладка, CI, работа с эмулятором Android
🔴Не все архитектуры/NDK-версии могут быть поддерживаются
🔴Форум полон описанием крашей и проблем в рантайме
🔴Хотя проект swift‑java генерирует, остаются нюансы: вызовы, управление памятью, поддержка наследования, интерфейсов (тред на реддит)

📱 Cветящийся, анимированный эффект обводки как в Apple Intelligence
Новый язык дизайна Apple - светящийся, анимированный эффект обводки для выделения форм и компонентов. Если вы захотите внедрить подобный эффект для индикации работы AI - можно взять готовое расширение SwiftUI и применить этот эффект.
🟢Можно применить как бекграунд или оверлей
🟢Гибкая кастомизация толщиты линий, блюра и анимаций
🟢Градиент автоматически генерирует рандомизированные по позициям цвета
🟢Поддерживает уменьшение движения accessibility настройку
🟢Работает со всеми фигурами (Circle, Capsule, RoundedRectangle, итд)

🔨iOS 26.1 Beta 4: новые возможности Liquid Glass и другие "особенности"

🟢Переключатель внутри Display & Brightness. В релизе iOS 26.1 Developer Beta 4 Apple впервые дала пользователям контроль над «стеклянным» интерфейсом Liquid Glass. В настройках дисплея, позволяющий выбрать два режима: Clear (прозрачный) и Tinted (более непрозрачный, с высоким контрастом). Для нас это означает, что интерфейсы должны корректно реагировать на оба режима и выглядеть гармонично при разной степени прозрачности.
🟢Новые языки Apple Intelligence (Русского нет). Китайский, датский, голландский, норвежский, португальский, шведский, турецкий, вьетнамский

Проблем, не много:
🔴Не работает ограничение allowCamera в MDM. Один из авторов форума сообщает, что параметр allowCamera=false, который предназначен для запрета доступа к камере на управляемых устройствах
🔴Сбой Broadcast Extension. Это полностью ломает функциональность потоковых приложений и любой другой программы, использующей Broadcast Extension (по сути работает только штатная запись экрана в Фото)

🗓iOS 26.1, по оценкам выйдет в первой половине ноября. Чем раньше вы начнёте тестирование, тем меньше сюрпризов будет после официального релиза.

Заметели какие-то особенности?

🔨Основные нововведения в Xcode 26.1 beta
🟢Исправления в Instruments. В бета‑версии устранена проблема, из‑за которой инструмент Processor Trace не позволял записывать трейсы на устройствах семейства iPhone 17
🟢Кэширование Swift Package Manager. Пакеты, загружаемые из реестра, теперь кэшируются локально с протуханием через час, что уменьшает количество сетевых запросов при сборке
🟢Улучшения Coding Assistant. Во второй бете улучшено потребление памяти Coding Assistant для проектов с большими git‑репозиториями
🟢Исправления симулятора. Команда simctl list devices --json снова корректно отображает все устройства, когда на машине установлены несколько рантаймов с одинаковыми идентификаторами

Известные проблемы
🔴Проблема запуска симуляторов. После обновления macOS до Sequoia 15.6 симуляторы могут не запускаться при первой сборке. Apple рекомендует выполнить команду xcrun simctl runtime dyld_shared_cache update --all перед запуском симулятора, чтобы завершить генерацию shared‑кэша dyld
🔴Coding Assistant: поиск текста. Инструмент поиска в файлах может возвращать неверные номера строк, что приводит к ошибкам при замене текста

🎹 Розыгрыш билета на Mobius Осень 2025. Для участия надо быть подписанным на @ios_broadcast и нажать "Участвую!"

Итоги розыгрыша - 06 ноября

🎉 Результаты розыгрыша:

🏆 Победитель:
1. Evgeniy (@Evgeniy_Shevtsov)

✔️Проверить результаты

📱 SwiftUI Canvas API — графика нового поколения для iOS
Продолжаем разбираться с нововведениями в SwiftUI, на этот раз доступными уже с iOS 15. Стандартные декларативные View не позволяют реализовать сложную графику или кастомные визуальные эффекты.
🔴До появления Canvas разработчикам приходилось переходить в UIKit/Metal или использовать сложные трюки с Path и Shape
🔴Высокопроизводительная графика, частицы, шейдеры — всё это было вне удобной области SwiftUI

Решение: использование Canvas API
🟢Canvas предоставляет GraphicsContext и позволяет рисовать сразу на уровне пикселей, линий, фигур — прямо внутри SwiftUI
🟢Поддержка GPU-шейдеров и эффектов, Canvas стал«самым важным графическим улучшением с момента Core Animation
🟢Отлично подходит для визуальных спецэффектов, кастомных макетов, игр, интерактивной графики — без ухода в UIKit/Metal

Canvas { context, size in
    context.fill(
        Path(ellipseIn: CGRect(origin: .zero, size: size)),
        with: .color(.green))
}

Canvas открывает новую эру для SwiftUI — графика, которую раньше надо было «обходить», теперь доступна в декларативном стиле. Если хотите сделать приложение с визуальной выразительностью — Canvas точно стоит попробовать!

🐥 Безопасные уведомления в Swift Concurrency: MainActorMessage и AsyncMessage
Стандартные уведомления через NotificationCenter не учитывают модель конкурентности и изоляцию акторов.
🔴Даже если вы подписываетесь на уведомление с очередью .main, компилятор может выдавать предупреждения при вызове методов, атрибутированных @MainActor.
🔴Уведомления часто передаются через notification.object as? Type, что небезопасно и не даёт строгой типизации.

Использование новых протоколов MainActorMessage и AsyncMessage, доступных с iOS 26+, которые обеспечивают безопасную передачу уведомлений в модели Swift Concurrency решает эту проблему
🟢MainActorMessage: уведомление чётко связано с глав­ным актором — наблюдатель вызывается на главном акторе.
🟢AsyncMessage: уведомление может быть опубликовано из любого изоляционного контекста (любой актор или не-актор), и наблюдатель получает его асинхронно.

Пример:

// ✅ 1. Определение уведомления:
struct RecentBuildsChangedMessage: NotificationCenter.AsyncMessage {
    typealias Subject = [RecentBuild]
    let recentBuilds: Subject
}
// ✅ 2. Отправка сообщения
let message = RecentBuildsChangedMessage(recentBuilds: builds)
NotificationCenter.default.post(message)
// ✅ 3. Подписка на сообщения
token = NotificationCenter.default.addObserver(of: [RecentBuild].self, for: .recentBuildsChanged) { message in
    self.handleNewRecentBuilds(message.recentBuilds)
}

➡️ Получаете: строгую типизацию, безопасность акторов, меньше бойлерплейта. Новые API дают гарантию изоляции и безопасного взаимодействия с актор-моделью. Если вы ещё используете старые методы — сейчас самое время обновиться.

🔨 Трекинг тренировок с HealthKit на iPhone без Apple Watch
HealthKit очень мощный фреймворк, который был не популярен среди разработчиков из-за ограниченности аудитории. Раньше приложением здоровья на iPhone можно было пользоваться очень ограниченно и пользы в интеграции с ним было мало. Все поменялось с выпуском iOS 26 и новых API. Теперь возможно реализовать полнофункциональное приложение для отслеживания тренировок на iPhone/iPad.

С iOS 26 теперь у нас есть:
🟢Возможность начать и завершить тренировочную сессию (HKWorkoutSession) на iPhone/iPad.
🟢В реальном времени отслеживать такие метрики, как пульс, сожжённые калории, дистанция.
🟢Сохранять данные тренировок в HealthKit, чтобы они были доступны другим приложениям.

Давайте разбираться!
🔵Тренировкой управляют четыре основных объекта: HKWorkoutConfiguration, HKWorkoutSession, HKLiveWorkoutBuilder, HKLiveWorkoutDataSource
🔵Создайте конфигурацию тренировки с типом активности и местоположением.
🔵Инициализируйте тренировку с помощью health store и установите делегата.
🔵Получите конструктор тренировок и подключите источник данных.
🔵Сохраните ссылки на сеанс и конструктор, подготовьте датчики и покажите обратный отсчет.
🔵Запишите время начала и начните сбор данных, обновите состояние до активного и запустите таймер.
🔵Сохраните данные о тренировке в HealthKit

Пример полной интеграции с API и создания интерфейса при помощи SwiftUI есть в статье.

🐥 Улучшенное автодополнение в Swift: новая ступень в развитии IDE
В рамках программы Google Summer of Code 2025 для проекта SourceKit-LSP реализовано значительное улучшение автодополнения и подсказок в IDE-средах, поддерживающих Swift.
🔵Раньше автодополнение показывало лишь краткое описание (первый абзац доккомментария) для элемента кода. Теперь поддерживается отображение полного документационного комментария прямо в списке предложений.
🔵Добавлена поддержка запроса signature help (подсказка сигнатуры функции/метода): отображаются все перегрузки и их описание.
🔵Эти улучшения применимы не только в Xcode: редакторы, поддерживающие LSP (например, Visual Studio Code, Neovim, IntelliJ IDEA) получают аналогичные преимущества.

Почему это важно для нас?
🟢Более богатые подсказки в коде значительно ускоряют процесс разработки: меньше «гугления», проще разобраться в API и перегрузках.
🟢Улучшает качество кода: с полной документацией и подсказками вы реже пропустите важную деталь метода или неверную перегрузку.
🟢Подходит для фреймворков, где много перегрузок, а документация длинная — например, SwiftUI, Combine, HealthKit
🟢Работает в редакторах, где ранее поддержка Swift была ограничена — расширяет выбор инструментов IDE для разработчика.

🐥 Усовершенствования Swift 6.3 для Embedded Swift
В версии Swift 6.3 идут значительные улучшения для Embedded Swift — версия Swift, оптимизированная под крайне ограниченные среды
Ключевые обновления:
🟢Метод description/debugDescription для Float, Double теперь доступен в библиотеке Embedded Swift
🟢Появились диагностические предупреждения (EmbeddedRestrictions), которые помогают выявлять конструкции языка, неподходящие для Embedded-режима (например, untyped throws, применение generic-функций к existential)
🟢Улучшена взаимосвязь с C: поддержка атрибута @c, улучшена терпимость к несоответствиям между C-подписью и Swift-объявлением
🟢Отладка: улучшена работа с LLDB — появилась поддержка чтения памяти с указанием типа, улучшенная трассировка исключений на armv7m
🟢Линковка: устранена типовая проблема с дублированием символов при использовании Embedded Swift библиотек через слабые (weak) определения; введён атрибут @export

Даже если вы разрабатываете исключительно под iOS, полезно знать о развитии языка: улучшенная C-совместимость, диагностика, отладка — всё это может пригодиться. Swift 6.3 продолжает расширять возможности встроенного (embedded) варианта языка — теперь он становится не просто экспериментом, а более полноценной средой для разработки лёгких и эффективных решений.

📱 MagnifyGesture в SwiftUI
Зумирование контента — привычное действие для пользователей. С помощью MagnifyGesture с iOS 17 в SwiftUI можно легко добавить такой жест к View:
🔴При использовании стандартных жестов зумирования возникают нюансы: нужно решить, будет ли увеличенное состояние "временным" (возврат к исходному после окончания жеста) или "сохраняемым" (пользователь может масштабировать и остаться на этом уровне)
🔴Без правильной настройки жеста и состояния пользовательский опыт будет непредсказуемым

Вариант 1: Временный зум
🟣Используйте @GestureState для хранения текущего коэффициента масштабирования:
🟣Примените .scaleEffect(magnification) к View и добавьте жест
🟣Итог: во время жеста View масштабируется, после окончания жеста возвращается к исходному состоянию.

  @GestureState private var magnification: CGFloat = 1

  .gesture(
    MagnifyGesture()
      .updating($magnification) { value, state, _ in
        state = value.magnification
      }
  )

Вариант 2: Сохраняемый зум
🟣Используйте два свойства:
🟣Применяйте .scaleEffect(totalMagnification * currentMagnification) и жест
🟣Итог: пользователь увеличивает View — и масштаб остаётся на этом уровне до следующего жеста.

  @State private var totalMagnification: CGFloat = 1.0
  @State private var currentMagnification: CGFloat = 1.0

  .gesture(
    MagnifyGesture()
      .onChanged { value in
        currentMagnification = value.magnification
      }
      .onEnded { value in
        totalMagnification *= value.magnification
        currentMagnification = 1.0
      }
  )

Что важно:
✅ Убедитесь, что целевые устройства поддерживают iOS 17+, чтобы использовать MagnifyGesture
✅ Решите заранее: нужен ли вам зум постоянный или временный — архитектура жеста зависит от этого
✅ При сохраняемом зуме обязательно работайте с двумя состояниями (текущим и накопленным), чтобы обеспечить плавный UX и корректные вычисления
✅ Проверьте интерфейс: масштабирование влияет на расположение, обрезку, может потребоваться дополнительная логика для предотвращения слишком малого или слишком большого масштаба
✅ Тестируйте на разных устройствах (iPhone, iPad), ориентациях и с разными контентами (изображения, списки, кастомные Views) — чтобы жест не конфликтовал с другими жестами (например, прокруткой)

Добавление зума через MagnifyGesture в SwiftUI — мощный инструмент для повышения интерактивности интерфейса. Главное — выбрать правильную стратегию и грамотно реализовать состояние.

📱 Когда GeometryReader не нужен
Использование GeometryReader для управления layout-разметкой может усложнить и сделать более тяжелой иерархию View. Часто, чтобы центрировать контент или задать максимальную ширину (например, для iPad), разработчики оборачивают всё в GeometryReader, вычисляют размеры — но это влияет на layout, вызывает лишние пересчёты, усложняет структуру. Правильным решением в этом кейсе является использование onGeometryChange + contentMargins (iOS 17+ с бекпортом до iOS 16)
🔵onGeometryChange даёт возможность реагировать на изменение геометрии контейнера — без необходимости оборачивать интерфейс в GeometryReader
🔵Вместе с contentMargins можно задавать отступы для scroll-контента, центрировать и ограничивать ширину — делая layout адаптивным и чистым

Практические плюсы для iOS разработчика:
🟢Более лёгкая и чистая иерархия View — без лишних вложений.
🟢Упрощённая адаптивная верстка: удобнее для iPad, разных размеров экранов, responsive-дизайна.
🟢Код легче поддерживать и читать — сокращается boilerplate, меньше хитростей.
🟢Можно контролировать layout декларативно, оставаясь в духе SwiftUI.

Что стоит проверить прямо сейчас:
✅ Проверьте части UI, где сейчас используете GeometryReader просто ради вычисления ширины/центрирования. Возможно, его можно заменить на onGeometryChange + contentMargins
✅ Для scrollable-экранов с ограниченной шириной (галереи, карточки, формы) — попробуйте contentMargins + ограничение max-width, чтобы красиво центрировать контент на широких экранах
✅ Если нужна реакция на изменение размеров контейнера — onGeometryChange позволяет элегантно отлавливать это и обновлять layout без лишней обёртки