Comment gérer les limites de téléversement d’On-Demand Resources en 2027 ? 2026

La migration d’On-Demand Resources vers Background Assets est la voie à préparer pour les nouvelles applications et celles qui n’ont jamais utilisé ODR : avant le début de la restriction, retirez les ressources ODR des envois concernés et validez le nouveau parcours dans Xcode. Cette règle ne signifie pas que toutes les applications existantes utilisant ODR s’arrêteront immédiatement ; leurs équipes doivent toutefois commencer à évaluer la migration.

Cet article s’adresse aux développeurs iOS et de jeux qui doivent vérifier si leur projet entre dans le périmètre de la restriction.
Il concerne aussi les ingénieurs chargés du téléchargement des ressources, de l’intégration continue et des tests de distribution.
Nous distinguons ici les règles confirmées par Apple des recommandations de migration propres à chaque projet.

Dernière mise à jour : 12 novembre 2026. Vérification effectuée à partir des notes de version d’App Store Connect et de la documentation Apple sur ODR, Background Assets et les tests locaux.

La limite d’envoi ne signifie pas l’arrêt immédiat des applications ODR

La règle porte sur l’acceptation de certains envois à App Store Connect, pas sur une désactivation immédiate de toutes les applications qui utilisent déjà On-Demand Resources. Apple indique qu’à partir du début de 2027, les envois contenant des ressources ODR ne seront plus acceptés lorsqu’ils proviennent d’une nouvelle application ou d’une application qui n’a jamais utilisé ODR. La date exacte n’est pas publiée dans l’annonce consultée : il faut donc suivre la documentation officielle, plutôt que planifier autour d’un jour supposé. Les notes d’App Store Connect sur les limites de taille des ressources ODR précisent le périmètre à vérifier.

Apple annonce également la dépréciation d’ODR à partir d’iOS 27, iPadOS 27, tvOS 27 et visionOS 27, avec une recommandation de migration vers Background Assets. Cette dépréciation de plateforme et la restriction d’envoi sont deux sujets liés, mais distincts. Apple indique que les applications ayant déjà utilisé ODR peuvent continuer à fonctionner à court terme ; cela ne constitue pas une garantie que chaque futur changement de système ou de distribution sera sans conséquence. La documentation de référence de NSBundleResourceRequest décrit l’ancienne API, mais ne transforme pas cette règle de téléversement en arrêt instantané des projets existants.

Attention : une compilation qui réussit ne prouve pas qu’un envoi futur respectera les conditions d’App Store Connect. Le critère à examiner est l’application réellement envoyée, son historique ODR et son contenu, pas seulement l’état du projet dans Xcode.

Vérifiez d’abord si votre projet est concerné

L’erreur la plus coûteuse consiste à déduire l’éligibilité à partir du seul code source actuel. Une équipe peut avoir supprimé un ancien appel, tout en conservant des ressources ou un réglage de paquet hérité. À l’inverse, un ancien dépôt peut contenir un répertoire inutilisé qui n’est plus intégré à l’archive. Il faut rapprocher trois éléments : la configuration du projet, le produit d’archive et l’historique des versions distribuées.

La restriction annoncée concerne la situation de l’application telle qu’elle est définie par Apple, notamment le fait qu’elle ait ou non utilisé ODR auparavant. Nous vous recommandons de documenter la preuve retenue pour cette classification : numéro de version concerné, archive inspectée, paramètres de ressources et historique de distribution. Cela évite qu’une décision de migration repose sur une supposition transmise oralement entre équipes.

Quand l’envoi d’On-Demand Resources à App Store Connect sera-t-il restreint ?

Apple situe le changement au début de 2027 pour les nouvelles applications et celles qui n’ont jamais utilisé ODR, dès lors que l’envoi contient des ressources ODR. L’annonce ne fournit pas de date précise : ne convertissez donc pas « début 2027 » en échéance quotidienne dans votre plan de livraison. Consultez à nouveau la page officielle avant de fixer une date de bascule ou de gel.

Le fait qu’un projet utilise une version récente de Xcode ne suffit pas non plus à démontrer que son envoi entre ou non dans le périmètre. Ce sont l’usage historique d’ODR et le contenu remis à App Store Connect qu’il faut établir. La vérification de l’archive doit donc faire partie du contrôle de publication, au même titre que la validation des ressources et des métadonnées.

Une checklist de qualification avant de modifier le projet

