iOS Broadcast

🈸 StoreKit 2: как давать доступ к premium-фичам (и не сломать уровни подписки)
Не часто приходится работать с in-app-ми и это то место, в котором не хочется допускать ошибки. Тут и репутационные и финансовые риски. Особенно сложно работать с нескольими уровнями подписок: как только вы добавляете несколько тарифов (например, личный / семкйный + месяц / год), появляются типичные боли:
🔵Приложение не понимает “какой план активен”, когда есть overlap при апгрейде/даунгрейде
🔵UI не может честно показать “что сейчас” и “на что продлится”
🔵Транзакции прилетают повторно / entitlement “откатывается” после рестарта

Подход из статьи: “всегда выбираем самый высокий tier”
1) Группы подписок + уровни (Level of Service)
Apple использует “Subscription Level” (lower number = *higher tier*) для логики апгрейдов/даунгрейдов и того, какая подписка должна считаться активной
В примере:
🟢Family = level 1 (выше)
🟢Individual = level 2 (ниже)
🟢Monthly и Yearly одного тира должны иметь одинаковый level, чтобы это был тот же tier, другая периодичность.

2) Модель тиров в коде
Делаем enum PassStatus (notSubscribed / individual / family) и маппим productID → tier, чтобы интерпретировать статусы StoreKit

3) Вычисляем текущий доступ по status’ам
Фильтруем statuses до .subscribed и выбираем max tier (чтобы Family “перебивал” Individual при overlap)

4) Trust only verified
Только .verified транзакции считаем entitlement’ом. Если verification не прошёл — считаем “нет подписки”.

5) Обязательно finish + наблюдаем апдейты
🟢Каждую verified транзакцию нужно finish(), иначе StoreKit может принести её снова
🟢На старте проверяем Transaction.unfinished (после крэша/сети)
🟢Держим живым listener на Transaction.updates для мгновенного обновления UI

6) UI: SubscriptionStoreView + статус рядом
В статье используют SubscriptionStoreView(groupID:), а текущий tier и “renews to …” строят из renewalInfo.

Эмпирическое правило для подписок
🟢Entitlement = verified transaction + правильно настроенный tier
🟢Тарифы = данные (ASC/StoreKit config), код должен лишь корректно их интерпретировать
🟢UI всегда показывает “effective tier”, а не последний купленный productID

📱 SwiftUI: как комбинировать жесты без магии и багов
Немного базы в пятницу, статья про жесты в SwiftUI.

Кейс один экран — несколько интеракций
Как только на элементе появляются drag + rotate + long press + tap — SwiftUI быстро начинает угадывать, какой жест вы имели в виду и не всегда у него это выходит успешно:
🔵Случайные конфликты распознавания
🔵Съеденные жесты
🔵Неочевидное поведение (особенно на трекпаде)
Все это создает негативный UX

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

Три базовых композиции жестов в SwiftUI:

1️⃣In sequence — сначала один, потом второй
Кейс: long press → drag
Используем LongPressGesture(...).sequenced(before: DragGesture())
🔵сначала удержание (например 0.5s)
🔵если пользователь продолжает — начинается drag
Идея: @GestureState обновляется через .updating(), а drag-translation читаем в .onChanged() на втором этапе

2️⃣ Simultaneous — два жеста одновременно
Кейс: drag + rotate
DragGesture().simultaneously(with: RotateGesture())
🔵можно тащить и одновременно крутить (двумя пальцами)
🔵каждый жест обновляет своё состояние через .onChanged()

3️⃣ Exclusive — либо одно, либо другое
Кейс: tap vs long press
ExclusiveGesture(TapGesture(), LongPressGesture(minimumDuration: 1.0))
🔵сработает первый распознанный жест
🔵tap меняет цвет, long press — увеличивает scale

💡 Шпаргалка:
🔵Если жесты должны идти “как сценарий” → Sequence
🔵Если жесты независимы и должны работать параллельно → Simultaneous
🔵Если жесты конкурируют за одно и то же взаимодействие → Exclusive

