Адаптація iPad-додатку під багатозадачність

Реалізація Split View, Slide Over та Stage Manager для iPad-додатку — наша спеціалізація з 2019 року. Це не лише технічні налаштування, але й повноцінна адаптація UX під багатозадачність. iPad-додаток не відображається в списку багатозадачності, а в режимі плаваючого вікна з'являються чорні смуги. Користувачі Magic Keyboard не можуть перемикати розділи з клавіатури. Це типові наслідки відсутності підтримки Multitasking. Ми адаптували понад 30 додатків для iPad — від фінансових дашбордів до графічних редакторів. Адаптація обходиться в 3–5 разів дешевше, ніж переписувати UI з нуля. Вартість визначається після аналізу, але базова підтримка стартує від 500$. Для типових проектів вартість повної адаптації становить 1500-2500$. Економія клієнтів — до 70% часу. Згідно з App Store Review Guidelines Section 4.2, додаток має коректно працювати у всіх підтримуваних режимах.

Типові проблеми без підтримки багатозадачності на iPad

iPadOS Multitasking включає три основні режими: Split View (два додатки поруч, кожен займає половину екрана), Slide Over (плаваюче вікно в компактному розмірі) та Stage Manager (вільно змінювані вікна починаючи з iPadOS 16). Щоб додаток підтримував хоча б один із них, необхідно відмовитися від UIRequiresFullScreen = YES у Info.plist та реалізувати гнучку верстку на AutoLayout. Інакше додаток буде відображатися з темними полями або взагалі не з'явиться в списку доступних для Split View.

Чому базова підтримка — лише половина справи

Навіть після включення UIApplicationSupportsMultipleScenes та видалення ключа UIRequiresFullScreen додаток може працювати некоректно. Головна причина — прив'язка до абсолютних розмірів екрана. На iPad з розміром екрана 11 або 12.9 дюймів у Split View вікно може мати ширину 375, 420 або 450 пунктів — жорсткі константи призводять до обрізання контенту.

Ми використовуємо Size Classes — системний механізм, який повідомляє, компактний чи регулярний розмір у вікна по горизонталі та вертикалі. Код, що перевіряє UIDevice.current.userInterfaceIdiom == .pad, зламається в компактному режимі. Правильний підхід — реагувати на traitCollection.horizontalSizeClass або @Environment(\.horizontalSizeClass) у SwiftUI.

Як ми реалізуємо адаптацію: типовий кейс

Нещодавно адаптували корпоративний додаток для управління задачами. Спочатку використовувався UISplitViewController у UIKit, але без підтримки Size Classes і Stage Manager. Користувачі скаржилися, що в Slide Over sidebar не ховався, а в Split View з іншою важкою програмою інтерфейс ламався.

Ми зробили:

• Замінили статичний UISplitViewController на динамічний з делегатом колапсу;
• Додали UIPointerInteraction для hover-ефектів на елементах;
• Реалізували Drag & Drop між колонками — UIDropInteraction для прийому файлів;
• Налаштували Keyboard Shortcuts через UIKeyCommand та UIMenuBuilder для Magic Keyboard.

Результат: додаток став з'являтися в списку Split View, зникли артефакти в Slide Over, час тестування скоротився — всі режими Multitasking відпрацьовують коректно.

Етапи повного циклу адаптації

1. Аудит поточного UI — перевірка Info.plist, SceneDelegate, AutoLayout на жорсткі розміри;
2. Проектування адаптивного layout — вибір між UISplitViewController (UIKit) та NavigationSplitView (SwiftUI);
3. Реалізація — впровадження Size Classes, підтримка колапсу, налаштування мінімальних ширин колонок (не нижче 280 pt);
4. Інтеграція багатозадачних можливостей — Drag & Drop, Pointer Interaction, Keyboard Shortcuts;
5. Тестування — на всіх режимах Multitasking, включаючи Stage Manager та всі орієнтації пристрою;
6. Документація — опис ключових рішень та інструкція з підтримки.

Порівняння UISplitViewController та NavigationSplitView

Для нових проектів на SwiftUI ми рекомендуємо NavigationSplitView — він автоматично адаптується і вимагає в 2 рази менше boilerplate-коду. Якщо проект на UIKit або потрібна підтримка iOS 14-15, залишається UISplitViewController. Детальніше про UISplitViewController в документації Apple. Таким чином, NavigationSplitView дозволяє отримати адаптацію в 2 рази швидше, ніж UISplitViewController.

Як адаптувати додаток для Split View без UIRequiresFullScreen?

Перший крок — видалити UIRequiresFullScreen = YES з Info.plist. Потім переконатися, що UIApplicationSupportsMultipleScenes не встановлений в NO. Після цього потрібно перевірити, що всі в'юхи коректно реагують на зміну size class. Типова помилка — жорстка ширина елементів. Використовуйте AutoLayout з відносними констрейнтами (leading/trailing) або SwiftUI-модифікатори .frame(minWidth:idealWidth:maxWidth:). Також важливо задати minimumPrimaryColumnWidth для UISplitViewController — не нижче 280 pt.

Які помилки допускають при адаптації?

• Ігнорування мінімальної ширини primary колонки. У UISplitViewController задайте minimumPrimaryColumnWidth не нижче 280 pt, інакше sidebar виглядатиме розчавленим.
• Відсутність presentsWithGesture. Без цього користувачі не зможуть сховати sidebar свайпом — очікувана поведінка на iPad.
• Забувають про Keyboard. На iPad Pro з Magic Keyboard відсутність UIKeyCommand та hover-ефектів знижує користувацький досвід. Додайте хоча б базові команди (⌘N, ⌘F).

Наші інженери мають понад 5 років досвіду роботи з адаптацією. Ми гарантуємо коректну роботу в режимах багатозадачності відповідно до App Store Review Guidelines. Отримайте консультацію з адаптації вже сьогодні. Замовте аудит вашого додатка, і ми надішлемо попередній план.

Коли чекати результатів: орієнтовні терміни

Терміни можуть варіюватися. Оцінимо ваш проект безкоштовно — напишіть, ми надішлемо попередній план.

Що входить в роботу

• Аудит Info.plist, SceneDelegate та AutoLayout-констрейнтів — виявляємо жорсткі прив'язки до розмірів.
• Адаптація UISplitViewController або NavigationSplitView під усі Size Classes.
• Реалізація підтримки Drag & Drop, Pointer Interaction та базових Keyboard Shortcuts.
• Тестування на 3+ iPad-пристроях: 11" (iPad Pro), 12.9" (iPad Pro), 10.9" (iPad Air).
• Перевірка у всіх режимах багатозадачності: розділення 50/50, 70/30, плаваюче вікно, Stage Manager.
• Документація архітектурних рішень та інструкція з підтримки багатозадачності в майбутньому.
• Технічна підтримка на 30 днів після здачі роботи.