Configuration requise pour le package d’application pour PWA
Spécifications
Suivez ces directives pour préparer les paquets de votre application pour les soumettre au Microsoft Store.
Avant de construire le paquet de votre application pour le Microsoft Store
Assurez-vous de tester votre application avec le Windows App Certification Kit. Nous vous recommandons également de tester votre application sur différents types de matériel. Veuillez noter que jusqu’à ce que nous certifiions votre application et qu’elle soit disponible dans Microsoft Store, celle-ci ne peut être installée et exécutée que sur des ordinateurs disposant de licences de développeur.
Construire le paquet de l’application en utilisant Microsoft Visual Studio
Si vous utilisez Microsoft Visual Studio comme environnement de développement, vous disposez déjà d’outils intégrés qui facilitent et accélèrent le processus de création d’un paquet d’application. Pour plus d’informations, consultez Empaquetage d’applications.
Remarque
Assurez-vous que tous vos noms de fichiers utilisent l’ANSI.
Lorsque vous créez votre paquet dans Visual Studio, assurez-vous d’être connecté avec le même compte associé à votre compte développeur. Certaines parties du manifeste du paquet ont des détails spécifiques liés à votre compte. Ces informations sont détectées et ajoutées automatiquement. Sans les informations supplémentaires ajoutées au manifeste, vous pourriez vous heurter à des échecs de téléchargement du paquet.
Lorsque vous construisez les paquets UWP de votre application, Visual Studio peut créer un fichier .msix ou .appx, ou un fichier .msixupload ou .appxupload. Pour les applications UWP, nous recommandons de toujours télécharger le fichier .msixupload ou .appxupload dans la page Paquets. Pour plus d’informations sur l’empaquetage des applications UWP pour le Store, veuillez consulter la section Empaqueter une application UWP avec Visual Studio.
Les paquets de votre application ne doivent pas être signés avec un certificat ayant sa racine dans une autorité de certification de confiance.
Paquets groupés
Pour les applications UWP, Visual Studio peut générer un paquet groupé (.msixbundle ou .appxbundle) pour réduire la taille de l’application que les utilisateurs téléchargent. Cela peut être utile si vous avez défini des ressources spécifiques à une langue, une variété d’actifs à différentes échelles d’image, ou des ressources qui s’appliquent à des versions spécifiques de Microsoft DirectX.
Remarque
Un paquet groupé peut contenir vos paquets pour toutes les architectures.
Avec un paquet groupé, un utilisateur téléchargera uniquement les fichiers pertinents, plutôt que toutes les ressources possibles. Pour plus d’informations sur les paquets groupés, veuillez consulter la section Empaqueter des applications et Empaqueter une application UWP avec Visual Studio.
Construire manuellement le paquet de l’application
Si vous n’utilisez pas Visual Studio pour créer votre paquet, vous devez créer votre manifeste de paquet manuellement.
Assurez-vous de consulter la documentation concernant le Manifeste de paquet d’application pour obtenir tous les détails et les conditions requises du manifeste. Votre manifeste doit suivre le schéma du manifeste de paquet pour passer la certification.
Votre manifeste doit inclure certaines informations spécifiques sur votre compte et votre application. Vous pouvez trouver ces informations en consultant la rubrique Voir les détails de l’identité de l’application dans la section Gestion du produit de la page de vue d’ensemble de votre application dans le tableau de bord.
Remarque
Les valeurs dans le manifeste sont sensibles à la casse. Les espaces et les signes de ponctuation doivent également correspondre. Saisissez les valeurs avec soin et vérifiez-les pour vous assurer qu’elles sont correctes.
Les paquets groupés (.msixbundle ou .appxbundle) utilisent un manifeste différent. Veuillez consulter la documentation intitulée Manifeste du paquet groupé concernant les détails et conditions requises des manifestes de paquets groupés. Veuillez noter que dans un .msixbundle ou .appxbundle, le manifeste de chaque paquet inclus doit utiliser les mêmes éléments et attributs, à l’exception de l’attribut ProcessorArchitecture de l’élément Identity.
Conseil
Assurez-vous d’exécuter le Kit Windows App Certification avant de soumettre vos paquets. Cela peut vous aider à déterminer si votre manifeste comporte des problèmes susceptibles de causer des échecs de certification ou de soumission.
Conditions requises pour le format du paquet
Les paquets de votre application doivent respecter ces exigences.
| Propriété du paquet d’application | Exigence |
|---|---|
| Taille du package | .msixbundle ou .appxbundle : maximum de 25 Go par paquet groupé Paquets .msix ou .appx ciblant Windows 10 ou Windows 11 : maximum de 25 Go par paquet |
| Hachages de la carte de blocs | Algorithme SHA2-256 |
Versions prises en charge
Pour les applications UWP, tous les paquets doivent cibler une version de Windows 10 ou Windows 11 prise en charge par le Store. Les versions que votre paquet prend en charge doivent être indiquées dans les attributs MinVersion et MaxVersionTested de l’élément TargetDeviceFamily du manifeste de l’application.
Fichier XML StoreManifest
StoreManifest.xml est un fichier de configuration optionnel qui peut être inclus dans les paquets d’application. Son but est de permettre des fonctionnalités que le manifeste du paquet ne couvre pas comme déclarer votre application comme une application de périphérique Microsoft Store ou déclarer des conditions requises dont un paquet dépend pour être applicable à un périphérique. Si utilisé, StoreManifest.xml est soumis avec le paquet d’application et doit être dans le dossier racine du projet principal de votre application. Pour plus d’informations, veuillez consulter la section Schema StoreManifest.
Numérotation des versions de packages
Chaque package que vous fournissez doit avoir un numéro de version (fourni comme une valeur dans l’attribut Version de l’élément Package/Identité dans le manifeste de l’application). Microsoft Store applique certaines règles relatives aux numéros de version, qui fonctionnent un peu différemment selon les versions du système d’exploitation.
Remarque
Ce sujet fait référence aux « packages », mais sauf mention contraire, les mêmes règles s’appliquent aux numéros de version pour les fichiers .msix/.appx et .msixbundle/.appxbundle.
Numérotation des versions pour les packages Windows 10 et 11
Important
Pour les packages Windows 10 ou Windows 11 (UWP), la dernière section (quatrième) du numéro de version est réservée à l’utilisation dans Microsoft Store et doit rester 0 lorsque vous construisez votre package (bien que Microsoft Store puisse changer la valeur dans cette section). Les paramètres des autres sections doivent être un nombre entier entre 0 et 65535 (sauf pour la première section, qui ne peut pas être 0).
Lorsque vous choisissez un package UWP à partir de votre soumission publiée, Microsoft Store utilisera toujours le package de la version la plus élevée applicable au dispositif Windows 10 ou Windows 11 du client. Cela vous donne une plus grande flexibilité et vous permet de contrôler quels packages seront fournis aux clients sur des types d’appareils spécifiques. Il est important de noter que vous pouvez soumettre ces packages dans n’importe quel ordre ; vous n’êtes pas limité à fournir des packages de version plus élevée à chaque soumission subséquente.
Vous pouvez fournir plusieurs packages UWP avec le même numéro de version. Cependant, les packages qui partagent un numéro de version ne peuvent pas également avoir la même architecture, car l’identité complète que Microsoft Store utilise pour chacun de vos packages doit être unique. Pour plus d’informations, veuillez consulter la section Identité.
Lorsque vous fournissez plusieurs packages UWP qui utilisent le même numéro de version, l’architecture (dans l’ordre x64, x86, Arm, neutre) sera utilisée pour décider lequel est de rang supérieur (lorsque Microsoft Store détermine quel package fournir à l’appareil d’un client). Lors du classement des lots d’applications qui utilisent le même numéro de version, le rang d’architecture le plus élevé dans le lot est choisi : un lot d’applications contenant un package x64 aura un rang supérieur à un qui contient uniquement un package x86.
Cela vous donne beaucoup de flexibilité pour faire évoluer votre application au fil du temps. Vous pouvez télécharger et soumettre de nouveaux packages utilisant des numéros de version inférieurs pour prendre en charge des dispositifs Windows 10 ou Windows 11 que vous n’avez pas précédemment pris en charge, vous pouvez ajouter des packages de version supérieure qui ont des dépendances plus strictes pour tirer parti des caractéristiques matérielles ou du système d’exploitation, ou vous pouvez ajouter des packages de version supérieure qui servent de mises à jour à une partie ou à la totalité de votre base de clients existante.
L’exemple suivant illustre comment la numérotation des versions peut être gérée pour livrer les packages destinés à vos clients sur plusieurs soumissions.
Exemple : Passer à un seul package sur plusieurs soumissions
Windows 10 vous permet d’écrire une base de code unique qui fonctionne partout. Cela rend le démarrage d’un nouveau projet multi plate-forme beaucoup plus simple. Cependant, pour un certain nombre de raisons, il est possible que vous ne souhaitiez pas fusionner les bases de code existantes pour créer un seul projet dans l’immédiat.
Vous pouvez utiliser les règles de contrôle de version des packages pour migrer progressivement vos clients vers un seul package pour la famille universelle d’appareils, tout en expédiant un certain nombre de mises à jour intermédiaires pour des familles d’appareils spécifiques (y compris celles qui tirent parti des API Windows 10). L’exemple ci-dessous illustre comment les mêmes règles sont appliquées de manière cohérente sur une série de soumissions pour la même application.
| Soumission | Contenu | Expérience du client |
|---|---|---|
| 1 | - Version du package : 1.1.10.0 - Famille d’appareils : Windows.Desktop, minVersion 10.0.10240.0 |
- Les appareils sur Windows 10 et 11 Desktop build 10.0.10240.0 et les versions ultérieures auront la version 1.1.10.0 - Les autres familles d’appareils ne pourront ni acheter ni installer l’application |
| 2 | - Version du package : 1.1.10.0 - Famille d’appareils : Windows.Desktop, minVersion 10.0.10240.0 - Version du package : 1.0.0.0 - Famille d’appareils : Windows.Universal, minVersion 10.0.10240.0 |
- Les appareils sur Windows 10 et 11 Desktop build 10.0.10240.0 et les versions ultérieures auront la version 1.1.10.0 - Les autres familles d’appareils (autres que Desktop), lorsqu’elles sont introduites, auront la version 1.0.0.0.0 - Les appareils Desktop sur lesquels l’application a déjà été installée ne verront aucune mise à jour (car ils ont déjà la meilleure version disponible : 1.1.10.0 et sont supérieurs à 1.0.0.0) |
| 3 | - Version du package : 1.1.10.0 - Famille d’appareils : Windows.Desktop, minVersion 10.0.10240.0 - Version du package : 1.1.5.0 - Famille d’appareils : Windows.Universal, minVersion 10.0.10250.0 - Version du package : 1.0.0.0 - Famille d’appareils : Windows.Universal, minVersion 10.0.10240.0 |
- Les appareils sur Windows 10 et 11 Desktop build 10.0.10240.0 et les versions ultérieures auront la version 1.1.10.0 - Les autres familles d’appareils (autres que Desktop) introduites avec la build 10.0.10250.0 et versions ultérieures obtiendront 1.1.5.0 - Les autres familles d’appareils (non de bureau) introduites avec build >=10.0.10240.0 et < 10.010250.0 obtiennent 1.1.0.0 - Les appareils Desktop sur lesquels l’application a déjà été installée ne verront aucune mise à jour (car ils ont déjà la meilleure version disponible : 1.1.10.0 qui est supérieure à 1.1.5.0 et 1.0.0.0) |
| 4 | - Version du package : 2.0.0.0 - Famille d’appareils : Windows.Universal, minVersion 10.0.10240.0 |
- Tous les clients sur toutes les familles d’appareils sur Windows 10 et 11 build v10.0.10240.0 et les versions ultérieures auront le package 2.0.0.0 |
Remarque
Dans tous les cas, les appareils des clients recevront le package ayant le numéro de version le plus élevé pour lequel ils sont éligibles. Par exemple, lors de la troisième soumission ci-dessus, tous les appareils de bureau recevront la version 1.1.10.0, même s’ils ont la version du système d’exploitation 10.0.10250.0 ou ultérieure et pourraient donc également accepter la version 1.1.5.0. Puisque 1.1.10.0 est le numéro de version le plus élevé disponible pour eux, c’est ce package qu’ils recevront.
Utiliser la numérotation des versions pour revenir à un package précédemment expédié pour de nouvelles acquisitions
Si vous conservez des copies de vos packages, vous aurez l’option de revenir à un package plus ancien de votre application dans Microsoft Store pour Windows 10 si vous découvrez des problèmes avec une version. C’est une façon temporaire de limiter les perturbations pour vos clients pendant que vous prenez le temps de résoudre le problème.
Pour cela, créez une nouvelle soumission. Retirez le package problématique et téléchargez l’ancien package que vous souhaitez proposer dans Microsoft Store. Les clients ayant déjà reçu le package auquel vous revenez auront toujours le package problématique (puisque votre package plus ancien aura un numéro de version antérieur). Mais cela empêchera personne d’autre d’acquérir le package problématique, tout en permettant à l’application d’être toujours disponible dans Microsoft Store.
Pour résoudre le problème pour les clients ayant déjà reçu le package problématique, vous pouvez soumettre un nouveau package Windows 10 ayant un numéro de version supérieur à celui du mauvais package dès que possible. Après que cette soumission ait passé le processus de certification, tous les clients seront mis à jour vers le nouveau package, puisqu’il aura un numéro de version supérieur.
Langues prises en charge
Vous pouvez soumettre des applications au Microsoft Store dans plus de 100 langues.
Pour en savoir plus sur la configuration des langues dans vos applications, veuillez consulter a section Mondialisation et localisation et Comprendre les langues des profils utilisateur et les langues du manifeste de l’application. Nous disposons également d’un Kit d’outils multilingue pour application pour vous aider à écrire des applications prenant en charge plusieurs langues.
Liste des langues prises en charge
Ce sont les langues que le Microsoft Store prend en charge. Votre application doit prendre en charge au moins une de ces langues.
Les codes de langue qui ne sont pas inclus ici ne sont pas pris en charge par Microsoft Store. Nous vous recommandons de ne pas inclure de paquets ciblant des codes de langue autres que ceux listés ci-dessous ; de tels paquets ne seront pas distribués aux clients et peuvent causer des retards ou des échecs dans la certification.
| Nom de la langue | Codes des langues prises en charge |
|---|---|
| Arabe | ar, ar-sa, ar-ae, ar-bh, ar-dz, ar-eg, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sy, ar-tn, ar-ye |
| Afrikaans | af, af-za |
| Albanais | sq, sq-al |
| Amharique | am, am-et |
| Arménien | hy, hy-am |
| Assamais | as, as-in |
| Azéri | az-arab, az-arab-az, az-cyrl, az-cyrl-az, az-latn, az-latn-az |
| Basque (Basque) | eu, eu-es |
| Biélorusse | be, be-by |
| Bangla | bn, bn-bd, bn-in |
| Bosniaque | bs, bs-cyrl, bs-cyrl-ba, bs-latn, bs-latn-ba |
| Bulgare | bg, bg-bg |
| Catalan | ca, ca-es, ca-es-valencia |
| Cherokee | chr-cher, chr-cher-us, chr-latn |
| Chinois (simplifié) | zh-Hans, zh-cn, zh-hans-cn, zh-sg, zh-hans-sg |
| Chinois (traditionnel) | zh-Hant, zh-hk, zh-mo, zh-tw, zh-hant-hk, zh-hant-mo, zh-hant-tw |
| Croate | hr, hr-hr, hr-ba |
| Tchèque | cs, cs-cz |
| Danois | da, da-dk |
| Dari | prs, prs-af, prs-arab |
| Néerlandais | nl, nl-nl, nl-be |
| Anglais | en, en-au, en-ca, en-gb, en-ie, en-in, en-nz, en-sg, en-us, en-za, en-bz, en-hk, en-id, en-jm, en-kz, en-mt, en-my, en-ph, en-pk, en-tt, en-vn, en-zw, en-053, en-021, en-029, en-011, en-018, en-014 |
| Estonien | et, et-ee |
| Filipino | fil, fil-latn, fil-ph |
| Finnois | fi, fi-fi |
| Français | fr, fr-be , fr-ca , fr-ch , fr-fr , fr-lu, fr-015, fr-cd, fr-ci, fr-cm, fr-ht, fr-ma, fr-mc, fr-ml, fr-re, frc-latn, frp-latn, fr-155, fr-029, fr-021, fr-011 |
| Galicien | gl, gl-es |
| Géorgien | ka, ka-ge |
| Allemand | de, de-at, de-ch, de-de, de-lu, de-li |
| Grec | el, el-gr |
| Goudjrati | gu, gu-in |
| Hausa | ha, ha-latn, ha-latn-ng |
| Hébreu | he, he-il |
| Hindi | hi, hi-in |
| Hongrois | hu, hu-hu |
| Islandais | is, is-is |
| Igbo | ig-latn, ig-ng |
| Indonésien | id, id-id |
| Inuktitut (Latin) | iu-cans, iu-latn, iu-latn-ca |
| Irlandais | ga, ga-ie |
| isiXhosa | xh, xh-za |
| Zoulou | zu, zu-za |
| Italien | it, it-it, it-ch |
| Japonais | ja, ja-jp |
| Kannada | kn, kn-in |
| Kazakh | kk, kk-kz |
| Khmer | km, km-kh |
| Quiché | quc-latn, qut-gt, qut-latn |
| Kinyarwanda | rw, rw-rw |
| KiSwahili | sw, sw-ke |
| Konkani | kok, kok-in |
| Coréen | ko, ko-kr |
| Kurde | ku-arab, ku-arab-iq |
| Kirghiz | ky-kg, ky-cyrl |
| Lao | lo, lo-la |
| Letton | lv, lv-lv |
| Lituanien | lt, lt-lt |
| Luxembourgeois | lb, lb-lu |
| Macédonien | mk, mk-mk |
| Malais | ms, ms-bn, ms-my |
| Malayalam | ml, ml-in |
| Maltais | mt, mt-mt |
| Maori | mi, mi-latn, mi-nz |
| Marathi | mr, mr-in |
| Mongole (cyrillique) | mn-cyrl, mn-mong, mn-mn, mn-phag |
| Népalais | ne, ne-np |
| Norvégien | nb, nb-no, nn, nn-no, no, no-no, |
| Odia | or, or-in |
| Persan | fa, fa-ir |
| Polonais | pl, pl-pl |
| Portugais (Brésil) | pt-br |
| Portugais (Portugal) | pt, pt-pt |
| Pendjabi | pa, pa-arab, pa-arab-pk, pa-deva, pa-in |
| Quechua | quz, quz-bo, quz-ec, quz-pe |
| Roumain | ro, ro-ro |
| Russe | ru, ru-ru |
| Gaélique écossais | gd-gb, gd-latn |
| Serbe (latin) | sr-Latn, sr-latn-cs, sr, sr-latn-ba, sr-latn-me, sr-latn-rs |
| Serbe (cyrillique) | sr-cyrl, sr-cyrl-ba, sr-cyrl-cs, sr-cyrl-me, sr-cyrl-rs |
| Sotho du Nord | nso, nso-za |
| Setswana | tn, tn-bw, tn-za |
| Sindhi | sd-arab, sd-arab-pk, sd-deva |
| Cingalais | si, si-lk |
| Slovaque | sk, sk-sk |
| Slovène | sl, sl-si |
| Espagnol | es, es-cl, es-co, es-es, es-mx, es-ar, es-bo, es-cr, es-do, es-ec, es-gt, es-hn, es-ni, es-pa, es-pe, es-pr, es-py, es-sv, es-us, es-uy, es-ve, es-019, es-419 |
| Suédois | sv, sv-se, sv-fi |
| Tadjik (cyrillique) | tg-arab, tg-cyrl, tg-cyrl-tj, tg-latn |
| Tamoul | ta, ta-in |
| Tatar | tt-arab, tt-cyrl, tt-latn, tt-ru |
| Télougou | te, te-in |
| Thaï | th, th-th |
| Tigrigna | ti, ti-et |
| Turc | tr, tr-tr |
| Turkmène | tk-cyrl, tk-latn, tk-tm, tk-latn-tr, tk-cyrl-tr |
| Ukrainien | uk, uk-ua |
| Ourdou | ur, ur-pk |
| Ouïgour | ug-arab, ug-cn, ug-cyrl, ug-latn |
| Ouzbek (latin) | uz, uz-cyrl, uz-latn, uz-latn-uz |
| Vietnamien | vi, vi-vn |
| Gallois | cy, cy-gb |
| Wolof | wo, wo-sn |
| Yoruba | yo-latn, yo-ng |
Windows developer