Découvrez les ressources d’arrière-plan hébergées par Apple

Bonjour, je m’appelle Gabriel. Je suis ingénieur logiciel de l’équipe App Store. Et moi c’est Jenny. Je suis ingénieure dans l’équipe App Processing. Nous allons présenter un nouveau moyen de distribuer les ressources de votre app sur l’App Store avec Background Assets. Je vais expliquer comment les apps et les ressources fonctionnent ensemble sur les appareils. Nous verrons comment utiliser l’hébergement Apple pour vos ressources. Nous passerons en revue les technologies de diffusion de ressources disponibles, y compris Background Assets. Puis, nous verrons les nouveautés comme les nouvelles API Swift et Objective-C pour gérer vos Background Assets, ainsi que l’hébergement Apple.

Nous montrerons comment intégrer les fonctionnalités dans votre app sous iOS, iPadOS, macOS, tvOS et visionOS, et comment réaliser des tests locaux.

Si vous souhaitez qu’Apple héberge et diffuse vos ressources, nous expliquerons comment préparer les tests bêta et la distribution sur l’App Store.

Gabriel va présenter un récapitulatif et les nouveautés de Background Assets.

Merci Jenny. Lorsque l’on télécharge une app sur l’App Store, on s’attend à l’utiliser immédiatement. On risque de quitter, voire de supprimer une app s’il faut attendre la fin d’autres téléchargements après l’avoir ouverte.

Background Assets facilite la création d’une excellente première expérience de lancement. Vous pouvez configurer la manière dont le système télécharge vos ressources sur les appareils et les met à jour sans mettre à jour votre app principale. Vous pouvez proposer un niveau tutoriel quand on télécharge un jeu pour la première fois, afin de commencer à jouer pendant que le reste du jeu se télécharge en arrière-plan. Vous pouvez proposer du contenu téléchargeable en option, appelé DLC, via des achats intégrés, ou mettre à jour les modèles d’apprentissage automatique grâce à un processus de soumission accéléré sur l’App Store. Supposons que vous développiez un jeu comportant plusieurs niveaux, dont un tutoriel. Vous disposez de quatre options pour fournir les ressources de chaque niveau : Tout conserver dans le bundle d’app principal, Session URL, Ressources sur requête ou Background Assets. Chacune à des avantages et des inconvénients, je vais les présenter.

Tout conserver dans le bundle d’app principal oblige à attendre le téléchargement de toutes les ressources, même si elles ne sont pas toutes requises pour le tutoriel. Vous risquez d’atteindre la limite de 4 Go de nombreuses plates-formes, et la mise à jour d’un seul élément oblige à charger et à soumettre à nouveau toute votre app. Ressources sur requête permet de passer plus vite au tutoriel, car seules certaines parties du bundle d’app sont téléchargées séparément depuis TestFlight ou l’App Store, mais la mise à jour de quelques fichiers de ressources requiert de mettre à jour toute l’app. Ressources sur requête est obsolète et sera bientôt supprimée.

Elle est remplacée par Background Assets, qui permet d’héberger les ressources de l’app sur votre serveur. Vous pouvez mettre à jour ces ressources à tout moment sans mettre à jour toute l’app. L’extension de téléchargement est l’élément clé de Background Assets, elle permet d’écrire du code pour planifier le téléchargement des ressources avant l’ouverture de l’app. Cela confère un contrôle total sur le comportement de téléchargement et le post-traitement. Pour beaucoup d’entre vous, le plus important est que les ressources de votre app soient juste disponibles et à jour. Grâce aux fonctionnalités Managed Background Assets, le système gère automatiquement les téléchargements, les mises à jour, la compression et bien plus pour vos packs de ressources. Nous avons développé un système de téléchargement ou une extension à intégrer à votre app, sans avoir à écrire de code personnalisé. Grâce au service Ressources d’arrière-plan hébergées par Apple pour les apps sur TestFlight et l’App Store, nul besoin d’héberger vos ressources sur votre serveur avec l’option d’hébergement Apple. Vous avez 200 Go de capacité d’hébergement Apple via votre abonnement au Apple Developer Program.

