De la conception SwiftUI à l’App Store en quelques semaines

Un type de retard bien précis touche les projets iOS : la fonctionnalité qui devait être livrée « en quelques semaines » et qui est toujours en développement trois mois plus tard parce que le périmètre n’a cessé de s’élargir et que le processus de soumission s’est avéré avoir plus d’étapes que prévu. En réalité, livrer rapidement une application SwiftUI n’est pas une question de vitesse de développement – il faut décider tôt ce que l’application ne va pas faire, puis ne pas remettre en question cette décision lorsque la tentation d’ajouter une fonctionnalité de plus apparaît.

Nous avons livré plusieurs applications SwiftUI dans des délais courts. Le processus est reproductible, mais il nécessite de la rigueur dans la gestion du périmètre, une bonne compréhension du pipeline de soumission Apple, et la volonté de publier quelque chose de bon mais pas de complet. Voici à quoi cela ressemble en pratique.

Le périmètre se définit avant le premier commit

Le travail le plus important dans un cycle de publication iOS rapide se fait avant l’écriture de tout code. La question n’est pas « que devrait faire cette application ? » mais « quel est le seul problème que cette application résout pour l’utilisateur dans la version un ? » Chaque fonctionnalité qui n’est pas directement liée à ce problème relève de la version deux.

C’est plus difficile qu’il n’y paraît parce que presque tout semble pertinent lorsque vous partez des principes fondamentaux pour concevoir le produit. Les notifications semblent importantes. Les fonctionnalités sociales semblent importantes. Les tableaux de bord analytiques détaillés semblent importants. Mais en réalité, les utilisateurs ne peuvent évaluer aucune de ces fonctionnalités tant qu’ils n’ont pas utilisé la fonction principale de l’application et l’ont jugée utile. Une application qui fait une chose bien et est publiée en quatre semaines génère plus de retours utiles qu’une application qui fait six choses de manière acceptable et est publiée en quatre mois.

L’outil pratique pour cela est une liste à deux colonnes écrite avant le début du développement : ce qui est dans le MVP, et ce qui est explicitement différé. La liste des fonctionnalités différées n’est pas un backlog – c’est un outil qui impose des choix. Pour chaque fonctionnalité ajoutée à un projet en cours, demandez-vous si elle devrait être différée plutôt qu’intégrée au sprint actuel. La plupart d’entre elles le devraient.

Les deux premières semaines : uniquement les écrans principaux

Une application SwiftUI avec un seul objectif clair nécessite généralement trois à cinq écrans pour fonctionner : un parcours de prise en main, un ou deux écrans d’interaction principaux, et un écran de paramètres ou de compte. Dans les deux premières semaines, ces écrans devraient atteindre un fonctionnement complet – ils remplissent leur fonction, avec des données réelles, dans le bon ordre. Ils n’ont pas besoin d’être peaufinés. Les animations peuvent utiliser les valeurs système par défaut. La typographie peut être ce que le système fournit. Les états d’erreur peuvent être de simples alertes textuelles.

Les décisions architecturales qui comptent dans cette phase sont celles qui sont difficiles à changer ultérieurement : le modèle de navigation (NavigationStack, TabView ou un coordinateur personnalisé), l’approche de gestion d’état (utiliser @Observable du framework Observation, ou rester avec ObservableObject), et la stratégie de persistance des données (SwiftData, Core Data, UserDefaults pour un état simple). Prendre ces décisions explicitement et tôt – plutôt que de les laisser se dessiner au fil du développement – évite la situation en semaine trois où la moitié de l’application utilise un modèle de navigation et l’autre moitié en utilise un autre.

