Адаптация мобильного приложения под новые возможности ОС

Ваше приложение работает без сбоев, но пользователи всё чаще замечают, что оно не использует новые возможности ОС. Последние версии iOS предлагают Dynamic Island, интерактивные виджеты, Live Activities — конкуренты уже внедряют эти фичи, а ваше приложение остаётся в стороне. Это сказывается на метриках: retention падает на 15–20% в месяц после выхода крупного обновления платформы. Мы поможем это исправить без потери обратной совместимости. Мы адаптировали более 30 приложений под новые версии iOS и iPadOS, включая фичи Dynamic Island, Live Activities, виджеты и Stage Manager. Наш опыт позволяет внедрять фичи быстро и надёжно.

Какие новые фичи ОС стоит внедрять в первую очередь?

Выбор фичи зависит от специфики приложения. Но есть универсальные: Lock Screen виджеты для быстрого доступа к данным, Live Activities для отслеживания событий в реальном времени, Interactive Widgets для выполнения действий без открытия приложения, а для iPad — поддержка Stage Manager для комфортной работы в многозадачном режиме. По нашим данным, внедрение Live Activities увеличивает вовлечённость в 2.5 раза по сравнению с обычными уведомлениями.

Lock Screen Widgets и Live Activities

Lock Screen Widgets — виджеты на экране блокировки. Используют WidgetKit с семействами .accessoryCircular, .accessoryRectangular, .accessoryInline. Просто перенести Home Screen виджет недостаточно — нужна явная поддержка этих семейств.

struct LockScreenWidgetView: View {
    @Environment(\.widgetFamily) var family
    var body: some View {
        switch family {
        case .accessoryCircular:
            Gauge(value: progress, in: 0...1) {
                Image(systemName: "star")
            }
            .gaugeStyle(.accessoryCircular)
        case .accessoryRectangular:
            VStack(alignment: .leading) {
                Text(title).font(.headline)
                Text(subtitle).font(.caption)
            }
        default: EmptyView()
        }
    }
}

Цветовая схема виджета настраивается через .widgetAccentable() — без этого модификатора виджет выглядит стандартно, не подхватывая пользовательский акцент.

Live Activities (ActivityKit) — динамические плашки на Lock Screen и в Dynamic Island. Обновляются через push-уведомления (ActivityKit push) или напрямую из приложения. Типичный сценарий: доставка, такси, спортивный матч.

// Запуск Activity
let attributes = DeliveryAttributes(orderId: "12345")
let state = DeliveryAttributes.ContentState(status: .preparing, eta: Date().addingTimeInterval(1800))
let activity = try Activity.request(
    attributes: attributes,
    content: .init(state: state, staleDate: nil),
    pushType: .token
)

Ключевой момент — pushType: .token. Сервер получает push token и обновляет активность через APNs без пробуждения приложения. Без серверной части Live Activities не работают.

Interactive Widgets и TipKit для новых версий

С актуальной версии iOS виджеты стали интерактивными: Button и Toggle выполняют AppIntent прямо из виджета, а не просто открывают приложение.

struct QuickActionWidget: Widget {
    var body: some WidgetConfiguration {
        StaticConfiguration(kind: "QuickAction", provider: Provider()) { entry in
            QuickActionWidgetView(entry: entry)
                .containerBackground(.fill.tertiary, for: .widget)
        }
    }
}

struct QuickActionWidgetView: View {
    var entry: Entry
    var body: some View {
        Button(intent: ToggleTaskIntent(taskId: entry.taskId)) {
            Image(systemName: entry.isCompleted ? "checkmark.circle.fill" : "circle")
        }
    }
}

containerBackground — обязательный модификатор фона, иначе Xcode выдаёт предупреждение, а виджет может отображаться некорректно.