Si vous utilisez toujours Ressources sur requête, nous vous recommandons de migrer vers Background Assets. Avec Managed Background Assets, vous pouvez créer plusieurs packs de ressources, chacun regroupant certains fichiers de ressources, tels que les textures, les effets sonores et les shaders GPU, pour le tutoriel du jeu. Un pack de ressources est automatiquement téléchargé sur l’appareil de l’utilisateur, selon sa stratégie de téléchargement. Il existe trois stratégies de téléchargement : Essentiel, Préchargement et À la demande. Avec une stratégie de téléchargement Essentiel, le système télécharge automatiquement le pack de ressources et intègre le téléchargement au processus d’installation. Le pack de ressources contribue à la progression globale du téléchargement indiquée dans l’App Store, TestFlight et sur l’écran d’accueil. Une fois l’installation terminée et votre app ouverte, le pack de ressources est prêt à être utilisé.

Dans une stratégie Préchargement, le système commence à télécharger le pack de ressources pendant l’installation de l’app, mais le téléchargement peut se poursuivre en arrière-plan une fois l’installation terminée. Avec une stratégie de téléchargement À la demande, le pack de ressources est uniquement téléchargé si une méthode API est explicitement appelée. Vous pouvez héberger vos packs de ressources vous-même ou laisser Apple s’en charger. Jenny va expliquer comment les serveurs Apple fournissent les packs de ressources et les builds d’apps. Bien sûr ! Chaque pack de ressources hébergé par Apple peut être utilisé sur une app, sur plusieurs plates-formes de votre choix. Pour que l’appareil télécharge le fichier binaire de l’app et les packs de ressources qu’il utilise, vous devez les charger séparément sur App Store Connect. Vous pouvez ensuite les soumettre pour des tests externes dans TestFlight et la distribution sur l’App Store.

Une fois chargé, le pack de ressources se voit attribuer une version et n’est lié à aucune build de l’app. La correspondance entre l’app et le pack de ressources sur l’appareil dépend de l’état de la version du pack de ressources. Je vais donner quelques exemples.

Supposons que vous ayez trois versions différentes pour un pack de ressources. La version 1 est sur l’App Store, la version 2 est en version bêta externe sur TestFlight et la version 3 est en version bêta interne sur TestFlight. Une seule version du pack de ressources peut être disponible pour chaque contexte. Vous disposez aussi de builds de l’app sur des appareils, qui ont été téléchargées depuis l’App Store ou via la version bêta externe ou interne de TestFlight. Le serveur choisit la version disponible du pack de ressources pour toutes les builds de l’app dans ce contexte particulier.

Ainsi, la version 1.0 build 1 de l’app téléchargée depuis l’App Store utilisera la version 1 du pack de ressources.

La version 2.0 build 1 de l’app disponible en bêta externe dans TestFlight utilisera la version 2 du pack de ressources. Et les versions 2.0 builds 2 et 3 de l’app en bêta interne utiliseront la version 3 du pack de ressources.

Il est important de comprendre le comportement lors des mises à jour de la version du pack de ressources.

Si vous êtes satisfait de la version 2 du pack de ressources, vous pouvez la soumettre pour distribution sur l’App Store. Elle remplacera l’ancienne version disponible sur l’App Store.

Ainsi, toutes les versions de votre app téléchargées depuis l’App Store passeront automatiquement à la version 2 du pack de ressources, y compris les anciennes versions installées sur les appareils des utilisateurs. Avant de mettre à jour le pack de ressources, assurez-vous donc qu’il fonctionne sur les anciennes versions de l’app. Voyons un exemple de mise à jour de build d’app. Supposons que vous souhaitiez soumettre la version 2.0 build 3 de l’app pour un test bêta externe. Une fois approuvée, si la build est téléchargée via la version bêta externe, elle utilisera l’ancienne version 2 du pack de ressources. Si vous souhaitez qu’elle soit associée à la version 3 du pack de ressources, soumettez aussi la version du pack de ressources. Maintenant que vous connaissez le concept des packs de ressources, Gabriel va expliquer comment les créer et les utiliser dans votre app. Merci Jenny. Je vais montrer comment utiliser Managed Background Assets dans votre app.

