Comment publier une application iOS sur l'App Store en 2026 ?

Je viens de publier Macrodiet, une app de nutrition macrobiotique. Première soumission le 24 avril 2026. Approbation le 4 mai. Entre les deux : deux rejets, six guidelines à corriger, et un build (4) finalement validé. Ce guide rassemble tout ce que j'aurais aimé savoir avant de commencer — pour vous éviter mes 8 jours de ping-pong avec le Resolution Center d'Apple.

Les 6 grandes étapes pour publier sur l'App Store

Étape	Délai réaliste	Coût
Inscription Apple Developer Program	24-48h (validation)	99 USD / an
Configuration App Store Connect	1-2 jours	Inclus
Build, signing, archive Xcode	0,5 à 2 jours	Mac requis
Préparation des assets (screenshots, icône, vidéo)	2 à 5 jours	Variable
Soumission + review Apple	24h à 7 jours	Inclus
Corrections post-rejet (si rejet)	1 à 14 jours	Variable

Total réaliste pour une première soumission : 3 à 6 semaines, dont 70 % du temps passé sur la préparation et les corrections, pas sur le code lui-même.

Les pré-requis avant de commencer

Le compte Apple Developer Program (99 USD / an)

Sans ce compte, vous ne pouvez ni signer une app, ni la soumettre à l'App Store. L'inscription se fait sur developer.apple.com avec un Apple ID classique, mais Apple vous demandera :

• Une pièce d'identité valide (passeport ou carte d'identité)
• Un moyen de paiement au nom du compte
• Si vous publiez en tant qu'entreprise : un D-U-N-S Number (gratuit en France via Altares, mais comptez 30 jours pour l'obtenir la première fois)

Le compte est validé en 24 à 48h. Vous pouvez choisir entre un compte Individuel (le plus rapide, votre nom apparaît comme éditeur) ou Organisation (votre raison sociale, plus de contributeurs possibles).

Mon conseil : si vous êtes auto-entrepreneur ou freelance, commencez en compte Individuel. Vous pourrez basculer plus tard. La bascule Individuel → Organisation est pénible mais possible.

Un Mac et Xcode

Pas de raccourci possible : la signature et l'upload nécessitent un Mac. Pas de Xcode, pas d'app iOS. Comptez :

• Un Mac avec macOS récent (Sequoia ou plus pour 2026)
• Xcode dernière version stable (gratuit sur le Mac App Store, ~12 Go)
• Au moins 256 Go d'espace libre — Xcode et les simulateurs sont gourmands

Si vous n'avez pas de Mac, des services comme MacinCloud ou MacStadium louent du Mac à distance (~30 €/mois). C'est plus lent qu'un Mac local mais ça dépanne.

Le bundle ID et l'identité de l'app

Le bundle ID est l'identifiant unique de votre app (ex : app.macrodiet.macrodiet). Une fois publié, il est gravé dans la pierre : pas de renommage possible. Choisissez-le avec soin, en respectant la convention reverse-DNS (com.entreprise.app).

À préparer en parallèle :

• Un nom d'app (max 30 caractères) — pensez aux mots-clés
• Une icône 1024×1024 (sans transparence ni coins arrondis, Apple les ajoute)
• Une catégorie principale + secondaire dans App Store Connect

Le site web (privacy, support)

Apple exige deux URLs publiques dans la fiche de l'app :

1. Politique de confidentialité (URL accessible sans login, en HTTPS)
2. Page de support ou de contact

Pas de site web ? Pas d'app. Le plus simple : un domaine + un VPS minimaliste avec Nginx et certbot (5 €/mois suffisent), ou Vercel/Netlify gratuit. Pour Macrodiet, j'ai monté un site statique sur un VPS Hostinger en moins d'une heure.

Configuration dans App Store Connect

App Store Connect est le tableau de bord d'Apple où vous gérez la fiche, les builds, les abonnements et les soumissions.

Créer la fiche de l'app

Mes apps → « + » → Nouvelle app. Vous renseignez :

• Plateformes : iOS (et macOS si applicable)
• Nom : visible sur le store, max 30 caractères
• Langue principale : déclaration définitive, choisissez bien
• Bundle ID : à sélectionner depuis votre Developer Account
• SKU : identifiant interne, peu importe la valeur (ex : MACRODIET2026)
• Accès utilisateur : qui peut éditer la fiche

Préparer les métadonnées

Apple distingue les champs visibles côté store et les champs ASO/internes :

• Sous-titre (30 chars) : visible sur la fiche, indexé pour la recherche
• Description (max 4000 chars) : visible, peu pondérée pour la recherche
• Mots-clés (max 100 chars) : invisibles, gros impact sur l'ASO
• URL de support + URL de marketing + URL de privacy
• Catégorie principale + secondaire
• Note d'âge : remplissez le questionnaire honnêtement

Pour les apps d'abonnement, ajoutez en bas de description : la liste des plans, la durée, le prix, et un lien vers vos conditions et la politique de confidentialité. C'est obligatoire depuis 2024 pour les apps avec auto-renewable subscriptions.

