iOS-разработка отличается от web и backend не только языком. Это другой ритм: длинные циклы App Store Review, жёсткие правила приватности, ограниченный доступ к системным API, и необходимость учитывать тактильную обратную связь, accessibility и фоновые режимы. В Schedars мы выработали воркфлоу, который позволяет выпускать iOS-приложения предсказуемо.

Контекст

Мы работаем с заказчиками в нишах health, fintech и lifestyle — там, где iOS-аудитория исторически активнее и платит больше. Это значит, что приложения часто завязаны на HealthKit, биометрию, локальные нотификации и интеграцию с Apple Pay. Каждая такая зависимость — отдельный слой проверок при ревью и отдельный сценарий деградации, если разрешение не выдано.

Подход

Базовый стек — SwiftUI с островами UIKit там, где это оправдано: камера, сложные жесты, кастомные коллекции. Мы используем Swift Concurrency (async/await, actors) для асинхронного кода, Swift Package Manager для модульности и Xcode Cloud либо GitHub Actions для CI. На уровне архитектуры — MV или TCA в зависимости от размера приложения. Маленькому продукту TCA добавит шума; большому — спасёт от хаоса.

Что мы делаем

  • SwiftUI как основной слой UI, UIKit-обёртки только когда необходимо
  • CoreHaptics для тактильной обратной связи в ключевых сценариях, без избыточности
  • HealthKit с честной обработкой отказа в разрешениях и graceful fallback
  • App Store Review checklist: privacy nutrition labels, App Tracking Transparency, демо-аккаунты
  • TestFlight bands: internal → external beta → production, минимум одна неделя на каждом
  • Crash reporting и performance metrics с первого билда, не после релиза

Чему научились

App Store Review — это не лотерея, а воспроизводимый процесс, если правильно подготовиться. Большинство отказов, которые мы видели, попадают в три категории: непрозрачное использование данных, неработающий демо-аккаунт и UI, который ломается на маленьких устройствах. Если устранить эти три класса заранее, вероятность одобрения с первого раза резко растёт. Второй урок — HealthKit и приватные API нельзя тестировать только на симуляторе; нужны реальные устройства и реальные сценарии разрешений.

Что дальше

Планируете iOS-приложение или хотите аудит существующего? Напишите через /contacts — обсудим архитектуру, риски ревью и реалистичный план релиза.