Pour utiliser Managed Background Assets, vous devez créer des packs de ressources, adopter les nouvelles API et tester votre app et vos packs de ressources localement.

Je vais expliquer comment créer un pack de ressources.

Vous pouvez utiliser le nouvel outil de packaging pour macOS, Linux et Windows qui récupère les fichiers de votre référentiel source et les compresse dans une archive pour les envoyer à TestFlight et à l’App Store. L’outil de packaging est fourni avec Xcode sur macOS et sera bientôt disponible au téléchargement dans la section Téléchargements sur Apple Developer pour Linux et Windows. Je vais montrer comment ça marche.

Vous commencez par exécuter la commande template pour générer un modèle de manifeste. Sur macOS, installez Xcode et exécutez xcrun ba-package template dans Terminal. Sous Linux ou Windows, rendez l’outil disponible dans le chemin de recherche de votre shell et exécutez ba-package template. L’outil de packaging va générer un modèle de manifeste. Le manifeste est un fichier JSON à renseigner pour informer Apple de votre pack de ressources. Vous pouvez choisir un identifiant personnalisé. Ceci permet d’identifier le pack de ressources dans le code de l’app, une stratégie de téléchargement et dans les plates-formes prises en charge par le pack de ressources.

D’abord, remplissons les sélecteurs de fichiers. Un sélecteur de fichiers sélectionne des fichiers de votre référentiel source à inclure dans le pack de ressources. Il existe deux types de sélecteurs de fichiers : ceux qui sélectionnent des fichiers individuels et ceux qui sélectionnent des répertoires entiers.

Ajoutons un sélecteur de fichiers pour la vidéo d’introduction du jeu, en utilisant un chemin relatif à partir de la racine du référentiel source.

L’ID de ce pack de ressources est Tutorial, car il contient les fichiers de ressources du niveau tutoriel du jeu. Configurons la stratégie de téléchargement. Le tutoriel est la première chose que les utilisateurs découvrent, son pack de ressources dont donc être disponible localement avant la première ouverture du jeu. Une stratégie de téléchargement Essentiel est donc idéale ici.

Ce niveau tutoriel ne concerne que ceux qui installent le jeu pour la première fois. Ceux qui jouent déjà au jeu et qui effectuent une mise à jour ne devraient pas avoir besoin de télécharger à nouveau le tutoriel.

Limitons donc la stratégie de téléchargement Essentiel à la première installation en excluant les mises à jour ultérieures. Ainsi, seules les personnes qui téléchargent le jeu pour la première fois obtiendront les ressources du tutoriel.

Maintenant que le manifeste est renseigné, exécutons à nouveau l’outil de packaging pour créer une archive compressée. Nous définissons le répertoire actuel comme racine du référentiel et transmettons le chemin d’accès vers le manifeste et le chemin d’accès où enregistrer l’archive. Le pack de ressources est packagé, voyons comment l’utiliser dans le jeu.

En quelques lignes de code, vous pouvez utiliser les nouvelles API dans Background Assets pour lire les fichiers des packs de ressources. Nous ajoutons d’abord une extension de téléchargement dans Xcode. L’extension de téléchargement permet à l’app de programmer le téléchargement des packs de ressources lorsque l’app principale n’est pas en cours d’exécution, par exemple pendant l’installation.

Ajoutons une nouvelle cible et sélectionnons le modèle Background Download.

Vous pouvez choisir ici d’utiliser l’hébergement Apple ou le vôtre.

