Descubrir activos en segundo plano alojados en Apple

Hola, soy Gabriel. Soy ingeniero de software en el equipo App Store. Yo soy Jenny. Soy ingeniera en el equipo App Processing. Hoy presentamos una nueva forma de distribuir recursos para tu app en App Store con Recursos en Segundo Plano. Hablaré de cómo tu app y sus recursos funcionan juntos. Compartiré cómo puedes usar el alojamiento de Apple para tus recursos. Revisaremos las tecnologías de entrega de recursos disponibles actualmente, incluyendo Recursos en Segundo Plano. Veremos las novedades de este año, incluidas las API Swift y Objective-C para administrar recursos en segundo plano y el alojamiento de Apple.

Mostraremos cómo integrar las nuevas funcionalidades en tu app para iOS, iPadOS, macOS, tvOS y visionOS, y cómo hacer pruebas locales.

Si quieres que Apple aloje y entregue tus recursos, te diremos cómo prepararte para las pruebas beta y la distribución del App Store.

Gabriel hará un resumen y mencionará novedades de Recursos en Segundo Plano.

Gracias, Jenny. Cuando las personas descargan una app del App Store, esperan usarla al instante. Es posible que abandonen o incluso eliminen tu app si deben esperar a que finalicen otras descargas.

Con Recursos en Segundo Plano, facilitamos una excelente experiencia desde el primer inicio. Puedes configurar cómo el sistema descarga tus recursos en los dispositivos y los actualiza sin necesidad de actualizar tu app. Puedes ofrecer un tutorial solo a quienes descargan un juego por primera vez, para que puedan jugar mientras el resto se descarga en segundo plano, ofrecer contenido descargable, o DLC, que se desbloquea con una compra en la app, o actualizar los modelos de aprendizaje automático del dispositivo con un envío acelerado al App Store. Supongamos que estás desarrollando un juego con niveles diferentes, incluido un tutorial. Tienes cuatro opciones para entregar los recursos de cada nivel: mantener todo en tu paquete de app principal, URLSession, On-Demand Resources o Recursos en Segundo Plano. Tienen sus pros y sus contras, así que vamos a analizarlas.

Mantener todo en el paquete de la app principal obliga a esperar a que se descarguen todos los recursos, incluso si solo necesitas algunos para el nivel del tutorial. También puedes alcanzar el límite de tamaño de 4 GB de las plataformas y actualizar solo uno de sus recursos requeriría volver a cargar y enviar toda la app. On-Demand Resources permite acceder al tutorial rápidamente, porque permite descargar algunas partes del paquete de apps por separado desde TestFlight o el App Store, pero aún debes actualizar toda la app solo para actualizar algunos archivos de recursos. On-Demand Resources es una tecnología heredada y será obsoleta.

Su sucesor es Recursos en Segundo Plano. Con él alojas los recursos de tu app en tu propio servidor. Puedes actualizar esos recursos cuando quieras, sin tener que actualizar toda la app. En el núcleo de Recursos en Segundo Plano está la extensión de descarga, que permite escribir código para programar descargas antes de que abran tu app. Es ideal si necesitas control sobre el comportamiento de descarga y el posprocesamiento. Pero sabemos que lo que más importa es que los recursos de tu app estén disponibles y actualizados. Con las funcionalidades de Recursos en Segundo Plano administrados, el sistema administra las descargas, actualizaciones, compresión y más. Creamos una extensión o descarga proporcionada por el sistema que puedes agregar a tu app sin tener que escribir código. Con el nuevo servicio de Recursos en Segundo Plano alojados por Apple para apps en TestFlight y el App Store, ya no necesitas alojar tus recursos en tu propio servidor con alojamiento de Apple. Obtendrás 200 GB de alojamiento de Apple incluido en tu membresía de Apple Developer Program.