TipKit — фреймворк для обучающих подсказок. Позволяет показывать советы только тем пользователям, которые ещё не воспользовались функцией. Правила показа (#Rule) фильтруют по количеству донатов или времени. TipKit хранит состояние в iCloud и синхронизирует между устройствами — не нужно писать свою логику трекинга.

Как адаптировать приложение под iPadOS Stage Manager?

Stage Manager на iPad позволяет открывать окна произвольного размера. Приложение должно корректно работать при любом соотношении сторон, а не только при фиксированных размерах iPad.

// Проверка поддержки множественных окон
UIApplication.shared.supportsMultipleScenes // true на iPad с Stage Manager

UIWindowScene.sizeRestrictions задаёт минимальный и максимальный размер окна:

windowScene.sizeRestrictions?.minimumSize = CGSize(width: 400, height: 300)
windowScene.sizeRestrictions?.maximumSize = CGSize(width: 1200, height: 900)

Обязательны AutoLayout с правильными constraint priorities и UIContentSizeCategoryAdjusting для шрифтов. Жёстко заданные размеры (например, frame = CGRect(x:0, y:0, width:375, height:812)) гарантируют проблемы на Stage Manager.

Сравнение влияния на метрики

Наш процесс работы

• Аудит кода и дизайна: определяем, какие новые фичи релевантны вашему приложению и как они впишутся в текущую архитектуру.
• Приоритизация: выбираем 2–3 фичи, которые дадут максимальную пользу. Не раздуваем скоуп.
• Разработка: пишем код с @available и условными имплементациями для обратной совместимости.
• Тестирование: проверяем на реальных устройствах с последними версиями iOS и в симуляторах, включая сценарии с разными версиями ОС.
• Публикация: обновляем описание в App Store, готовим скриншоты с новыми фичами.
• Документация: описание изменений, инструкция по поддержке.

Мы выполнили адаптацию для более чем 30 приложений — от финансовых до фитнес-трекеров. Каждый проект сдаём в срок и с гарантией совместимости. За 5 лет работы мы накопили опыт, который позволяет избежать типичных ошибок при внедрении новых фич.

Ориентировочные сроки

Стоимость рассчитывается индивидуально после аудита. Для получения консультации и оценки проекта свяжитесь с нами. Закажите аудит вашего приложения — мы предложим оптимальный набор фич.

WidgetKit | ActivityKit

Почему нативная разработка iOS — лучший выбор для сложных приложений

Приложение крашит на cold start — EXC_BAD_ACCESS в момент инициализации синглтона, который обращается к другому синглтону, который ещё не инициализирован. Или: ViewController утечёт в памяти, потому что closure захватывает self без [weak self], и этот ViewController висит в памяти через два перехода после того, как пользователь его покинул. Это не гипотетические сценарии — это два самых частых класса проблем на iOS-проектах, которые приходят к нам после другой команды.

Мы занимаемся iOS-разработкой более 5 лет, реализовали 40+ проектов разной сложности — от стартапов до enterprise-решений с миллионами пользователей. Каждый проект проходит через 3 этапа Code Review, собственный набор UI-тестов (в среднем 150+ тест-кейсов) и обязательный прогон через Xcode Instruments до релиза.

Нативная iOS-разработка на Swift — это прямой доступ к платформе. Без прослойки, без компромиссов по производительности, с полным контролем над тем, что происходит на каждом кадре.

Почему нативная разработка iOS на Swift — выбор для enterprise-приложений?

Нативный код даёт гарантию совместимости с новыми API Apple в день их выхода, а не через месяцы адаптации в кроссплатформенных фреймворках. Для приложений с чувствительной к задержкам логикой (финансовые терминалы, медицинские мониторы, AR-навигация) это критично. Swift с ARC и строгой типизацией позволяет держать crash-free rate на уровне 99.9% при правильной архитектуре.

SwiftUI или UIKit: что выбрать для нативной разработки iOS

К настоящему времени SwiftUI покрывает подавляющее большинство production-задач. Но UIKit не устарел и не исчезнет — Apple не deprecate-ит его, а продолжает добавлять API. Реальная картина на крупных проектах: гибридный подход. SwiftUI для большинства экранов, UIKit там, где SwiftUI упирается в ограничения.

Какие сценарии SwiftUI выигрывает безоговорочно

Декларативный синтаксис SwiftUI сокращает код UI в 3–5 раз по сравнению с UIKit. Экран настроек с List, Toggle, Picker — это 40 строк SwiftUI против 200 строк UIKit с делегатами UITableViewDataSource. Экономия времени на UI-разработку достигает 60%[Apple рекомендует начинать новые проекты на SwiftUI (Human Interface Guidelines)]. При среднем бюджете проекта в 5 миллионов рублей экономия может составить до 3 миллионов рублей только на UI-слое.

@State, @Binding, @ObservableObject (а с iOS 17 — макрос @Observable) создают реактивную связь между данными и UI без ручного reloadData(). Измение @State-переменной автоматически перерисовывает затронутую часть иерархии. Это работает правильно, если понимать, как SwiftUI вычисляет diff — через Equatable и id в ForEach.

AsyncImage, NavigationStack с типобезопасным роутингом через NavigationPath, searchable, refreshable — это готовые паттерны, которые UIKit требует реализовывать вручную.

Когда UIKit остаётся необходимым

UICollectionView с compositional layout и diffable data source — сложные сетки с разными типами ячеек, горизонтальными секциями внутри вертикального скролла, динамическими размерами ячеек. SwiftUI LazyVGrid / LazyHGrid не дают такого контроля.

Кастомные переходы между экранами. UIViewControllerAnimatedTransitioning и UIViewControllerInteractiveTransitioning — интерактивный pop gesture с частичным прогрессом, кастомный hero-переход с точным управлением frame. SwiftUI matchedGeometryEffect покрывает часть случаев, но не все.

UITextView с TextKit 2. Богатый редактор текста, кастомные атрибуты, кастомный рендеринг — TextKit 2 (доступен с iOS 16) перешёл на async layout, что решило проблемы с производительностью на длинных документах. SwiftUI TextEditor — это обёртка вокруг UITextView без прямого доступа к TextKit.

UIScrollView с кастомным поведением. scrollViewDidScroll, parallax-эффекты, sticky headers с кастомной логикой, pull-to-refresh с кастомным индикатором. SwiftUI ScrollView с scrollPosition и onScrollGeometryChange (iOS 17) закрывает часть случаев, но не все.

Как мы интегрируем SwiftUI и UIKit: шаг за шагом

1. Идентифицируем экраны, где SwiftUI даёт максимальный выигрыш (списки, формы, настройки) — обычно 70-80% экранов.
2. Для критичных к производительности участков (сложные коллекции, кастомные анимации) оставляем UIKit.
3. Используем UIHostingController для встраивания SwiftUI-вью в UIKit navigation stack.
4. Для обратной совместимости оборачиваем UIKit-компоненты через UIViewRepresentable.
5. Coordinator pattern (UIKit) управляет навигацией на уровне флоу, экраны реализованы на SwiftUI.

Один паттерн, который мы используем на проектах: UIKit-координатор управляет навигацией, а сами экраны на SwiftUI. Координатор создаёт UIHostingController, передаёт ViewModel через инициализатор или @EnvironmentObject, управляет переходами. Это даёт чистое разделение: SwiftUI занимается UI, Coordinator — навигацией.

Как async/await и Combine работают вместе

До Swift 5.5 асинхронный код на iOS строился на Combine или callback-цепочках. С появлением async/await и Actor модель конкурентности стала частью языка. На новых проектах мы используем async/await как основной инструмент для сетевых вызовов и бизнес-логики, Combine — для реактивной привязки UI-состояния.

// Правильно — @MainActor гарантирует UI-обновления на main thread
@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false

    func loadUser(id: String) async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await userService.fetch(id: id)
        } catch {
            // handle error
        }
    }
}