Le modèle génère du code Swift, mais vous pouvez le remplacer par du code Objective-C si vous préférez.

Le système fournit désormais une extension de téléchargement complète qui prend en charge les téléchargements automatiques, les mises à jour en arrière-plan et bien plus, à intégrer à votre app sans code personnalisé. L’extrait généré par Xcode avec le modèle Background Download est déjà configuré pour utiliser l’implémentation système par défaut. Il n’y a aucun autre code d’extension à écrire.

Vous pouvez même supprimer la méthode shouldDownload(_:) si vous n’avez pas besoin de personnaliser le comportement de téléchargement. Ainsi, vous pouvez ajouter une extension de téléchargement à votre app avec juste quelques lignes de code générées par Xcode.

Pour personnaliser le comportement de téléchargement, vous pouvez fournir une implémentation personnalisée pour shouldDownload(_:). Le système appelle votre implémentation shouldDownload(_:) pour chaque nouveau pack de ressources qu’il prévoit de télécharger en arrière-plan, selon la stratégie de téléchargement du pack de ressources. Vous pouvez renvoyer une valeur booléenne pour poursuivre ou non le téléchargement. Cela est utile si certains de vos packs de ressources ont des exigences de compatibilité spécifiques. Maintenant que vous avez implémenté l’extension de téléchargement, voyons comment utiliser les fichiers des packs de ressources téléchargés dans l’app principale.

La première étape est d’appeler la méthode ensureLocalAvailability(of:) sur l’AssetPackManager partagé. Cette méthode vérifie si le pack de ressources est actuellement téléchargé. Si ce n’est pas le cas, elle lance le téléchargement et attend qu’il se termine. Dans la plupart des cas, l’extension de téléchargement aura déjà téléchargé le pack de ressources, et la méthode sera rapide. Si le pack de ressources doit être téléchargé à nouveau, il est recommandé de fournir des informations visibles sur la progression aux utilisateurs de votre app.

Dans Swift, vous pouvez attendre les mises à jour de statut sur la séquence asynchrone retournée par la méthode statusUpdates(forAssetPackWithID:).

Dans Objective-C, vous pouvez créer un objet conforme au protocole BAManagedAssetPackDownloadDelegate et l’associer à la propriété déléguée du gestionnaire de packs de ressources partagées.

Si vous devez annuler un téléchargement, vous pouvez le faire en appelant cancel() sur l’une des structures de progression reçues dans les mises à jour de l’état du téléchargement. Quand ensureLocalAvailability(of:) retourne une valeur sans erreur, le pack de ressources demandé peut être utilisé localement.

Pour lire un fichier à partir de celui-ci, appelez la méthode contents(at:searchingInAssetPackWithID:options:) sur le gestionnaire de packs de ressources partagé. Le premier paramètre est un chemin relatif à partir de la racine du référentiel source, c’est-à-dire le répertoire où l’outil de packaging a été exécuté pour créer le pack de ressources, vers le fichier que vous souhaitez lire. Le système fusionne automatiquement tous vos packs d’actifs dans un espace de noms partagé, reconstruisant votre référentiel source comme un copié-collé depuis votre machine de développement vers les appareils des utilisateurs. Vous n’avez donc plus à vous soucier de savoir dans quel pack de ressources se trouve un fichier particulier lorsque vous souhaitez le lire lors de l’exécution. Par défaut, contents(at:searchingInAssetPackWithID:options:) retourne une instance de données mappée en mémoire, qui convient même aux fichiers de ressources volumineux en mémoire.