Si aún usas On-Demand Resources, te sugerimos que comiences a migrar a Recursos en Segundo Plano. Con Recursos en Segundo Plano administrados, puedes crear varios paquetes con algunos de tus archivos de recursos, como texturas, efectos de sonido y sombreadores de GPU para un nivel tutorial. El sistema descarga automáticamente un paquete de recursos según la política de descarga de cada dispositivo. Hay tres políticas de descarga: esencial, previa y por solicitud. Descarga esencial significa que el sistema descarga automáticamente el paquete de recursos e integra la descarga en el proceso de instalación. El paquete de recursos contribuye al progreso general de la descarga que las personas ven en el App Store, TestFlight y la pantalla de inicio. Una vez que finaliza la instalación y se abre tu app, el paquete de recursos está listo para usarse.

Una política de descarga previa significa que el sistema comienza a descargar el paquete en la instalación de la app, pero la descarga puede continuar en segundo plano una vez finalizada la instalación. Una política de descarga por solicitud significa que el sistema descarga el paquete solo cuando se invoca explícitamente a un método API. Puedes alojar tus paquetes de recursos o dejar que Apple los aloje por ti. Jenny explicará cómo los servidores de Apple entregan paquetes de recursos y compilaciones de apps. ¡Por supuesto! Cada paquete de recursos alojado por Apple se puede usar en una app, en plataformas de tu elección. Para que el dispositivo descargue el binario de la app y cualquier paquete de recursos, primero debes cargarlos por separado en App Store Connect. Luego, puedes enviarlos para revisión con pruebas externas en TestFlight y distribución en App Store.

Una vez cargado, al paquete se le asigna una versión y no está vinculado a una versión específica de la app. La forma en que la app y el paquete coinciden en el dispositivo se determina por el estado de la versión del paquete. Déjame explicarlo con ejemplos.

Digamos que hay tres versiones del mismo paquete de recursos. La Versión 1 está disponible en App Store, la Versión 2 para beta externa en TestFlight y la Versión 3 para beta interna en TestFlight. Solo puedes activar una versión del paquete para cada contexto. Al mismo tiempo, tienes versiones de la app en dispositivos que se descargaron desde el App Store, o a través de la beta de TestFlight. El servidor seleccionará entregar la versión activa de tu paquete para todas las versiones de tu app en ese contexto en particular.

Eso significa que la versión 1.0 (1) de la app, que se descarga del App Store, usará la versión 1 del paquete.

La versión 2.0 (1) de la app disponible para beta externa en TestFlight usará la versión 2 del paquete. Y la versión 2.0 (2) y (3) en versión beta interna usarán la versión 3 del paquete.

Es importante comprender el comportamiento cuando se realizan actualizaciones a la versión de paquete.

Si estás feliz con la versión 2 del paquete de recursos, puedes enviarlo para su distribución en el App Store. Reemplazará la versión anterior disponible en el App Store.

O sea que las versiones de tu app descargadas del App Store cambiarán automáticamente para usar la versión 2 del paquete de recursos, incluidas las versiones anteriores aún instaladas. Antes de actualizar el paquete de recursos, asegúrate de que funcione en versiones y compilaciones de apps anteriores. Veamos un ejemplo de actualización de una versión de la app. Digamos que quieres enviar la versión 2.0 (3) de la app para pruebas beta externas. Si la compilación se descarga a través de una versión beta externa, usará la versión 2 del paquete más antiguo. Si quieres combinarlo con la versión 3 del paquete de recursos más nuevo, debes enviar también la versión del paquete de recursos. Ahora que conoces el concepto de paquetes de recursos, Gabriel explicará cómo crearlos y usarlos en tu app. Gracias, Jenny. Déjame mostrarte cómo usar Recursos en Segundo Plano administrados en tu app.

Para comenzar a usarlos, debes crear paquetes de recursos, adoptar las nuevas API y probar tu app y paquetes de recursos localmente.

Veamos cómo crear un paquete de recursos.

Puedes usar la nueva herramienta para macOS, Linux y Windows que toma archivos de tu repositorio de origen y los empaqueta en un archivo comprimido para enviarlos a TestFlight y al App Store. La herramienta viene con Xcode en macOS y pronto estará disponible para descargar desde el sitio web para desarrolladores de Apple para Linux y Windows. Veamos la herramienta en acción.