Pour les applications intégrant un backend Supabase, le flux d’authentification mérite une attention particulière dans cette phase. Les consignes de validation des applications d’Apple distinguent deux exigences : les applications qui permettent de créer un compte doivent aussi permettre aux utilisateurs de le supprimer depuis l’application (règle 5.1.1(v)), et celles qui utilisent une connexion tierce ou sociale, comme Google Sign-In, pour le compte principal doivent également proposer une option de connexion équivalente axée sur la confidentialité, qui est généralement Sign in with Apple en pratique (règle 4.8). Si votre application utilise uniquement son propre système d’authentification par email et mot de passe via Supabase, Sign in with Apple n’est pas obligatoire, mais le flux de suppression de compte doit être dans le MVP – pas parce que les utilisateurs l’utiliseront dès le premier jour, mais parce que l’App Review rejettera l’application sans lui. Si vous ajoutez une connexion sociale, prévoyez en même temps l’option de connexion équivalente.

Semaines trois et quatre : finitions et TestFlight

La troisième semaine est le moment où l’application commence à ressembler à un vrai produit. C’est là que vous traitez les états de chargement (pas seulement « afficher un indicateur de chargement » mais « afficher un indicateur de chargement qui rend l’attente compréhensible »), les états vides (ce que l’application montre lorsqu’il n’y a pas encore de données) et les états d’erreur (ce qui se passe lorsqu’un appel réseau échoue). Ce ne sont pas de simples finitions – c’est l’expérience des nouveaux utilisateurs, qui arrivent sans données et ont parfois des problèmes de réseau.

La distribution TestFlight devrait commencer en semaine trois, pas en semaine quatre. La raison est que la première compilation que vous envoyez aura des problèmes que vous n’aviez pas anticipés. App Store Connect valide le binaire avant de le rendre disponible pour les tests, et il détecte des problèmes – habilitations manquantes, mauvaises combinaisons de profils de provisionnement, clés Info.plist requises mais absentes – que la compilation locale dans Xcode ne détecte pas. Rencontrer ces problèmes en semaine trois vous laisse du temps pour les corriger avant la vraie soumission. Les rencontrer la veille de votre lancement souhaité ne le permet pas.

Les retours TestFlight à ce stade sont les plus utiles pour identifier la confusion de navigation et les éléments d’interface dont l’usage n’est pas évident, pas pour les demandes de fonctionnalités. Demandez aux testeurs : « Y avait-il quelque chose que vous avez essayé de faire que vous n’avez pas réussi à comprendre comment faire ? » plutôt que « Quelles fonctionnalités aimeriez-vous voir ? » Cette dernière question produira une liste qui rallongerait le calendrier de plusieurs mois.

Le processus de soumission App Store

Le processus de soumission App Store a plus d’étapes que les développeurs qui soumettent leur première application ne s’y attendent, et chaque étape a le potentiel de bloquer la publication. Anticiper ces étapes – plutôt que de les commencer lorsque l’application est terminée côté code – empêche la dernière semaine de devenir une course effrénée.

Les captures d’écran sont requises avant la soumission et doivent correspondre à l’une des dimensions en pixels acceptées pour chaque taille d’écran. En octobre 2026, App Store Connect exige des captures d’écran d’iPhone pour la catégorie d’écrans de 6,9 pouces (par exemple, iPhone 16 Pro Max), ou pour celle de 6,5 pouces (par exemple, iPhone 14 Plus) si vous ne fournissez pas de captures de 6,9 pouces, ainsi que des captures d’iPad de 13 pouces (par exemple, iPad Pro (M4) ou iPad Pro de 12,9 pouces (6e génération)) si l’application fonctionne sur iPad. Les générer dans le Simulateur est simple mais chronophage si vous le laissez au dernier jour. Une configuration Fastlane snapshot simple peut automatiser cela.

La section consacrée à la confidentialité de l’application dans App Store Connect vous demande de déclarer chaque type de données que votre application collecte, à quoi elles servent, et si elles sont liées à l’identité de l’utilisateur. Ce ne sont pas des métadonnées optionnelles – la soumission échoue si elles sont incomplètes. Si votre application utilise Supabase avec authentification, vous collectez au minimum des adresses e-mail et des identifiants utilisateur, qui nécessitent tous deux une déclaration. Les SDK tiers et les outils d’analyse s’ajoutent à cette liste. Cartographier avec précision vos collectes de données avant la soumission évite d’avoir à mettre à jour ces détails après le lancement.