Pour un accès de bas niveau au descripteur de fichier, par exemple pour lire un fichier en mémoire de manière procédurale, utilisez la méthode descriptor(for:searchingInAssetPackWithID:) à la place, auquel cas il vous incombe de fermer le descripteur lorsque vous avez terminé de l’utiliser. Vous pouvez limiter la recherche à un pack de ressources particulier en fournissant un argument non nul pour le paramètre assetPackID de l’une des méthodes. Le système suit les packs de ressources que votre app a téléchargés et les met automatiquement à jour en arrière-plan. Il ne supprime pas automatiquement vos packs de ressources tant que l’app est installée. Appelez la méthode remove(assetPackWithID:) sur le gestionnaire de packs de ressources partagés pour libérer de l’espace de stockage lorsque vous n’utilisez plus un pack de ressources. Par exemple, vous pouvez supprimer le pack de ressources Tutorial lorsque quelqu’un termine le niveau tutoriel.

Vous pouvez toujours appeler ensureLocalAvailability(of:) pour télécharger à nouveau le pack de ressources si, par exemple, quelqu’un réinitialise sa progression dans le jeu et recommence le tutoriel.

N’oubliez pas que les utilisateurs peuvent voir l’espace de stockage occupé par vos packs de ressources téléchargés dans la section Stockage des Réglages de leur appareil. L’étape suivante consiste à ajouter l’app principale et votre extension de téléchargement au même groupe d’apps. Le système utilise le groupe d’apps pour faciliter la coordination entre l’app principale et votre extension.

Ajoutez ensuite la clé BAAppGroupID au fichier Info.plist de l’app principale avec l’ID de groupe d’apps comme valeur de chaîne.

Ajoutez également la clé BAHasManagedAssetPacks avec la valeur booléenne true ou yes.

Si vous utilisez l’hébergement Apple, ajoutez la clé BAUsesAppleHosting avec la valeur booléenne true ou yes. Si vous n’utilisez pas l’hébergement Apple, consultez la documentation dans la section Ressources de cette session pour en savoir plus sur les autres clés Info.plist requises, notamment BAManifestURL. Maintenant que l’app et l’extension sont configurées, passons aux tests.

Nous avons créé un serveur fictif Background Assets pour macOS, Linux et Windows pour tester les téléchargements de packs de ressources avant de soumettre l’app à TestFlight ou à l’App Store. Tout comme l’outil de packaging, le serveur fictif est fourni avec Xcode sur macOS et sera bientôt disponible au téléchargement dans la section Téléchargements sur Apple Developer pour Linux et Windows. Background Assets utilise le protocole HTTPS pour tous les téléchargements. Vous devez donc émettre un certificat SSL. Pour ce faire, vous devez créer une autorité de certification racine. Ensuite, vous l’installerez sur vos appareils de test. Puis, vous utiliserez l’autorité de certification pour émettre un certificat SSL et vous lancerez le serveur fictif et le dirigerez vers ce certificat SSL. Pour en savoir plus, consultez la documentation dans la section Ressources de cette session. Une fois votre certificat SSL émis, vous pouvez exécuter ba-serve pour démarrer sur serveur fictif, transmettre les chemins d’accès respectifs aux archives du pack de ressources à servir et définir l’hôte auquel se connecter. L’hôte peut être une adresse IP, un nom d’hôte ou un nom de domaine. Sur macOS, l’outil vous invite à choisir une identité, à savoir une paire composée d’un certificat et d’une clé privée provenant de votre trousseau. Sous Linux ou Windows, vous devrez transmettre le certificat et sa clé privée sur la ligne de commande. Transmettez l’indicateur d’aide pour en savoir plus sur les options supplémentaires, notamment pour définir un numéro de port personnalisé et, bientôt sous macOS, la possibilité d’ignorer l’invite d’identité. Sur les appareils de test iOS, iPadOS et visionOS, et bientôt sur les appareils de test tvOS, accédez à Dérogations de développement dans Réglages Développement afin de saisir l’URL de base du serveur fictif, y compris son hôte et son port. Sur les appareils de test macOS, exécutez xcrun ba-serve url-override pour saisir les mêmes informations.

Lorsque vous compilez et exécutez l’app depuis Xcode, elle télécharge ses packs de ressources depuis le serveur fictif. Jenny va maintenant parler du test bêta et de la distribution de vos packs de ressources. - Jenny ? - Merci Gabriel. Maintenant que vous avez le nouveau fichier binaire de l’app et les packs de ressources, je vais expliquer comment les préparer pour le test bêta sur TestFlight et la distribution sur l’App Store.