Puedes comenzar ejecutando el comando de plantilla y generando una plantilla de manifiesto. En macOS, instala Xcode y ejecuta la plantilla xcrun ba-package en Terminal. En Linux o Windows, haz que la herramienta esté disponible en la ruta de búsqueda y ejecuta ba-package template. La herramienta generará una plantilla de manifiesto. Ese es un archivo JSON que debes completar para informar a Apple de tu paquete de recursos. Puedes elegir un ID personalizado. Esto usarás para identificar el paquete de recursos en el código de tu app, una política de descarga y el conjunto de plataformas que admite el paquete de recursos.

Primero completemos los selectores de archivos. Este selecciona un conjunto de archivos en tu repositorio de origen para incluirlos en el paquete de recursos. Hay dos tipos de selectores de archivos: los que seleccionan archivos individuales y los de directorios completos.

Agreguemos un selector de archivos para el video introductorio del juego, con una ruta relativa desde la raíz del repositorio de origen.

El ID de este paquete de recursos es Tutorial porque contiene los archivos para el nivel Tutorial. Ahora, configuremos la política de descarga. Como el tutorial es lo primero que se experimenta, hagamos que el paquete del tutorial esté disponible antes de abrir el juego. Esta es una excelente situación para usar una política de descarga esencial.

El nivel tutorial es relevante sólo para quienes recién instalan el juego. Quienes ya juegan el juego y simplemente están actualizando a una nueva versión no necesitan descargar el tutorial.

Vamos a restringir la descarga esencial sólo a la primera instalación y excluir las actualizaciones posteriores. Esto significa que solo alguien que descargue el juego por primera vez obtendrá los recursos del tutorial.

Ahora que el manifiesto está completo, ejecutemos la herramienta para generar un archivo comprimido. Estableceremos el directorio actual en la raíz del repositorio y pasaremos la ruta al manifiesto y la ruta donde guardar el archivo. Ahora que el paquete de recursos está empaquetado, veamos cómo usarlo.

Con unas pocas líneas de código, puedes usar las API en Recursos en Segundo Plano para leer los archivos de paquetes de recursos. Empecemos con una extensión de descarga en Xcode. La extensión de descarga es la forma en que tu app programa la descarga de paquetes cuando la app principal no se está ejecutando, como durante la instalación.

Agrega un nuevo objetivo y selecciona la plantilla Background Download.

Aquí puedes elegir si quieres usar el hosting de Apple o el tuyo.

La plantilla genera código Swift, pero puedes reemplazarlo con código Objective-C si lo prefieres.

Este año, el sistema ofrece una extensión de descarga que admite descargas automáticas, actualizaciones en segundo plano y más, que puedes incorporar a tu app sin ningún código personalizado. El fragmento que Xcode genera con la plantilla Background Download está configurado para usar la implementación del sistema predeterminadamente. No hay otro código de extensión que escribir.

Incluso puedes eliminar por completo el método shouldDownload(_:) si no necesitas personalizar el comportamiento de descarga. Esto significa que puedes agregar una extensión de descarga a tu app con solo unas líneas de código generado por Xcode.

Si deseas personalizar el comportamiento de descarga, puedes brindar una implementación personalizada para shouldDownload(_:). El sistema invoca a shouldDownload(_:) para cada nuevo paquete de recursos que, según la política de descarga, planea descargar en segundo plano, y puedes devolver un valor booleano para decidir si continuar con la descarga. Esto es útil si algunos paquetes de recursos tienen requisitos de compatibilidad específicos. Ya que implementaste la extensión de descarga, veamos cómo usar archivos en los paquetes de recursos descargados en tu app principal.

El primer paso es invocar ensureLocalAvailability(of:) en el AssetPackManager compartido. Este método verifica si el paquete de recursos está descargado. Si no es así, comienza a descargarlo y espera a que finalice la descarga. En la mayoría de los casos, la extensión de descarga ya habrá descargado el paquete de recursos, por lo que el método regresará. Si el paquete de recursos debe descargarse nuevamente, es una buena idea proporcionar información de progreso visible a las personas que usan tu app.