🗞 Дайджест новостей для iOS разработчиков за январь
Небольшие но важные изменения к которым нужно подготовиться:
🔵iOS 26.3 beta 2. Apple выкатили beta версии 26.3, релиз совсем скоро, самое время прогнать тесты
🔵App Store комплаенс — важные дедлайны
🔴Age Rating: до 31 января 2026. Рейтинги приложений автоматически “пересчитали” под новую систему, но вам нужно ответить на обновлённые вопросы в App Store Connect до 31.01.2026, иначе можно словить блок при отправке апдейтов
🔴Техас: возраст, согласия, PermissionKit. С 1 января 2026 для новых Apple Accounts в Техасе включаются требования по age assurance и parental consent (до 18 лет) — Apple даёт API для получения возрастной категории.
🔴EU: новая модель условий и UX установки
🔴Корея Sign in with Apple: новое требование (с 1 января 2026). При регистрации/обновлении Services ID нужно указывать endpoint для server-to-server нотификаций
🔵Swift 6.2.3 вышел в декабре, а в январе уже доступны снапшоты ветки release/6.3. В 6.2 заметно прокачали “approachable concurrency” (включая режимы изоляции), добавили опции для более строгой memory safety, ускорили сборки проектов с макросами (prebuilt swift-syntax) и продолжают развивать экосистему библиотек/тестов

🔨 Creating reminder lists with EventKit (и зачем это вообще нужно)
Добавить напоминание в дефолтный список — легко.
Но как только у вас появляются кейсы типа Проекты / Контексты / Приоритеты, всё ломается:
🟣Пользователю некуда "складывать" задачи из вашего приложения
🟣Получается помойка в одном списке
🟣Вы теряете смысл интеграции с системными Reminders

Искушение: писать в default list и забыть
🔴 EventKit позволяет быстро сохранить EKReminder в defaultCalendarForNewReminders() — и кажется, что задача решена. Но это не UX, а технический костыль.

Рабочий подход: создавать свои списки (reminder lists) через EKCalendar
🟢В этом случае напоминания живут внутри календария для reminders (EKCalendar c entity .reminder)

Что делаем:
🔵Запрашиваем доступ к Reminders через requestFullAccessToReminders()
🔵Загружаем текущие списки: eventStore.calendars(for: .reminder)
🔵Создаём новый список: EKCalendar(for: .reminder, eventStore: ...), задаём title, подбираем source, сохраняем saveCalendar(..., commit: true)
🔵Добавляем напоминания в выбранный список через EKReminder, выставляя dueDateComponents и сохраняя eventStore.save(reminder, commit: true)
🔵Важно: не забыть ключ в Info.plist — Privacy - Reminders Full Access Usage Description.

Списки Reminders должны сохраняться в конкретное хранилище (локально / iCloud / CalDAV). Авторы предлагают приоритет:
🟢.local или .calDAV, иначе fallback на defaultCalendarForNewReminders()?.source
🟢Если вы добавляете Reminders “как интеграцию” — делайте списки, иначе это просто запись в чужой inbox.
🟢Если у фичи есть доменная структура (проекты/категории) — отражайте её системными списками.

🎯 Agent Skills: отказ от AGENTS.md в пользу переиспользуемых знаний для AI-агентов
Оказывается есть аналог глобального AGENTS.md для каждого проекта. Можно настроить общие подходы через скилы.

Skills заменяют AGENTS.md
🔵AGENTS.md — это единый файл с правилами/правилами для вашего AI-агента, но он обычно включает много проект-специфичной информации, которую трудно переиспользовать
🔵Agent Skills — это отдельные, тематические блоки знаний, хранимые в своих папках и которые можно подключать к разным проектам и инструментам

Skill — это каталог, содержащий:
🔵SKILL.md — файл с описанием навыка / инструкциями.
🔵references/ — дополнительные справочные материалы.
🔵scripts, assets — вспомогательные файлы, шаблоны и прочее

Skills позволяют разделять знания по темам, например:
➡️Swift Concurrency
➡️Testing Patterns
➡️SwiftUI Best Practices
➡️Refactoring Guidelines
и использовать их во всей своей экосистеме AI-инструментов

Автор создал Swift Concurrency Skill с модульной структурой:

swift-concurrency/
├── SKILL.md
└── references/
    ├ async-await-basics.md
    ├ actors.md
    ├ tasks.md
    ├ memory-management.md
    └ …

Это даёт агенту глубокий, структурированный контекст, когда он отвечает на вопросы или делает refactor/анализ кода