Si vous utilisez l’hébergement Apple, vous devrez charger séparément le fichier binaire de l’app et les packs de ressources sur App Store Connect, éventuellement les tester avec TestFlight, puis les distribuer sur l’App Store.

Examinons comment ce processus fonctionne pour les packs de ressources. Il y a plusieurs façons de charger un pack de ressources.

Pour une expérience UI de type glisser-déposer, utilisez l’app Transporter pour macOS.

Pour un contrôle et une transparence totale, utilisez les API REST App Store Connect afin de créer votre automatisation. Pour une interface de ligne de commande simplifiée, l’app multiplateforme iTMSTransporter fournit des commandes utiles et envoie les requêtes à votre place aux API App Store Connect. Vous pouvez consulter la documentation relative à tous ces outils. Je vais maintenant expliquer comment utiliser Transporter et l’API App Store Connect. Avec l’app Transporter, il vous suffit de glisser-déposer votre archive Tutorial.aar dans la fenêtre Transporter.

Ajoutez-la à l’app de votre choix, puis cliquez sur Deliver. Elle deviendra une nouvelle version du pack de ressources Tutorial.

Vous pourrez voir l’état du chargement du pack de ressources dans l’app Transporter.

Pour une visibilité complète sur le processus de chargement, utilisez l’API App Store Connect. Vous devrez suivre trois étapes : créer un enregistrement de pack de ressources, créer un enregistrement de version du pack de ressources, charger l’archive vers la version du pack de ressources. Pour créer l’enregistrement du pack de ressources, vous pouvez envoyer une requête POST à la ressource backgroundAssets.

Dans le corps de la requête, indiquez le nom du pack de ressources comme assetPackIdentifier et ajoutez l’identifiant Apple de votre app dans la section relationships. La réponse à cet appel renvoie un UUID à votre pack de ressources, à utiliser dans les appels API ultérieurs.

Vous allez ensuite créer une version de votre pack de ressources en effectuant une requête POST vers la ressource backgroundAssetVersions.

Dans la section relationships, utilisez l’ID du pack de ressources fourni par la réponse API précédente. Cette opération augmente automatiquement le numéro de version sur la base des versions existantes. Ici, nous aurons la version 1. Vous obtiendrez un identifiant dans la réponse afin d’identifier de manière unique la version 1 du pack de ressources Tutorial.

Une fois la version du pack de ressources créée, vous pouvez utiliser la ressource backgroundAssetUploadFiles pour réserver le chargement de votre fichier d’archive Tutorial.aar. Cela est similaire à d’autres opérations de chargement, comme les captures d’écran de l’App Store.

Vous aurez besoin du type de ressource, du nom du fichier, de la taille du fichier et de la somme de contrôle MD5.

Indiquez aussi la relation avec l’ID de version de la ressource d’arrière-plan. La réponse à cet appel comprend un ID pour votre fichier à charger et des instructions de chargement.

Une fois votre archive chargée, effectuez un appel PATCH vers backgroundAssetUploadFiles avec votre ID de fichier chargé, et le traitement de votre pack de ressources commence.

Pour voir la progression du pack de ressources, vous pouvez toujours obtenir des infos complètes sur vos packs de ressources disponibles dans App Store Connect ou via les API App Store Connect.

Dans App Store Connect, l’état de traitement du pack de ressources est visible sous l’onglet TestFlight. Une fois le chargement traité avec succès, l’état passe à Prêt pour les tests internes. Votre nouvelle version est prête à être utilisée dans vos builds d’app en ligne pour les tests internes dans TestFlight. Vous recevrez un e-mail indiquant que la nouvelle version du pack de ressources est prête. Vous pouvez aussi configurer un webhook pour recevoir cette notification.