En Swift, puedes esperar actualizaciones de estado en la secuencia asincrónica que devuelve statusUpdates(forAssetPackWithID:)

En Objective-C, puedes crear un objeto que cumpla con el protocolo BAManagedAssetPackDownloadDelegate y asignarlo a la propiedad delegate del administrador de paquetes compartido.

Si necesitas cancelar una descarga, puedes hacerlo invocando cancel(). En cualquiera de las estructuras de progreso que recibas en las actualizaciones de estado de descarga. Una vez que ensureLocalAvailability(of:) regresa sin generar un error, el paquete de recursos está listo para usarse localmente.

Para leer un archivo, invoca contents(at:searchingInAssetPackWithID:options:). En el administrador de paquetes compartido. El primer parámetro es una ruta relativa desde la raíz de tu repositorio de origen, es decir, el directorio desde el que ejecutaste la herramienta para crear el paquete de recursos, hasta el archivo que quieres leer. El sistema fusiona automáticamente todos tus paquetes en un espacio de nombres compartido, reconstruyendo tu repositorio de origen como si fuera copiado desde tu máquina de desarrollo a los dispositivos. Esto significa que no debes preocuparte por dar seguimiento de paquetes cuando deseas leer ese archivo en tiempo de ejecución. De forma predeterminada, contents(at:searchingInAssetPackWithID:options:) devuelve una instancia de datos mapeada en memoria, adecuada para archivos de recursos grandes que ocupan mucho espacio.

Si necesitas acceso de bajo nivel al descriptor de archivo, como para leer un archivo en la memoria, puedes usar descriptor(for:searchingInAssetPackWithID:), en cuyo caso es tu responsabilidad cerrar el descriptor cuando termines de usarlo. También puedes restringir la búsqueda a un paquete de recursos proporcionando un argumento distinto de nulo para assetPackID de cualquier método. El sistema rastrea qué paquetes de recursos descargó tu app y los mantiene actualizados automáticamente en segundo plano. No eliminará automáticamente los paquetes mientras tu app esté instalada, por lo que es una buena idea invocar remove(assetPackWithID:) en el administrador de paquetes de recursos compartidos para liberar espacio de almacenamiento cuando ya no uses un paquete. Puedes eliminar el paquete de Tutorial cuando alguien termine de jugar el nivel del tutorial.

Siempre puedes invocar ensureLocalAvailability(of:) para volver a descargar el paquete de recursos si, por ejemplo, alguien restablece su progreso en el juego y juega el tutorial otra vez.

Ten en cuenta que las personas pueden ver el espacio de almacenamiento que ocupan tus paquetes de recursos en la vista de almacenamiento de la Configuración en su dispositivo. El siguiente paso es agregar la app principal y la extensión de descarga al mismo grupo de apps. El sistema usa el grupo de apps para facilitar la coordinación entre tu app principal y tu extensión.

Agrega BAAppGroupID al Info.plist de tu app principal con el ID del grupo de apps como valor de cadena.

Además, agrega BAHasManagedAssetPacks con true o yes como su valor booleano.

Si usas el alojamiento de Apple, agrega BAUsesAppleHosting con true o yes como su valor booleano. Si no usas el alojamiento de Apple, consulta la documentación en la sección Recursos de esta sesión para más información sobre otras claves Info.plist requeridas, incluida BAManifestURL. Ahora que la app y la extensión están configuradas, es hora de probar.