Capturer les screenshots aux bons formats

Apple demande des screenshots pour chaque format d'écran que votre app supporte :

• 6,9 pouces (iPhone 16 Pro Max) : 1320×2868 px — obligatoire
• 6,5 pouces (iPhone 11 Pro Max) : 1242×2688 px — obligatoire
• iPad 13 pouces : 2064×2752 px — obligatoire si vous supportez l'iPad

Minimum 3 captures par format, max 10. Apple génère automatiquement les rendus pour les anciens iPhones depuis le format 6,9".

Configurer les abonnements / IAP

Pour les apps payantes, les produits IAP doivent être créés AVANT la première soumission. Path : App Store Connect → votre app → onglet Monétisation → Abonnements.

Pour chaque abonnement :

• Reference Name (interne) — différent du nom affiché
• Product ID (irrévocable une fois publié) — utilisez la même valeur que dans votre code
• Localizations — display name et description visibles côté utilisateur, différents par abonnement (un piège classique de rejet : si vos plans mensuel et annuel ont le même display name, Apple rejette)
• Prix par région

Pour l'IAP côté serveur : si votre backend valide les reçus, configurez les App Store Server Notifications V2 avec un endpoint webhook (JWS ES256, vérification de la chaîne de certificats Apple Root CA). Comptez 2-3 jours d'implémentation pour faire ça proprement.

Définir les règles de review

Apple vous demande de fournir les infos qui leur permettent de tester l'app :

• Compte de test (email + mot de passe) si l'app exige un login
• Notes pour le reviewer : un texte court qui explique comment naviguer, où trouver les features clés, etc.
• Coordonnées : email + téléphone joignables en cas de question

Mon conseil : créez un compte dédié (reviewer@votreapp.com) avec abonnement Premium activé en base. Ne laissez jamais le reviewer face à un paywall qu'il ne peut pas contourner — c'est un motif de rejet automatique (Guideline 4.1).

Le build et la soumission

Build release dans Xcode

Dans Xcode :

1. Configuration : Release (pas Debug)
2. Generic iOS Device comme cible (pas un simulateur)
3. Product → Archive pour générer un .ipa signé
4. Window → Organizer pour voir l'archive

L'archive est signée avec votre provisioning profile distribution (créé automatiquement par Xcode si vous êtes connecté à votre compte Apple Developer dans Xcode).

Upload via Transporter ou Xcode

Deux voies :

• Xcode : depuis l'Organizer, « Distribute App » → App Store Connect → Upload
• Transporter (app séparée, gratuite sur le Mac App Store) : drag & drop le .ipa

Transporter est plus fiable pour les apps lourdes (>100 Mo) et donne des erreurs plus claires en cas de problème.

L'upload prend 5 à 30 minutes selon le poids. Apple traite ensuite le build (2 à 60 minutes), puis il apparaît dans App Store Connect comme « En cours de traitement » puis « Prêt à soumettre ».

Soumettre pour review

Quand votre build est prêt :

1. Sélectionnez-le dans la fiche de version
2. Vérifiez toutes les métadonnées une dernière fois
3. Cliquez sur « Ajouter pour examen » puis « Soumettre pour examen »

L'app passe en statut « En attente d'examen » puis « En cours d'examen » quand un reviewer la prend.

La review Apple : à quoi s'attendre

Délais réels (mai 2026)

• Apps neuves : 24h à 7 jours (médiane à 48h)
• Updates : 24h à 48h
• App expedited (urgence justifiée) : 12-24h, demandable une fois par mois max

Le délai Apple est plus court qu'avant — début 2024, on était à 5-7 jours. Aujourd'hui, 80 % des reviews passent sous 48h. Mais ne soumettez jamais le vendredi : les reviews ralentissent fortement le week-end.

Le compte reviewer à fournir

Apple teste votre app avec un de leurs comptes de pool. Si votre app exige un login (Google, Apple, email), le reviewer ne peut pas en créer — vous devez fournir des credentials.

Pour Macrodiet, j'ai utilisé : apple-review@macrodiet.app / mot de passe fort, marqué Premium en base avec subscription_tier = 'yearly' pour qu'il accède à toutes les fonctionnalités sans devoir simuler un IAP.

Les 6 motifs de rejet les plus courants (avec mes fixes)

C'est ici que ça se passe vraiment. Voici les six guidelines qui ont fait recaler Macrodiet — et que je vois revenir sur 80 % des projets que j'audite.

1. Guideline 4.8 — Login Services

Cause : votre app propose Google Sign-In, Facebook Sign-In ou tout autre login tiers, mais pas Sign in with Apple.

Fix : depuis 2020, Sign in with Apple est obligatoire dès qu'un login tiers est présent. Ajoutez-le sur les écrans de signup ET de login. Le package Flutter sign_in_with_apple se branche en 30 minutes.

2. Guideline 2.3.2 — Promotional Image IAP

Cause : la « promotional image » de votre IAP est identique à votre icône d'app, ou contient le nom de l'app sans valeur ajoutée.

