🐥 Swift 6.3, C‑интероп, SwiftPM и Swift Testing
На Swift.org рассказали детали про Swift 6.3 с упором на C‑интероп, кроссплатформенную сборку и официальный Swift SDK для Android
🟢Проще и понятнее сделать мост между Swift и C/C++
🟢Сделали кроссплатформенную сборку через SwiftPM + новый Swift Build более предсказуемой

@c и module selectors: меньше боли на границе модулей
В языке появились атрибут @c и module selectors вроде ModuleA::foo()
🔵Можно экспортировать Swift‑функции и enum’ы в C‑хедеры и реализовывать C‑API на Swift (@c + @implementation)
🔵Удобное разрешение конфликтов имён между модулями (ModuleA::getValue() и ModuleB::getValue())
🔵Явный доступ к системным API через Swift::Task и др.

SwiftPM 6.3 и Swift Testing: tooling взрослеет
Swift Package Manager получил preview интеграции Swift Build и несколько практичных улучшений, а Swift Testing — новые возможности
🔵Более единый build‑движок на всех поддерживаемых платформах (через Swift Build preview)
🔵Удобную поддержку prebuilt Swift Syntax для shared macro‑библиотек и новую команду swift package show-traits
🔵В тестах — warning‑issues (Issue.record(..., severity: .warning)), отмену тестов (try Test.cancel()) и image attachments для визуальных сценариев

Если у вас есть C/Obj‑C‑код, которому нужно дернуть функцию, написанную на Swift, теперь это можно сделать без лишней магии:

@c(MyLibrary_doWork)
func doWork() {
  // Swift-реализация
}

🈸 Курс на глубокую интеграцию приложений в систему
Неочевидный фактор использования AI в разработке - не программисты начали массово клепать приложения в AppStore, это уже отражается на скоросте ревью приложений и конкуренции. Но я уверен что это только повысит потребность в опытных iOS разработчиках, которые могут довести приложение из MVP до настоящего продукта. На носу #WWDC26, и я ставлю на том что фокус сместится еще глубже в интеграцию приложений в систему через AppIntents:
🟢можно заранее закладывать в архитектуру приложения слой для App Intents и виджетов
🟢появляются новые кейсы для Shortcuts и автоматизаций на базе вашего продукта
🟢хорошо продуманные интенты становятся конкурентным преимуществом: пользователю проще вернуться в ваш сценарий

App Intents уже стали стандартом для интеграции с Shortcuts и Siri
В новых примерах и туториалах Apple опирается на AppIntents‑фреймворк как основной способ описывать действия приложения. Старые схемы с отдельными intent‑definition и кастомными интентами отодвигаются на второй план.
🔵Проще описывать действия приложения декларативно и использовать их в разных местах (Shortcuts, виджеты, Live Activities)
🔵Снижается связность между UI и «точками входа» в логику приложения
🔵Становится проще строить сценарии «поверх» вашего приложения без отдельного API

Виджеты и Live Activities всё сильнее завязаны на интенты
Новые примеры Apple показывают: виджеты и Live Activities всё чаще используют App Intents как единую точку входа. Основная идея — один интент описывает действие, а разные оболочки (виджет, Shortcut, Live Activity) решают, как его вызвать:
🔵Меньше дублирования логики между виджетами, Shortcut’ами и самим приложением
🔵Проще добавлять новые точки входа без переписывания бизнес‑логики
🔵Повышается устойчивость архитектуры к новым форматам системной интеграции

Сценарий: у вас есть приложение‑трекер (задачи, привычки, таймеры), и вы хотите дать пользователю быстрое действие из виджета или Shortcuts — например, отметить привычку выполненной, достаточно:

import AppIntents

struct CompleteHabitIntent: AppIntent {
  static var title: LocalizedStringResource = "Отметить привычку выполненной"
  static var description = IntentDescription("Помечает выбранную привычку как выполненную за сегодня.")

@Parameter(
  title: "Привычка",
  description: "Выберите привычку, которую хотите отметить."
)
var habit: HabitEntity

func perform() async throws -> some IntentResult {
  try HabitService.shared.complete(habit: habit)
  return .result(
    value: "Привычка \(habit.name) отмечена выполненной на сегодня."
  )
}

🧰 Swift 6.3 на Android
Swift давно кроссплатформенный: есть Linux, Windows, серверный Swift. Но для мобильщика вопрос всегда был простой: что с андроид? С недавних пор у этого вопроса появился более внятный ответ: Swift SDK for Android. После релиза Swift 6.3 версия стала стабильная и самое время для экспериментов, что есть сейчас:
🔵Сборки SDK, которые можно ставить в Android‑окружение
🔵Компиляция Swift‑кода под Android
🔵Линковка с Android‑библиотеками
🔵Сборка JNI‑совместимые артефакты

Это не рандомный GitHub‑проект энтузиаста, а часть официального Swift‑экосистемного усилия, в одном ряду с Linux/Windows поддержкой. Пока ключевая идея: дать возможность переиспользовать Swift код на Android. Часто MVP приложение разрабатывают под iOS и уже после стартуют Android проект. Получается что уже есть богатый доменный слой на Swift, core‑логика, алгоритмы, валидация, форматирование и это все переписывается заново. iOS и Android‑команды постоянно синхронизируют бизнес‑правила, дублируют логику, ловят рассинхроны и баги.
Идея не новая, уже есть KMP/Flutter/React Native и каждый из них решал ту же проблему, но не стал популярным. Kotlin Multiplatform находится в гораздо более зрелом состоянии на сегодня. На что же надежда? Пока нет готовых production‑кейсов, GUI‑стека и инструментов уровня Xcode/Android Studio, заточенных под такой гибрид, я не ожидаю популяризации. Особенно с учетом роста популяризации переписывания готового приложения при помощи AI. Мне кажется что Claude и Codex возможно даже более значительные конкуренты для Swift для Android чем другие инструменты. Верите в Swift для Android?

🈸 Что творится с ревью в 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-продукты, но и длинный хвост персональных микроприложений, соло-проектов и нишевых утилит. Рынок становится жестче: новых приложений больше, внимание пользователя — нет

🕸Минцифры попросило крупнейшие в России цифровые площадки помочь с блокировкой 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 не дает информации о деталях пути.