Creamos un servidor simulado de Recursos en Segundo Plano para macOS, Linux y Windows para probar las descargas de paquetes antes de enviar tu app a TestFlight o al App Store. El servidor simulado también viene con Xcode en macOS y pronto se podrá descargar desde las descargas del sitio web para desarrolladores de Apple para Linux y Windows. Recursos en Segundo Plano usa HTTPS para las descargas, por lo que debes emitir un certificado SSL. Para eso, debes crear una autoridad de certificación raíz. Luego instala esa autoridad en tus dispositivos de prueba. Después de eso, usa la autoridad de certificación para emitir un certificado SSL e inicia el servidor simulado y apúntalo al certificado SSL. Para más detalles, consulta la documentación relacionada en la sección Recursos de esta sesión. Una vez que emitiste tu certificado, puedes ejecutar ba-serve para iniciar el servidor simulado, pasar las rutas respectivas a los archivos de paquetes que deseas servir y configurar el host a vincular. El host puede ser una dirección IP, un nombre de host o de dominio. En macOS, la herramienta te pedirá que elijas una identidad, es decir, un certificado y una clave privada de tu llavero. En Linux o Windows, deberás pasar el certificado y tu clave privada en la línea de comando. Pasa el indicador de ayuda para opciones adicionales, como configurar un número de puerto personalizado y, en macOS pronto, omitir la solicitud de identidad. En dispositivos de prueba con iOS, iPadOS y visionOS, y próximamente con tvOS, ve a Anulaciones de desarrollo en Configuración del desarrollador para ingresar la URL tu servidor simulado, su host y puerto. En dispositivos de prueba macOS, ejecuta xcrun ba-serve url-override para ingresar esa información.

Al crear y ejecutar tu app desde Xcode, descargará sus paquetes de recursos desde tu servidor simulado. Ahora, Jenny hablará sobre las pruebas beta y la distribución de tus paquetes de recursos. - ¿Jenny? - Gracias Gabriel. Ahora que ya tienes listos los paquetes binarios y de recursos de la app, te explicaré cómo prepararlos para las pruebas beta en TestFlight y su distribución en el App Store.

Si usas el alojamiento de Apple, carga los paquetes binarios y de recursos de tu app en App Store Connect por separado, pruébalos con TestFlight y distribuye en el App Store.

Veamos cómo funciona este proceso para los paquetes de recursos. Hay varias formas de cargar un paquete de recursos.

Para arrastrar y soltar, puedes usar la app Transporter para macOS.

Para control y transparencia total, puedes usar las API REST de App Store Connect para crear tu propia automatización. Para una IU de línea de comandos simplificada, iTMSTransporter proporciona comandos útiles y realiza solicitudes a las API de App Store Connect. Puedes consultar la documentación de todas estas herramientas. Te explicaré cómo usar Transporter y la API de App Store Connect. Con la app Transporter, simplemente arrastra y suelta tu archivo Tutorial.aar en la ventana Transporter.

Agrégalo a la app que quieras y haz clic en Deliver. Se convertirá en una nueva versión del paquete de recursos del Tutorial.

Podrás ver el estado de la carga de tu paquete de recursos en Transporter.

Si deseas tener visibilidad completa de la carga, puedes usar la API de App Store Connect. Necesitarás seguir tres pasos: crea un registro de paquete de recursos, crea un registro de versión y carga el archivo en la versión del paquete de recursos. Para crear el registro del paquete de recursos, realiza una solicitud POST al recurso backgroundAssets.

En el cuerpo de la solicitud, coloca el nombre del paquete de recursos como assetPackIdentifier y agrega la cuenta de Apple de tu app. La respuesta devolverá un UUID a tu paquete de recursos, que puedes usar en invocaciones a API.

Luego, crea una nueva versión para tu paquete de recursos con una solicitud POST al recurso backgroundAssetVersions.

En la sección relationships, usa el ID del paquete de recursos de la respuesta de API anterior. Esta operación aumenta el número de versión en función de las versiones existentes. Aquí tendremos la versión 1. También recibirás un ID para identificar de forma única la versión 1 del paquete de recursos del Tutorial.

Cuando se cree correctamente la versión del paquete de recursos, podrás usar el recurso backgroundAssetUploadFiles para una reserva de carga de tu archivo Tutorial.aar. Este paso es similar para otras operaciones de carga.

Aquí necesitarás el tipo de recursos, el nombre del archivo, el tamaño la suma de comprobación MD5,

y la relación con el ID de la versión del recurso en segundo plano. La respuesta incluye un ID para archivo de carga y detalles sobre las instrucciones de carga.

Cuando cargues exitosamente tu archivo, invoca PATCH a backgroundAssetUploadFiles con tu ID de archivo de carga y tu paquete de recursos comenzará a procesarse.