Преимущества подхода
🔵Повторное использование: навыки можно применять во многих проектах — больше не нужно копировать и править AGENTS.md в каждом
🔵Структурированность: навыки маленькие, тематические, легче поддерживаются
🔵Поддержка инструментов: многие инструменты (например Claude/Claude Code, Cursor) уже поддерживают стандарт Skills, а стандарт открыт
🔵Более качественные ответы: агенту легче выбирать и подгружать только нужные знания, чем держать весь контекст в одном AGENTS.md

Agent Skills эффективно превращают набор практик и знаний вашего стека в модульные, переиспользуемые блоки. Это даёт:
✅ меньше дублирования
✅ лёгкую поддержку и обновление знаний
✅ более точные ответы от AI-агентов

🎯 Privacy как бизнес-модель Apple
Google и Apple опубликовали совместное заявление, что само по себе редкость. Компании подчеркнули общее видение будущего цифровой экосистемы - AI с акцентом на безопасность, приватность и ответственность крупных платформ.
Факт - бизнес Apple не строится на продаже пользовательских данных

Именно поэтому Apple может:
🔵Выстраивать маркетинг вокруг privacy
🔵Делать privacy частью позиционирования платформы
🔵Использовать privacy как конкурентное преимущество

Для компаний, живущих за счёт рекламы и данных, такой подход просто недоступен.
На этом фоне совместное заявление Apple и Google выглядит не компромиссом, а расчётливым шагом:
📁 Apple не продаёт данные — Apple продаёт устройства, экосистему и доверие.
🧰 Google нуждается в сильном партнере для соперничества с OpenAI и Anthropic

Gemini — один из самых зрелых AI-стеков
🔵сильная работа с контекстом и мультимодальностью
🔵быстрый цикл улучшений и масштабируемость

И ключевое — Gemini легко встраивается как внешний сервис, без передачи контроля над платформой.

Apple делает то, что умеет лучше всего:
🔵чётко очерчивает границы доступа
🔵изолирует внешние модели от пользовательских данных
🔵оставляет UX и data-flow под своим контролем

Gemini здесь — инструмент, а не хозяин экосистемы.

Apple усиливает платформу, используя privacy как рычаг, а Gemini — один из немногих AI-партнёров, которого можно встроить, не ломая эту модель.
Верите в успех этого партнерства или расстроены тем что Apple признали свое отставание и сдались вендору в плоскости AI?

🔨 Stanford CS193p Лекция 6
Новая лекция из курса iOS Development with SwiftUI от Stanford University продолжает тему архитектуры приложений на SwiftUI — от базового разделения Model/View/ViewModel к более сложным паттернам устойчивости и масштабируемости. Лекция полностью состоит из демонстрации, на основе которой после лекции формируется домашнее задание.

Продвинутая архитектура SwiftUI-приложений:
🔵Управление состоянием на уровне всего приложения
🔵Организация логики и зависимостей через Observable, @MainActor, ViewModels
🔵Стратегии для больших проектов (модули, слои, separation of concerns)

Связь Model ↔️ ViewModel ↔️ View
🔵Обновление UI через реактивные свойства (@Published, Binding, @StateObject)
🔵Продвинутые паттерны: сценирование, flows, экраны со сложным состоянием

Работа с навигацией и состоянием
🔵Управление переходами в больших приложениях
🔵Сохранение состояния при смене экранов / вкладок

Домашнее задание:
Создать игру, похожую на CodeBreaker (которую создают в курсе), но с буквами английского алфавита вместо цветных меток, а также со следующими требованиями:
🟢Код и попытки должны быть словами на английском языке. Поэтому в игре используются все 26 букв алфавита как возможные «пины»
🟢UI должен показывать точные и неточные совпадения прямо на буквах (не через отдельные индикаторы)
🟢Кнопки должны быть расположены в виде QWERTY-клавиатуры, чтобы пользователь мог выбирать буквы
🟢Игра должна поддерживать перезапуск, выбор длины слова (от 3 до 6 букв), анимации из предыдущих лекций

#cs193p

🔨 Stanford CS193p Лекция 5
Первые дни новогодних праздников позади, а значит пора возвращаться к контенту. Что может быть лучше для начала года чем лекции Стенфорда. Пятая лекция сосредотачивается на архитектуре приложений, модели состояния и связке с UI — это следующий логичный шаг после первых четырёх лекций