Fix : soit vous créez une image promotionnelle réellement différente de l'icône (avec un visuel produit), soit vous supprimez carrément le champ (il est optionnel). Dans 90 % des cas, supprimez-le.

3. Guideline 2.3.2 — IAP Display Names dupliqués

Cause : vos abonnements « Premium Mensuel » et « Premium Annuel » ont le même display name ou la même description côté Localizations (la section visible par l'utilisateur, pas le Reference Name).

Fix : différenciez les deux. Limite : 30 caractères pour le display name, 45 pour la description. Soyez explicite sur ce qui change : « 25 crédits IA / mois » vs « 400 crédits IA / an ».

4. Guideline 3.1.2(c) — Subscriptions / EULA

Cause : votre app propose un abonnement auto-renouvelable, mais vous n'avez pas de lien Terms of Use accessible depuis la fiche App Store.

Fix : ajoutez en bas de votre description App Store le bloc suivant :

Conditions d'utilisation : https://www.apple.com/legal/internet-services/itunes/dev/stdeula/
Politique de confidentialité : https://votreapp.com/privacy

Et reproduisez ces deux liens dans le paywall in-app, accessibles avant l'achat.

5. Guideline 2.1(a) — App Completeness

Cause : Apple teste sur iPad même si votre app est principalement iPhone, et trouve un bug bloquant — un bouton qui freeze, un écran qui crash, etc.

Fix : testez systématiquement sur iPad avant soumission, même si votre cible est iPhone. C'est un piège fréquent : votre code marche en iPhone parce que vous avez testé là-dessus, mais une marge ou un comportement diffère sur iPad. Pour Macrodiet, ce sont les liens « CGU » et « Confidentialité » du paywall qui freezaient sur iPad Air M3 — invisible sur iPhone.

6. Guideline 1.4.1 — Apps santé / médical / nutrition

Cause : votre app donne des conseils santé sans citations vérifiables.

Fix v1 (refusé chez Macrodiet) : un écran « Sources » caché dans le profil avec des noms d'auteurs en texte plat. Apple a re-rejeté parce qu'il n'y avait ni liens cliquables ni mention « in-context ».

Fix v2 (validé) : (a) chaque référence dans Sources est une carte cliquable avec URL visible (OMS, Harvard Nutrition Source, Anses, ouvrages de référence), (b) un bandeau citation visible sur chaque écran qui surface des conseils santé, routé vers /sources.

Règle générale : Apple veut des liens cliquables (pas juste des noms d'auteurs) ET des citations in-context (pas seulement un écran isolé). Un écran Sources caché dans le profil ne suffit pas pour passer la review santé.

Post-approval : que faire après le go-live

Le mail « Your app has been approved » tombe — bravo. Maintenant :

Surveiller les premiers crash logs

Dans App Store Connect → onglet Apple Analytics, vous voyez les sessions, les crashs, et les mises à jour. Si vous avez intégré Crashlytics ou Sentry, c'est encore mieux pour le détail des stack traces.

Les premières 24-48h post-launch sont cruciales : si un bug critique passe, vous voulez le repérer vite et soumettre une 1.0.1.

Optimiser les keywords (ASO)

L'App Store Optimization est aussi importante que le SEO web :

• Itérez sur le sous-titre (30 chars) à chaque update
• Testez différents mots-clés (max 100 chars)
• A/B testez vos screenshots via App Store Connect (feature gratuite depuis iOS 17)

Préparer les updates futures

Apple n'oblige pas à updater régulièrement, mais une app sans update depuis 2 ans est susceptible d'être retirée de la recherche. Visez une update toutes les 4 à 8 semaines, même petite.

Combien ça coûte au total ?

Poste	Coût
Apple Developer Program	99 USD / an (~95 €)
Mac (si pas déjà possédé)	À partir de 1 200 € (Mac mini)
Site web (domaine + hosting)	5-15 € / mois
Conception graphique (icône, screenshots)	0 € (vous-même) à 500 € (designer)
Backend (Supabase / Firebase)	Gratuit jusqu'à plusieurs centaines d'utilisateurs
Commission Apple sur ventes IAP	30 % la 1re année, 15 % ensuite

Mes 5 conseils issus de l'expérience Macrodiet

1. Ne soumettez jamais une première version sans avoir testé sur iPad — même si votre cible est iPhone. C'est le piège n°1.
2. Préparez un compte de review Premium avant la soumission. Pas de friction = moins de motifs de rejet.
3. Le ping-pong avec le Resolution Center est plus rapide qu'un nouveau build. Si le rejet est un malentendu, répondez par message avant de re-soumettre.
4. Anticipez la guideline 1.4.1 si votre app touche à la santé, finance, ou éducation. Citez des sources, et faites-les apparaître en contexte (pas dans un écran caché).
5. Apple expedited review est utile dans deux cas : un crash critique en prod, ou un événement timing-sensitive (lancement marketing prévu). Pas pour gagner 2 jours sur une review normale.

Questions fréquentes