• [ ] Relevez dans les réglages de la cible si la gestion d’ODR est activée ou si des ressources associées sont déclarées.
• [ ] Recherchez les appels à NSBundleResourceRequest, y compris dans les bibliothèques internes et les composants partagés.
• [ ] Inspectez une archive représentative et confirmez si elle embarque des ressources ODR ou des éléments de gestion associés.
• [ ] Vérifiez l’historique des versions réellement envoyées et distribuées ; la présence de code ancien dans Git ne prouve pas, à elle seule, un usage antérieur.
• [ ] Faites consigner par l’équipe de publication la conclusion : nouvelle application, application sans usage antérieur établi, ou application ayant déjà utilisé ODR.
• [ ] Si les éléments sont ambigus, suspendez l’adoption d’ODR pour un nouveau flux et demandez une vérification auprès de la personne responsable de la distribution.

Ces vérifications sont particulièrement importantes pour les jeux et les applications créatives. Un niveau téléchargeable, une bibliothèque audio ou un ensemble de médias haute résolution peut être associé à une logique d’accès, de progression ou de téléchargement distincte. Il faut donc repérer les règles produit attachées aux ressources, pas seulement leurs noms de fichiers.

La migration remplace un cycle de ressources, pas une API par une autre

NSBundleResourceRequest participe à l’ancien modèle de demande de ressources ODR. Background Assets utilise un autre dispositif de téléchargement et de mise à disposition. On ne peut donc pas considérer la migration comme un renommage mécanique de classes ou un convertisseur automatique de balises. Les appels, les états visibles par l’application, les règles de rétention et les réactions aux échecs doivent être revus ensemble.

Background Assets remplace-t-il directement NSBundleResourceRequest ?

Non. Les ressources doivent être reclassées selon leur rôle et leur disponibilité attendue, puis associées à une stratégie de paquets d’assets. La documentation Apple présente la création de paquets gérés dans la configuration de Managed Asset Packs. Elle ne décrit pas une correspondance automatique entre chaque ancienne balise ODR et un nouveau paquet.

Commencez par établir une table de correspondance fonctionnelle, pas seulement technique :

Pour chaque ancienne demande, notez le déclencheur, la ressource attendue, l’écran ou la tâche qui en dépend et le comportement en cas d’échec. Une fonction peut actuellement attendre une réponse ODR avant d’afficher un niveau ; après migration, elle doit toujours savoir distinguer « téléchargement demandé », « contenu disponible localement » et « téléchargement non abouti ». Ne liez pas l’accès à une ressource au seul fait d’avoir déclenché son téléchargement.

Pour une application de création audio, vidéo ou de conception, testez aussi les parcours interrompus : un projet peut être techniquement disponible, mais inutilisable si une séquence, un échantillon ou un média nécessaire n’est pas encore présent localement.

Le mode d’hébergement détermine qui exploite le paquet

Managed Background Assets et un projet unmanaged/self-hosted ne confient pas les mêmes responsabilités à l’équipe. Dans le premier cas, l’application s’appuie sur des paquets gérés et un flux Apple-hosted à configurer. Dans le second, l’équipe doit aussi prendre en charge son organisation d’hébergement et les paramètres nécessaires au projet. Les besoins de contrôle, de maintenance et de publication doivent peser davantage que l’habitude de réutiliser l’ancienne structure ODR.

Pour une équipe qui ne veut pas exploiter séparément l’hébergement des ressources, Managed Background Assets est une option à évaluer en premier, pas une réponse automatique. Pour une équipe qui doit maîtriser davantage le cycle de publication de ses paquets, le modèle self-hosted peut mieux correspondre à son exploitation, au prix d’une responsabilité supplémentaire. Dans les deux cas, l’application doit avoir une stratégie claire pour confirmer qu’un asset pack est effectivement disponible en local avant de lancer le contenu qui en dépend.

Validez le parcours complet dans Xcode et dans la distribution

Un test réussi du code de téléchargement n’établit pas que l’application et ses paquets sont correctement associés dans le processus de distribution. À l’inverse, un paquet téléversé ne prouve pas que l’interface gère correctement un téléchargement absent ou interrompu. Nous conseillons de valider séparément la construction des paquets, leur comportement local, leur association au produit et le parcours de test réellement utilisé par l’équipe.

Comment tester localement des Background Assets dans Xcode ?

Apple fournit un serveur simulé local pour exercer le comportement des asset packs avant de dépendre d’un déploiement distribué. Suivez les étapes décrites dans le guide officiel consacré aux tests locaux des asset packs. Un résultat local sert à examiner le comportement de l’application dans cette configuration ; il ne constitue pas une approbation d’App Store ni une preuve que toute la chaîne de distribution est valide.

Procédez dans cet ordre :