🔵Глубокая архитектура приложения — как строить устойчивые, масштабируемые структуры, где Model, ViewModel и View чётко разделены.
🔵Связь модели и UI — через @StateObject, @ObservedObject, @Binding и реактивное обновление View.
🔵Swift Type System в архитектуре — как использовать enum, структуры и Optional для описания состояния приложения
🔵Обработка пользовательских событий — обновление модели, навигация, состояние побед/ошибок.
Все эти подходы помогают перейти от простого UI к полноценному приложению с бизнес-логикой, состояниями и тестируемой моделью

Почему это полезно?
🟡Если вы строите серьёзные приложения на SwiftUI, важно не только знать синтаксис, но уметь проектировать архитектуру
🟡Эта лекция показывает best practices по организации кода, которые работают и для небольших MVP, и для крупных приложений с десятками экранов
🟡Контент из Stanford — один из самых авторитетных источников входа в изучение SwiftUI и архитектуры iOS-приложений

#cs193p

🐥 Non-Sendable First Design — новый взгляд на Swift Concurrency
В Swift 6.2 появилась превью новой фичи, под флагом NonisolatedNonsendingByDefault. В комьюнити и форумах swift обсуждается идея, которая набирает отклик в Swift-сообществе: начинать проект с non-Sendable типов и добавлять Sendable / actor только там, где действительно нужна безопасность между потоками. Этот подход предлагает более простой путь к переходу на Swift Concurrency, чем повсеместное использование акторов и Sendable.

В чём суть Non-Sendable First Design:
🔵Sendable — это маркер безопасности для передачи между потоками/акторами, но далеко не все типы в приложении должны быть такими
🔵Идея Non-Sendable First Design заключается в том, чтобы изначально проектировать модели как non-Sendable, пока они не пересекают границы изоляции (то есть не должны быть переданы в Task, actor или другой изоляционный контекст)
🔵Это напоминает принцип «начинай с простого» — избегай лишних аннотаций @MainActor, @Sendable, акторов, пока код фактически не требует потокобезопасного обмена

Почему это может быть полезно:
🔵Меньше шума в коде на старте: не нужно помечать всё акторной изоляцией только из-за страхов компилятора
🔵Упрощение модели данных: простые классы и структуры не обременены проверками Sendable, пока они используются в одном домене
🔵Добавление безопасности по потребности: когда код пересекает границы конкуренции (например, Task или Actor), можно локально добавить Sendable/actor именно туда, где это важно

📌 Статья от Apple
📌 Оригинальный пропоузал
📌 Обсуждение на reddit

🎯 Как заставить LLM генерировать код как вы, а не средний по интернету
Большинство разработчиков используют LLM (ChatGPT, Claude, Cursor) из коробки и получают рабочий, но недостаточно качественный код: он компилируется, но не соответствует архитектуре, стилю и практикам, которые вы используете в своем проекте. Это особенно заметно в Swift, так как в тренировочных данных таких примеров меньше, чем, скажем, JavaScript/Python. LLM обучены на статистике текста — они средние по трендовым паттернам интернета, а не специфичным корпоративным/производственным стилям. Поэтому они генерируют код, который компилируется, но:
🔴не учитывает архитектуру вашего проекта
🔴игнорирует Dependency Injection и тестирование
🔴пропускает ваши правила именования и шаблоны

AGENTS.md Это “README для LLM” - высокоуровневое описание архитектуры, команд, workflow, договорённостей:
➡️ цели, ограничения, ожидаемое качество
➡️ структура репозитория
➡️ стиль кода
➡️ архитектурные шаблоны и тесты
➡️ команда/инструменты

Rule Files - Набор правил на уровне доменов:
➡️ Dependency Injection
➡️ SwiftUI архитектура
➡️ Стратегии тестирования
➡️ Стиль коммитов
➡️ Workflow и code patterns
Каждый файл содержит чёткие директивы и примеры кода, которые LLM подгружает только тогда, когда это нужно.

Что это даёт
🔵Код, который выглядит как ваш собственный код, а не среднестатистический
🔵Снижение рефакторинга после генерации
🔵Больше соблюдения правил архитектуры и тестов
🔵Поддержка нескольких AI-инструментов (Claude, ChatGPT, Cursor) на одной основе правил