App Extensions and System Integrations in Mobile Development: What They Are, Types, and How They Work

App Extensions on iOS: Widgets and Content Sharing Extensions

App Extensions on iOS appeared in iOS 8 and became the foundation for system integrations in mobile development. These are separate binaries bundled with the main app but launched in an isolated process. Each extension has its own Info.plist and entry point defined via NSExtensionPrincipalClass. The system manages the lifecycle of App Extensions — they cannot stay in the background after completing a task.

WidgetKit and Today Widget

WidgetKit (iOS 14+) is a modern framework for creating widgets on the home screen. WidgetKit uses SwiftUI for interface description and TimelineProvider for defining update schedules. Widgets come in three sizes: small (2×2 cells), medium (4×2), and large (4×4). The old Today Widget based on UICollectionViewController is still supported, but Apple recommends migrating to WidgetKit. App Extensions on WidgetKit do not support animation, keyboard input, or gestures — they are static or pseudo-animated elements with periodic updates.

Share Extension and Action Extension

Share Extension allows sending content from any app to yours via the system share sheet. Share Extension receives data through NSExtensionItem and uses SLComposeServiceViewController for the UI. Action Extension processes content in place — for example, it translates text in the browser without switching to another app. Both types must complete work within a limited time, otherwise the system "kills" the extension. This is an important limitation of App Extensions in a mobile app — background tasks are not available at the extension level.

CallKit, PushKit, and SiriKit — System Integrations for Voice and Notifications

System Integrations on iOS go far beyond widgets: CallKit, PushKit, and SiriKit allow a mobile app to work at the system level. These frameworks require special entitlements but give the user a seamless experience — calls via CallKit look like regular phone calls, and Siri handles requests without opening the app.

CallKit — VoIP Calls in the System Interface

CallKit integrates third-party app calls into the system call screen, including the locked screen. The CXProvider registers the app as a VoIP service, and CXCallController manages calls. CallKit automatically blocks duplicate calls and supports Call Directory Extension for blocking unwanted numbers. System integrations in mobile development with CallKit are critical for voice communication apps — WhatsApp, Skype, and Zoom use it to display incoming calls.

PushKit — Background Push Notifications

PushKit delivers push notifications directly to the mobile app without showing them to the user. PushKit wakes the app from a "killed" state and passes data through the PKPushRegistryDelegate. This is the primary mechanism for VoIP apps: PushKit delivers call information, and CallKit displays it. PushKit has higher delivery priority than regular push notifications and does not require showing a banner. App Extensions in mobile apps often combine PushKit with CallKit for voice communication.

SiriKit and Intents Extension

SiriKit allows handling requests through Siri and the Shortcuts app. Intents Extension is a separate App Extension that registers supported intents and processes them. SiriKit supports 20+ domains: calls, messages, payments, notes, workouts. Shortcuts allow users to create automations — for example, "Send a message in WhatsApp via Siri." System integrations with SiriKit and Shortcuts increase engagement since the user performs actions without opening the app.

BroadcastReceiver and System Services on Android

BroadcastReceiver is an Android component that reacts to system broadcast messages. Unlike iOS App Extensions, BroadcastReceiver does not require a separate binary — you just register the receiver in the manifest or in code via Context.registerReceiver. System integrations on Android often start with BroadcastReceiver: from starting a service at device boot to reacting to network connection.

IntentFilter for System Events

IntentFilter binds BroadcastReceiver to a specific system event. Typical events: BOOT_COMPLETED (device boot), CONNECTIVITY_ACTION (network change), BATTERY_LOW (low battery), TIME_SET (time change). The receiver is registered in AndroidManifest.xml or via Context.registerReceiver for dynamic registration. Dynamic registration is preferable — it does not require manifest permissions and only works while the app is active. App Extensions on Android do not exist as a concept, but BroadcastReceiver performs a similar role — it extends app capabilities through system integrations.

NotificationListenerService and AccessibilityService

NotificationListenerService is a service that receives all system notifications. NotificationListenerService requires BIND_NOTIFICATION_LISTENER_SERVICE permission and access through accessibility settings. AccessibilityService is a more powerful system integration tool: it can read screen content, simulate clicks, and automate actions. Both services require explicit user enablement in settings, which improves security. System integrations in mobile apps via AccessibilityService are used for auto-fillers, screen readers, and accessibility tools.

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

The example registers a BroadcastReceiver for the BOOT_COMPLETED event. WorkManager is used for deferred task execution after device boot — this is the standard approach for Android apps.

App Widget Provider — Creating Widgets on Android

App Widget Provider on Android is the iOS App Extensions counterpart in the widget context: it is a component that displays interactive content on the home screen. Unlike WidgetKit, Android widgets can accept user input — clicks, toggles, and gestures. App Widget Provider is registered in the manifest via an XML description of size and update frequency.

RemoteViews and AppWidgetProvider

RemoteViews describes the widget interface through an XML layout and supports only a limited set of Views. RemoteViews does not allow custom Views — only standard components: TextView, ImageView, Button, ProgressBar. AppWidgetProvider is the base class that handles widget updates, enabling, and deletion. The onUpdate method is called via timer using updatePeriodMillis or via WorkManager for precise control. System integrations with widgets on Android require caution — too frequent updates drain the battery.

Glance API (Jetpack) — Modern Approach

Glance API is a Jetpack library for creating widgets using Kotlin DSL instead of XML. Glance API compiles to RemoteViews and supports Compose-like syntax: GlanceComposable, Column, Row, Text. The library solves the problem of complex XML code and allows testing widgets via JUnit. Glance API does not yet support all RemoteViews features — for complex interactive widgets, the classic approach is better. App Extensions in mobile development on Android are evolving toward Glance API, simplifying widget creation and maintenance.

Content Provider, FileProvider, and Data Sharing Between Apps

Content Provider is an Android component for sharing structured data between apps through a unified ContentResolver interface. Unlike iOS App Extensions, Content Provider does not create a separate process — data is requested synchronously within the calling app's context. Content Provider is the foundation of system integrations on Android: contacts, media files, calendar, and standard apps use it to publish data.

FileProvider for Secure File Sharing

FileProvider is a subclass of ContentProvider for secure file transfer between apps. FileProvider generates temporary content:// URIs instead of direct file:// paths, which are prohibited on Android 7+. To use it, you need to specify files-path or external-files-path in the XML configuration. App Extensions in mobile development on Android do not exist as a separate concept, but FileProvider performs their function — it extends data sharing capabilities beyond one app.

iOS Counterpart: File Provider Extension

On iOS, the role of file sharing is performed by File Provider Extension. File Provider Extension publishes the app's files to the Files App via NSFileProviderManager. Unlike FileProvider, the iOS extension requires a separate binary and runs in an isolated process. File Provider Extension supports NSFileProviderItem for file description and NSFileProviderEnumerator for folder navigation. System integrations in mobile apps via File Provider Extension allow the user to manage app files from the Files App without opening it.

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

The example shows a minimal implementation of File Provider Extension in Swift. The item(for:) method returns an NSFileProviderItem object by identifier — the system calls it when displaying files in the Files App.