Combine остаётся незаменимым для дебаунсинга ввода, объединения нескольких Publishers (CombineLatest, Zip) и функциональной обработки потока значений (map, flatMap, filter). На практике 80% проектов используют оба подхода, выбирая инструмент под задачу.

Архитектура iOS-приложения

MVVM — базовый паттерн. ViewModel содержит логику и @Published-состояние, SwiftUI View подписывается через @ObservedObject или @StateObject. Правило одно: View не знает об URLSession, CoreData, UserDefaults.

Clean Architecture добавляет слои Repository и UseCase. UserRepository абстрагирует источник данных (сеть vs кеш). FetchUserUseCase содержит бизнес-правило. UserViewModel вызывает UseCase и управляет UI-состоянием.

TCA (The Composable Architecture) — более строгий паттерн от Point-Free. State, Action, Reducer, Effect — всё явное, всё тестируемое, composable через Scope. Хорошо работает в больших командах (5+ iOS-разработчиков), где важна предсказуемость поведения.

Что входит в разработку iOS-приложения

Инструменты, без которых не обходится ни один релиз

Xcode Instruments. Time Profiler показывает, где CPU тратит время. Allocations — утечки памяти и excessive allocations. Leaks — объекты, которые не освобождаются. Перед каждым релизом — обязательный прогон.

Firebase Crashlytics. Crash-free rate, группировка по stack trace, breadcrumbs событий до крэша. Настраивается за 30 минут, даёт картину по всему парку устройств. В среднем crash-free rate на наших проектах — 99.8%.

Fastlane match. Управление сертификатами и provisioning profiles через зашифрованный git-репозиторий. Устраняет «у меня локально собирается, а на CI нет» раз и навсегда. Экономит до 4 часов на каждую сборку при ручном подписывании.

XCTest + XCUITest. Unit-тесты для ViewModel и UseCase, UI-тесты для критичных флоу (онбординг, оплата, авторизация). В среднем код покрыт на 75%.

Процесс и сроки

Стоимость рассчитывается индивидуально после анализа ТЗ и дизайна. Обычно первые 2 недели уходят на проектирование, после чего мы фиксируем сроки и бюджет. Средний бюджет на разработку среднего iOS-приложения — от 4 до 7 миллионов рублей в зависимости от сложности интеграций.

Закажите разработку под ключ — мы оценим ваш проект за 2 рабочих дня и предложим оптимальную архитектуру. Свяжитесь с нами, чтобы обсудить вашу задачу: гарантируем качество кода, соблюдение App Store Review Guidelines и опыт работы с проектами любого масштаба. Получите консультацию — мы поможем выбрать правильный стек и избежать типичных ошибок на старте.