App Extensions та системні інтеграції в мобільній розробці: що це, які типи та як працюють

App Extensions на iOS: віджети та розширення для обміну контентом

App Extensions на iOS з'явилися в iOS 8 і стали фундаментом для системних інтеграцій у мобільній розробці. Це окремі бінарники, упаковані разом з основним додатком, але запущені в ізольованому процесі. Кожне розширення має власний Info.plist та точку входу, задану через NSExtensionPrincipalClass. Система керує життєвим циклом App Extensions — вони не можуть залишатися у фоновому режимі після завершення завдання.

WidgetKit та Today Widget

WidgetKit (iOS 14+) — сучасний фреймворк для створення віджетів на домашньому екрані. WidgetKit використовує SwiftUI для опису інтерфейсу та TimelineProvider для визначення розкладу оновлень. Віджети бувають трьох розмірів: малий (2×2 комірки), середній (4×2) та великий (4×4). Старий Today Widget на UICollectionViewController підтримується, але Apple рекомендує мігрувати на WidgetKit. App Extensions на WidgetKit не підтримують анімацію, клавіатурне введення та жести — це статичні або псевдоанімовані елементи з періодичним оновленням.

Share Extension та Action Extension

Share Extension дозволяє надсилати контент з будь-якого додатка у ваш через системний лист «Поділитися». Share Extension отримує дані через NSExtensionItem та використовує SLComposeServiceViewController для UI. Action Extension обробляє контент на місці — наприклад, перекладає текст у браузері без переходу в інший додаток. Обидва типи повинні завершити роботу за обмежений час, інакше система «вбиває» розширення. Це важливе обмеження App Extensions у мобільному додатку — фонові завдання недоступні на рівні розширень.

CallKit, PushKit та SiriKit — системні інтеграції голосу та сповіщень

Системні інтеграції на iOS виходять далеко за рамки віджетів: CallKit, PushKit та SiriKit дозволяють мобільному додатку працювати на системному рівні. Ці фреймворки вимагають спеціальних entitlements, але дають користувачеві безшовний досвід — дзвінки через CallKit виглядають як звичайні телефонні, а Siri обробляє запити без відкриття додатка.

CallKit — VoIP-дзвінки в системному інтерфейсі

CallKit інтегрує дзвінки сторонніх додатків у системний екран виклику, включаючи заблокований екран. Провайдер CXProvider реєструє додаток як VoIP-сервіс, а CXCallController керує дзвінками. CallKit автоматично блокує дублюючі дзвінки та підтримує Call Directory Extension для блокування небажаних номерів. Системні інтеграції в мобільній розробці з CallKit критичні для додатків голосового зв'язку — WhatsApp, Skype та Zoom використовують його для відображення вхідних дзвінків.

PushKit — фонові push-сповіщення

PushKit доставляє push-сповіщення безпосередньо в мобільний додаток без показу користувачеві. PushKit пробуджує додаток з «убитого» стану та передає дані через делегат PKPushRegistryDelegate. Це основний механізм для VoIP-додатків: PushKit доставляє інформацію про дзвінок, а CallKit відображає її. PushKit має вищий пріоритет доставки, ніж звичайні push-сповіщення, і не потребує показу банера. App Extensions у мобільних додатках часто комбінують PushKit з CallKit для організації голосового зв'язку.

SiriKit та Intents Extension

SiriKit дозволяє обробляти запити через Siri та додаток «Команди». Intents Extension — окремий App Extension, який реєструє підтримувані інтенти та обробляє їх. SiriKit підтримує 20+ доменів: дзвінки, повідомлення, платежі, нотатки, тренування. Швидкі команди дозволяють користувачеві створювати автоматизації — наприклад, «Надіслати повідомлення в WhatsApp через Siri». Системні інтеграції з SiriKit та Швидкими командами підвищують залученість, оскільки користувач виконує дії без відкриття додатка.

BroadcastReceiver та системні сервіси на Android

BroadcastReceiver — компонент Android, який реагує на системні широкомовні повідомлення. На відміну від iOS App Extensions, BroadcastReceiver не потребує окремого бінарника — достатньо зареєструвати ресивер у маніфесті або в коді через Context.registerReceiver. Системні інтеграції на Android часто починаються з BroadcastReceiver: від запуску сервісу при завантаженні пристрою до реакції на підключення до мережі.

IntentFilter для системних подій

IntentFilter зв'язує BroadcastReceiver з конкретною системною подією. Типові події: BOOT_COMPLETED (завантаження пристрою), CONNECTIVITY_ACTION (зміна мережі), BATTERY_LOW (низький заряд), TIME_SET (зміна часу). Ресивер реєструється в AndroidManifest.xml або через Context.registerReceiver для динамічної реєстрації. Динамічна реєстрація краща — вона не потребує дозволів у маніфесті та діє тільки при активному додатку. App Extensions на Android не існують як концепція, але BroadcastReceiver виконує схожу роль — розширює можливості додатка за рахунок системних інтеграцій.

