App Extensions e integraciones de sistema en el desarrollo móvil: qué son, tipos y cómo funcionan

App Extensions en iOS: widgets y extensiones para compartir contenido

Las App Extensions en iOS aparecieron en iOS 8 y se convirtieron en la base de las integraciones de sistema en el desarrollo móvil. Son binarios separados empaquetados con la aplicación principal, pero que se ejecutan en un proceso aislado. Cada extensión tiene su propio Info.plist y punto de entrada definido mediante NSExtensionPrincipalClass. El sistema gestiona el ciclo de vida de las App Extensions — no pueden permanecer en segundo plano después de completar una tarea.

WidgetKit y Today Widget

WidgetKit (iOS 14+) es un framework moderno para crear widgets en la pantalla de inicio. WidgetKit usa SwiftUI para describir la interfaz y TimelineProvider para definir los horarios de actualización. Los widgets vienen en tres tamaños: pequeño (2×2 celdas), mediano (4×2) y grande (4×4). El antiguo Today Widget basado en UICollectionViewController sigue siendo compatible, pero Apple recomienda migrar a WidgetKit. Las App Extensions en WidgetKit no admiten animaciones, entrada de teclado ni gestos — son elementos estáticos o pseudoanimados con actualizaciones periódicas.

Share Extension y Action Extension

Share Extension permite enviar contenido desde cualquier aplicación a la suya a través de la hoja de compartir del sistema. Share Extension recibe datos mediante NSExtensionItem y usa SLComposeServiceViewController para la interfaz. Action Extension procesa contenido en el lugar — por ejemplo, traduce texto en el navegador sin cambiar a otra aplicación. Ambos tipos deben completar su trabajo en un tiempo limitado; de lo contrario, el sistema "mata" la extensión. Esta es una limitación importante de las App Extensions en una aplicación móvil — las tareas en segundo plano no están disponibles a nivel de extensión.

CallKit, PushKit y SiriKit — integraciones de sistema para voz y notificaciones

Las integraciones de sistema en iOS van mucho más allá de los widgets: CallKit, PushKit y SiriKit permiten que una aplicación móvil funcione a nivel de sistema. Estos frameworks requieren entitlements especiales, pero ofrecen al usuario una experiencia fluida: las llamadas a través de CallKit se ven como llamadas telefónicas normales, y Siri gestiona las solicitudes sin abrir la aplicación.

CallKit — llamadas VoIP en la interfaz del sistema

CallKit integra las llamadas de aplicaciones de terceros en la pantalla de llamadas del sistema, incluida la pantalla bloqueada. CXProvider registra la aplicación como servicio VoIP, y CXCallController gestiona las llamadas. CallKit bloquea automáticamente las llamadas duplicadas y admite Call Directory Extension para bloquear números no deseados. Las integraciones de sistema en el desarrollo móvil con CallKit son críticas para las aplicaciones de comunicación por voz — WhatsApp, Skype y Zoom lo usan para mostrar llamadas entrantes.

PushKit — notificaciones push en segundo plano

PushKit entrega notificaciones push directamente a la aplicación móvil sin mostrarlas al usuario. PushKit activa la aplicación desde un estado "terminado" y pasa datos a través del delegado PKPushRegistryDelegate. Este es el mecanismo principal para aplicaciones VoIP: PushKit entrega la información de la llamada y CallKit la muestra. PushKit tiene mayor prioridad de entrega que las notificaciones push normales y no requiere mostrar un banner. Las App Extensions en aplicaciones móviles a menudo combinan PushKit con CallKit para la comunicación por voz.

SiriKit y Intents Extension

SiriKit permite gestionar solicitudes a través de Siri y la aplicación Atajos. Intents Extension es una App Extension separada que registra los intents compatibles y los procesa. SiriKit admite más de 20 dominios: llamadas, mensajes, pagos, notas, entrenamientos. Los Atajos permiten al usuario crear automatizaciones — por ejemplo, "Enviar un mensaje en WhatsApp a través de Siri." Las integraciones de sistema con SiriKit y Atajos aumentan la participación, ya que el usuario realiza acciones sin abrir la aplicación.

BroadcastReceiver y servicios de sistema en Android

BroadcastReceiver es un componente de Android que reacciona a mensajes de difusión del sistema. A diferencia de las App Extensions de iOS, BroadcastReceiver no requiere un binario separado — basta con registrar el receptor en el manifiesto o en el código mediante Context.registerReceiver. Las integraciones de sistema en Android a menudo comienzan con BroadcastReceiver: desde iniciar un servicio al arrancar el dispositivo hasta reaccionar a la conexión de red.

IntentFilter para eventos del sistema

