Contrairement à Google, Apple ne retire pas votre app du store parce qu'elle est ancienne. La contrainte arrive au moment où vous voulez publier quelque chose. Depuis le 28 avril 2026, toute app envoyée à App Store Connect doit être construite avec Xcode 26 et un SDK iOS 26, iPadOS 26, tvOS 26, visionOS 26 ou watchOS 26.
Dit autrement : une app qui n'a pas bougé depuis le printemps 2026 ne peut plus sortir la moindre correction sans une remise à niveau préalable.
Le vrai sujet n'est pas Xcode, c'est le design
Recompiler avec le SDK iOS 26 ne change pas seulement la boîte à outils. Les composants standard adoptent automatiquement le nouveau look d'iOS 26, et cela se voit : barres, onglets, champs, feuilles modales, tout ce qui était dessiné par le système prend la nouvelle apparence. Une app dont l'interface a été pensée autour des anciens composants peut se retrouver avec des écrans corrects sur le papier et bancals à l'usage.
Apple a prévu une soupape : une clé à ajouter dans la configuration de l'app pour demander l'ancien rendu. Elle est explicitement temporaire, et Apple indique qu'elle sera ignorée par les SDK de la génération suivante. C'est un sursis d'un an, pas une solution.
Ce qu'il faut en retenir pour planifier : la mise à jour technique prend quelques jours, la relecture écran par écran prend souvent plus longtemps, surtout sur une app avec beaucoup de formulaires et de listes.
L'autre règle, celle qu'on oublie
Apple évalue aussi les apps qui dorment. Les apps qui n'ont pas été mises à jour depuis plus de trois ans et qui sont très peu téléchargées sur douze mois glissants reçoivent un avis de retrait possible. Quand un problème est signalé, le développeur dispose de 90 jours pour envoyer une mise à jour, faute de quoi l'app est retirée. Et une app qui plante au lancement est retirée immédiatement, sans délai.
Une app installée régulièrement n'est donc pas menacée par son âge. Une app confidentielle et figée, si.
Par quoi commencer
Dans l'ordre où je le fais sur une app que je découvre :
- vérifier qu'elle compile encore, sur une machine propre, avec les certificats et profils à jour ;
- monter la version de Xcode et du SDK, et régler ce qui casse dans les dépendances ;
- lancer l'app sur un iPhone récent et parcourir les écrans principaux avec le nouveau rendu ;
- décider, écran par écran, ce qui est corrigé maintenant et ce qui attend la refonte suivante ;
- publier, puis regarder les crashs les jours qui suivent.
Le point 3 est celui qu'on saute et qu'on regrette.
Si vous voulez de l'aide
Je prends ce genre de mise à niveau de bout en bout, sur iOS et sur Android, avec la publication et un compte rendu simple. Les dates et les règles sont résumées sur la page Mise à jour et conformité des stores. Si la question est plus large que la conformité, l'audit en cinq jours donne l'état réel de l'app.
Sources officielles : Upcoming requirements chez Apple, la clé UIDesignRequiresCompatibility et App Store Improvements.