NotificationListenerService та AccessibilityService

NotificationListenerService — сервіс, який отримує всі сповіщення системи. NotificationListenerService потребує дозволу BIND_NOTIFICATION_LISTENER_SERVICE та доступу через налаштування спеціальних можливостей. AccessibilityService — потужніший інструмент для системної інтеграції: він може читати вміст екрана, симулювати натискання та автоматизувати дії. Обидва сервіси вимагають явного ввімкнення користувачем у налаштуваннях, що підвищує безпеку. Системні інтеграції в мобільному додатку через AccessibilityService використовуються для авто-філерів, читалок екрана та інструментів доступності.

class BootReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_BOOT_COMPLETED) {
            WorkManager.getInstance(context)
                .enqueueUniqueWork("post-boot", ...)
        }
    }
}

Приклад реєструє BroadcastReceiver для події BOOT_COMPLETED. WorkManager використовується для відкладеного виконання завдання після завантаження пристрою — це стандартний підхід для Android-додатків.

App Widget Provider — створення віджетів на Android

App Widget Provider на Android — аналог iOS App Extensions у контексті віджетів: це компонент, який відображає інтерактивний контент на домашньому екрані. На відміну від WidgetKit, Android-віджети можуть приймати введення користувача — натискання, перемикання та жести. App Widget Provider реєструється в маніфесті через XML-опис розміру та частоти оновлення.

RemoteViews та AppWidgetProvider

RemoteViews описує інтерфейс віджета через XML-розмітку та підтримує лише обмежений набір View. RemoteViews не дозволяє використовувати кастомні View — лише стандартні компоненти: TextView, ImageView, Button, ProgressBar. AppWidgetProvider — базовий клас, який обробляє оновлення, ввімкнення та видалення віджета. Метод onUpdate викликається за таймером через updatePeriodMillis або через WorkManager для точного контролю. Системні інтеграції з віджетами на Android вимагають обережності — занадто часте оновлення витрачає батарею.

Glance API (Jetpack) — сучасний підхід

Glance API — Jetpack-бібліотека для створення віджетів на Kotlin DSL замість XML. Glance API компілюється в RemoteViews та підтримує Compose-подібний синтаксис: GlanceComposable, Column, Row, Text. Бібліотека вирішує проблему складного XML-коду та дозволяє тестувати віджети через JUnit. Glance API поки не підтримує всі можливості RemoteViews — для складних інтерактивних віджетів краще використовувати класичний підхід. App Extensions у мобільній розробці на Android еволюціонують у бік Glance API, спрощуючи створення та підтримку віджетів.

Content Provider, FileProvider та обмін даними між додатками

Content Provider — компонент Android для обміну структурованими даними між додатками через єдиний інтерфейс ContentResolver. На відміну від iOS App Extensions, Content Provider не створює окремий процес — дані запитуються синхронно в контексті викликаючого додатка. Content Provider лежить в основі системних інтеграцій на Android: контакти, медіафайли, календар та стандартні додатки використовують його для публікації даних.

FileProvider для безпечного шарінгу файлів

FileProvider — підклас ContentProvider для безпечної передачі файлів між додатками. FileProvider генерує тимчасові content:// URI замість прямих file:// шляхів, які заборонені на Android 7+. Для використання потрібно вказати files-path або external-files-path у XML-конфігурації. App Extensions у мобільній розробці на Android не існують як окрема концепція, але FileProvider виконує їхню функцію — розширює можливості обміну даними за межі одного додатка.

Аналоги на iOS: File Provider Extension

На iOS роль обміну файлами виконує File Provider Extension. File Provider Extension публікує файли додатка в Files App через NSFileProviderManager. На відміну від FileProvider, iOS-розширення потребує окремого бінарника та працює в ізольованому процесі. File Provider Extension підтримує NSFileProviderItem для опису файлів та NSFileProviderEnumerator для навігації по папках. Системні інтеграції в мобільних додатках через File Provider Extension дозволяють користувачеві керувати файлами додатка з Files App без його відкриття.

class MyFileProviderExtension: NSFileProviderExtension {
    override func item(for identifier: NSFileProviderItemIdentifier) throws -> NSFileProviderItem {
        return MyFileProviderItem(identifier: identifier)
    }
}

Приклад показує мінімальну реалізацію File Provider Extension на Swift. Метод item(for:) повертає об'єкт NSFileProviderItem за ідентифікатором — система викликає його при відображенні файлів у Files App.