Consultez la session WWDC25 « Automate your development process with the App Store Connect API » pour en savoir plus sur les fonctionnalités webhook de cette année.

Si un problème est détecté dans votre fichier d’archive de pack de ressources pendant le traitement, l’état de la version indique Échec et vous en êtes informé. Résolvez le problème, puis chargez à nouveau le pack de ressources comme nouvelle version. Avec les API App Store Connect, vous pouvez envoyer des requêtes GET à de nombreuses ressources afin d’afficher la liste de tous les packs de ressources de votre app, leurs versions et leur état respectif. Vous pouvez suivre la progression de votre chargement avec la ressource backgroundAssetVersions.

Une fois votre pack de ressources traité, une ressource Internal Beta Releases sera créée. Elle indiquera que la version du pack de ressources est READY_FOR_TESTING.

Une fois le fichier binaire de l’app et le pack de ressources chargés, vous pouvez commencer le test bêta dans TestFlight.

Sur App Store Connect, vous pouvez voir que la version 1 du tutoriel est prête pour les tests internes. Si vous souhaitez tester la build de l’app et la version du pack de ressources auprès d’un public plus large, vous pouvez les soumettre séparément pour des tests externes.

Pour soumettre un pack de ressources, cliquez sur la version spécifique, puis sur Soumettre pour test externe. Une fois la version approuvée, son statut passe à Prêt pour test externe et vous recevez une notification.

Avec les API App Store Connect, vous pouvez aussi soumettre la version du pack de ressources via la ressource betaBackgroundAssetReviewSubmissions.

Vous pouvez suivre l’état de la vérification via la ressource des versions bêta externes. Elle indiquera quand la version du pack de ressources sera prête pour les tests externes.

Après les tests, pour rendre la version du pack de ressources disponible sur l’App Store, soumettez-la à la vérification des apps pour une distribution sur l’App Store.

Accédez à l’onglet Distribution sur App Store Connect et affichez les packs de ressources. Vous pouvez soumettre une version de pack de ressources seule ou avec d’autres packs de ressources, une version d’app et même d’autres éléments à vérifier. Si vous soumettez une version de pack de ressources et une version d’app ensemble, l’équipe vérifiera l’app selon la version du pack de ressources sélectionnée.

Pour ajouter un pack de ressources à vérifier, cliquez sur Sélectionner un pack de ressources, choisissez la version, puis ajoutez-la.

Une fois la soumission approuvée, la version du pack de ressources apparaîtra comme Prête pour la distribution.

Avec l’API App Store Connect, vous pouvez aussi soumettre l’app pour vérification via la ressource reviewSubmissions.

Vous pouvez consulter l’état de la vérification dans la ressource Versions App Store. Lorsque la distribution est prête, les utilisateurs de votre app pourront télécharger les nouvelles ressources depuis l’App Store. Nous avons abordé de nombreux sujets aujourd’hui. Nous avons parlé des packs de ressources, comment en créer un et l’utiliser dans votre app, et comment le charger et le soumettre à Apple pour hébergement. Nous espérons que cette session vous a aidé à vous familiariser avec les nouveaux Managed Background Assets.

À vous de jouer, maintenant ! Testez l’outil de packaging pour créer votre premier pack de ressources. Ensuite, si votre app utilise toujours Ressources sur requête, envisagez de migrer vers Background Assets. Consultez la documentation et adoptez les nouvelles API Background Assets dans votre app. Enfin, nous attendons vos retours. Dites-nous ce qui fonctionne et ce qui ne fonctionne pas via l’Assistant d’évaluation. Vous pouvez aussi découvrir les autres nouveautés de cette année dans App Store Connect en regardant la session « What’s new in App Store Connect ». Apprenez-en plus sur les fonctionnalités existantes Background Assets et obtenez des conseils pour les tests locaux en regardant « What’s new in Background Assets » de la WWDC23.

- Merci de nous avoir suivis. - Nous attendons vos retours avec impatience.