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