• [ ] Cartographiez l’ancien parcours. Listez les balises ODR, les appels NSBundleResourceRequest, les états de téléchargement et les écrans qui attendent une ressource.
• [ ] Définissez le découpage cible. Regroupez les fichiers selon le moment où ils doivent devenir disponibles, plutôt que de recopier les anciennes balises.
• [ ] Construisez les paquets avec la configuration retenue. Vérifiez que les ressources attendues sont présentes, nommées correctement et rattachées au bon projet.
• [ ] Exercez les états locaux. Utilisez le serveur simulé fourni avec Xcode pour contrôler la demande, la disponibilité locale et le comportement de l’application quand le contenu n’est pas immédiatement prêt.
• [ ] Testez les erreurs et les reprises. Vérifiez que l’application ne traite pas un téléchargement demandé comme un téléchargement achevé et que l’interface propose un état cohérent en cas d’échec.
• [ ] Contrôlez l’archive de l’application. Confirmez que le produit remis contient le bon code et qu’il n’embarque pas par inadvertance le parcours ODR que vous cherchiez à retirer.
• [ ] Rejouez le flux de distribution du projet. Pour Apple-hosted, suivez les instructions de téléversement et le parcours de test prévu ; le guide de test des paquets Apple-hosted avec TestFlight décrit cette étape.
• [ ] Consignez les résultats. Gardez ensemble la version de Xcode utilisée, l’identification de l’archive, le résultat des scénarios de ressources et la validation de distribution, afin de pouvoir comparer les essais suivants.

Si le serveur local fonctionne mais que le parcours distribué échoue, séparez le diagnostic par frontière : construction du paquet, association à l’application, téléversement, puis téléchargement dans le scénario de test. Ne corrigez pas au hasard le code d’interface avant d’avoir établi à quelle étape le paquet cesse d’être disponible.

Dans une chaîne CI, conservez également les éléments qui rendent l’essai reproductible : paramètres de construction, scripts de génération, résultats de tests et version de l’application examinée. La liste exacte dépend de votre pipeline ; l’objectif est de pouvoir répondre, pour chaque échec, à une question précise : le paquet a-t-il été généré, correctement associé, accepté par le flux de publication et rendu accessible au client de test ?

Organisez la bascule par risque, pas par date supposée

Pour une nouvelle application ou un projet sans usage ODR antérieur, n’ajoutez pas le mécanisme historique au seul motif qu’il paraît déjà familier à l’équipe. Construisez le parcours avec Background Assets et vérifiez tôt comment il se comporte en local, dans l’archive et dans la distribution prévue. Cela réduit le risque de découvrir une contrainte de publication après que le format des ressources et la logique produit ont été intégrés partout.

Pour une application qui a déjà utilisé ODR, la première décision n’est pas nécessairement de tout réécrire immédiatement. Dressez l’inventaire, mesurez les dépendances fonctionnelles, identifiez les modules qui exigent encore l’ancien cycle et définissez une migration par parcours. Si plusieurs versions ou équipes partagent les mêmes assets, documentez les responsabilités de génération et de publication avant de changer le format.

Les projets avec un catalogue audio ou vidéo, des niveaux de jeu et des ressources de conception doivent notamment vérifier trois points : la disponibilité au moment d’usage, le comportement d’un téléchargement interrompu et la cohérence entre la version de l’application et celle des paquets. Une mise à jour du contenu qui ne correspond plus à la logique embarquée peut produire un défaut difficile à reproduire. Le plan de test doit donc couvrir les ressources indispensables au premier usage comme celles que l’utilisateur obtient plus tard.

Pour l’exploitation, attribuez un responsable à chaque frontière : génération des paquets, hébergement, envoi, test de distribution et diagnostic côté application. Sans cette répartition, l’équipe risque de traiter un problème de publication comme un bogue de téléchargement, ou un défaut de disponibilité locale comme un incident d’hébergement. La migration est une évolution de l’architecture de livraison, pas seulement une tâche de nettoyage dans le dépôt.

Enfin, réexaminez les consignes officielles juste avant de fixer une échéance de livraison. La restriction est annoncée pour le début de 2027, sans date précise dans la source citée ; toute date interne doit donc être présentée comme un jalon de projet, et non comme la date officielle d’entrée en vigueur.

Si votre validation exige Xcode et une machine macOS dédiée, comparez d’abord les options selon la durée et la fréquence des essais. Un environnement Linux ne remplace pas le flux de compilation et de validation macOS requis ; un Mac local peut, de son côté, être indisponible pour une équipe ou mobilisé par d’autres tâches. Pour des tests de migration ponctuels ou une phase de publication, la location d’un Mac distant peut éviter cet achat, tout en conservant une dépendance au réseau et sans remplacer un poste local lorsqu’un accès physique est nécessaire. Vous pouvez consulter les environnements Mac proposés par metalvnc, puis comparer les modalités sur la page des offres. Pour un usage intensif et continu, évaluez aussi le coût total d’un Mac dédié plutôt que de supposer que la location est toujours préférable.