IntentFilter vincula BroadcastReceiver a un evento del sistema específico. Eventos típicos: BOOT_COMPLETED (arranque del dispositivo), CONNECTIVITY_ACTION (cambio de red), BATTERY_LOW (batería baja), TIME_SET (cambio de hora). El receptor se registra en AndroidManifest.xml o mediante Context.registerReceiver para registro dinámico. El registro dinámico es preferible — no requiere permisos en el manifiesto y solo funciona mientras la aplicación está activa. Las App Extensions en Android no existen como concepto, pero BroadcastReceiver cumple un papel similar — amplía las capacidades de la aplicación a través de integraciones de sistema.

NotificationListenerService y AccessibilityService

NotificationListenerService es un servicio que recibe todas las notificaciones del sistema. NotificationListenerService requiere el permiso BIND_NOTIFICATION_LISTENER_SERVICE y acceso a través de la configuración de accesibilidad. AccessibilityService es una herramienta más potente para la integración de sistema: puede leer el contenido de la pantalla, simular clics y automatizar acciones. Ambos servicios requieren que el usuario los active explícitamente en la configuración, lo que mejora la seguridad. Las integraciones de sistema en aplicaciones móviles a través de AccessibilityService se utilizan para autocompletar, lectores de pantalla y herramientas de accesibilidad.

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

El ejemplo registra un BroadcastReceiver para el evento BOOT_COMPLETED. WorkManager se utiliza para la ejecución diferida de tareas después del arranque del dispositivo — este es el enfoque estándar para aplicaciones Android.

App Widget Provider — creación de widgets en Android

App Widget Provider en Android es el equivalente de las App Extensions de iOS en el contexto de widgets: es un componente que muestra contenido interactivo en la pantalla de inicio. A diferencia de WidgetKit, los widgets de Android pueden aceptar entrada del usuario — clics, interruptores y gestos. App Widget Provider se registra en el manifiesto mediante una descripción XML del tamaño y la frecuencia de actualización.

RemoteViews y AppWidgetProvider

RemoteViews describe la interfaz del widget mediante un diseño XML y solo admite un conjunto limitado de Vistas. RemoteViews no permite Vistas personalizadas — solo componentes estándar: TextView, ImageView, Button, ProgressBar. AppWidgetProvider es la clase base que maneja las actualizaciones, activación y eliminación del widget. El método onUpdate se llama mediante un temporizador usando updatePeriodMillis o mediante WorkManager para un control preciso. Las integraciones de sistema con widgets en Android requieren precaución — las actualizaciones demasiado frecuentes agotan la batería.

Glance API (Jetpack) — enfoque moderno

Glance API es una biblioteca de Jetpack para crear widgets usando Kotlin DSL en lugar de XML. Glance API se compila a RemoteViews y admite una sintaxis similar a Compose: GlanceComposable, Column, Row, Text. La biblioteca resuelve el problema del código XML complejo y permite probar widgets mediante JUnit. Glance API aún no admite todas las funciones de RemoteViews — para widgets interactivos complejos, es mejor usar el enfoque clásico. Las App Extensions en el desarrollo móvil en Android están evolucionando hacia Glance API, simplificando la creación y el mantenimiento de widgets.

Content Provider, FileProvider e intercambio de datos entre aplicaciones

Content Provider es un componente de Android para compartir datos estructurados entre aplicaciones a través de una interfaz unificada ContentResolver. A diferencia de las App Extensions de iOS, Content Provider no crea un proceso separado — los datos se solicitan de forma síncrona dentro del contexto de la aplicación solicitante. Content Provider es la base de las integraciones de sistema en Android: contactos, archivos multimedia, calendario y aplicaciones estándar lo usan para publicar datos.

FileProvider para compartir archivos de forma segura

FileProvider es una subclase de ContentProvider para la transferencia segura de archivos entre aplicaciones. FileProvider genera URI temporales content:// en lugar de rutas directas file://, que están prohibidas en Android 7+. Para usarlo, debe especificar files-path o external-files-path en la configuración XML. Las App Extensions en el desarrollo móvil en Android no existen como concepto separado, pero FileProvider cumple su función — amplía las capacidades de intercambio de datos más allá de una aplicación.

Equivalente en iOS: File Provider Extension

En iOS, el papel del intercambio de archivos lo realiza File Provider Extension. File Provider Extension publica los archivos de la aplicación en la aplicación Archivos a través de NSFileProviderManager. A diferencia de FileProvider, la extensión de iOS requiere un binario separado y se ejecuta en un proceso aislado. File Provider Extension admite NSFileProviderItem para la descripción de archivos y NSFileProviderEnumerator para la navegación por carpetas. Las integraciones de sistema en aplicaciones móviles a través de File Provider Extension permiten al usuario gestionar los archivos de la aplicación desde la aplicación Archivos sin abrirla.

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

El ejemplo muestra una implementación mínima de File Provider Extension en Swift. El método item(for:) devuelve un objeto NSFileProviderItem por identificador — el sistema lo llama al mostrar archivos en la aplicación Archivos.