Apple indique examiner généralement 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures ; un examen accéléré peut être demandé dans des circonstances exceptionnelles, comme la correction d’un bug critique ou un lancement lié à un événement. L’examen est effectué par une personne qui évalue l’application au regard des consignes d’Apple. Les raisons de rejet les plus courantes lors de la première soumission sont : fonctionnalité de compte manquante (suppression du compte depuis l’application ou option de connexion équivalente en complément d’une connexion sociale), identifiants de compte de démonstration non fournis pour les applications avec connexion, et plantages dans des cas limites que les testeurs n’ont pas rencontrés mais que les examinateurs ont rencontrés.

Quelles fonctionnalités retirer et comment le faire

La partie la plus difficile d’un cycle de publication rapide est de faire en sorte que les choix de réduction du périmètre paraissent intentionnels plutôt que précipités. Les utilisateurs peuvent faire la différence entre une application délibérément simple et une application inachevée. La différence tient principalement au caractère abouti de ce qui est présent – chaque écran existant devrait être complet – plutôt qu’au nombre d’écrans existants.

Éléments que l’on peut généralement retirer sans nuire à une première version : les notifications push (complexes à configurer correctement, et les utilisateurs ont besoin de faire confiance à l’application avant que les notifications soient les bienvenues), les fonctionnalités sociales (suivre, partager, classements – utiles à grande échelle, distrayantes au lancement), les paramètres de personnalisation avancés (la plupart des utilisateurs ne changent jamais les valeurs par défaut), et toute fonctionnalité nécessitant une infrastructure backend significative dont le MVP n’a pas déjà besoin.

Éléments dont le retrait nuit à une première version : la gestion des erreurs (une application qui plante lors d’un délai d’expiration réseau frustre les utilisateurs de manière permanente), les états de chargement (une application qui se fige sans retour visuel semble cassée), et les bases de gestion de compte (les utilisateurs doivent pouvoir réinitialiser leur mot de passe et supprimer leur compte, même dans le MVP).

Après le lancement : les deux premières semaines comptent le plus

Les deux premières semaines après le lancement sont la période où les évaluations App Store sont les plus fragiles. Un premier groupe d’évaluations à une étoile dues à un plantage qui n’est pas apparu lors des tests est disproportionnellement dommageable pour la note à long terme d’une application. Instruments et la section consacrée aux plantages dans l’Organizer de Xcode devraient être vérifiés quotidiennement la première semaine. Une version corrective traitant tout plantage critique devrait être soumise dans les 24 heures suivant l’identification – App Review offre une procédure accélérée pour les correctifs de plantage.

Il vaut mieux résister pendant au moins deux semaines à l’envie de livrer les fonctionnalités différées immédiatement après le lancement. Comprendre comment les utilisateurs interagissent réellement avec l’expérience principale avant d’ajouter de la complexité est plus précieux que d’afficher un rythme soutenu. Les fonctionnalités de la version deux sur la liste différée seront mieux conçues après deux semaines d’observation des usages réels qu’elles ne l’auraient été si elles avaient été construites en parallèle avec le lancement.

Ressources connexes

• Corriger les rejets d’icônes App Store – Les exigences sRGB, canal alpha et TrueColor qui bloquent la soumission à la dernière étape.
• Créer une application de préparation aux examens avec des milliers de questions – À quoi ressemble l’architecture lorsque le MVP doit à terme évoluer vers un produit complet.
• Concurrence Swift 6 : guide de migration pratique – Quand traiter les avertissements de concurrence Swift 6 pendant un cycle de publication rapide et quand les différer.