Para ver el progreso del paquete de recursos, puedes obtener la información completa de los paquetes de recursos disponibles en App Store Connect o con las API de App Store Connect.

En App Store Connect, puedes ver el estado del procesamiento del paquete en la pestaña TestFlight. Una vez que la carga se procese, el estado pasará a Ready para pruebas internas. Significa que tu nueva versión está lista para usarse en las versiones de apps activas para pruebas internas en TestFlight. Recibirás un correo electrónico informándote que tu versión del paquete está lista. También puedes configurar un webhook para esta notificación.

Consulta la sesión de la WWDC25 “Automatiza tu proceso de desarrollo con la API de App Store Connect” para más información de las funcionalidades del webhook de este año.

Pero, si durante el procesamiento, se descubre un problema con el archivo de tu paquete de recursos, el estado será Failed y se te notificará. Puedes solucionar el problema y cargar el paquete como una nueva versión. Al usar las API de App Store Connect, hay muchos recursos a los que realizar solicitudes GET para ver una lista de todos los paquetes de recursos de tu app, las versiones y sus estados. Puedes seguir el progreso de tu carga con el recurso backgroundAssetVersions.

Cuando se procese tu paquete de recursos, se creará un recurso de versiones beta internas. Te mostrará que la versión del paquete de recursos está READY_FOR_TESTING.

Después de cargar el binario de tu app y el paquete de recursos, puedes realizar pruebas beta en TestFlight.

En App Store Connect, puedes ver que la versión 1 del Tutorial está lista para pruebas internas. Si deseas probar tu app y el paquete de recursos con un público más amplio, puedes enviarlos por separado para pruebas externas.

Para enviar un paquete de recursos, haz clic en la versión y selecciona Submit for External Testing. Cuando se apruebe la versión, verás el cambio de estado a Ready para pruebas externas y recibirás una notificación.

Con las API de App Store Connect, también puedes enviar la versión del paquete de recursos con betaBackgroundAssetReviewSubmissions.

Puedes seguir el estado de la revisión con el recurso de versiones beta externas. Te mostrará cuando la versión del paquete está lista para pruebas externas.

Después de la prueba, cuando quieras que la versión de paquete de recursos esté disponible en el App Store, puedes enviarla a App Review para su distribución.

Puedes ir a la pestaña de distribución en App Store Connect y ver los paquetes de recursos. Puedes enviar una versión del paquete de recursos sola o con otros paquetes, una versión de la app y quizás otros elementos de revisión juntos. Si envías una versión de paquete de recursos y de app juntas, el equipo de revisión de apps usará la versión de paquete seleccionada para revisarla.

Para agregar un paquete de recursos para revisión, haz clic en Select Asset Pack, elige la versión y agrégala.

Cuando se apruebe el envío, verás que la versión del paquete de recursos está Ready for Distribution.

Al usar la API de App Store Connect, también puedes enviar material para revisión con reviewSubmissions.

Durante la revisión, puedes ver los estados en el recurso de lanzamientos del App Store. Cuando esté listo para su distribución, significa que las personas que usan tu app podrán descargar los nuevos recursos desde el App Store. Vimos muchos temas hoy. Hablamos sobre paquetes de recursos, cómo crear uno y usarlo en tu app, cómo cargarlo y enviarlo para el alojamiento de Apple. Esperamos que esta sesión te resulte útil para usar los Recursos en Segundo Plano administrados.

Ahora es tu turno. Intenta usar la herramienta para crear tu primer paquete de recursos. Si tu app aún usa On-Demand Resources, evalúa cómo puedes migrar a Recursos en Segundo Plano. Consulta la documentación y adopta las nuevas API de Recursos en Segundo Plano en tu app. Por último, queremos tus comentarios. Cuéntanos qué funciona para ti y qué no con Feedback Assistant. También puedes consultar todas las novedades de este año en App Store Connect viendo la sesión “Novedades en App Store Connect”. Obtén más información de funcionalidades de Recursos en Segundo Plano y consejos útiles para pruebas locales, en “Novedades de Recursos en Segundo Plano” de la WWDC23.

- Gracias por acompañarnos. - Esperamos tus comentarios.