Liquid Glass sur iOS 26 : votre application doit-elle s'adapter, et avant quand ?

Depuis l’automne 2025, chaque iPhone à jour affiche ses menus, ses barres et ses boutons en verre. Les applications qui ont suivi s’y fondent, les autres se repèrent au premier coup d’œil. Si vous possédez une application mobile sur l’App Store, voici ce qui change pour elle, ce qui arrive tout seul à la prochaine mise à jour, et la date après laquelle il ne sera plus possible de reculer.

Qu’est-ce que Liquid Glass, la nouvelle apparence d’iOS 26 ?

Liquid Glass est le nouveau langage visuel d’Apple, arrivé avec iOS 26 : barres de navigation, barres d’onglets, boutons, menus et fenêtres modales prennent l’aspect d’un verre translucide qui flotte au-dessus du contenu. Apple l’a présenté en septembre 2025 comme sa refonte de design la plus large à ce jour.

Liquid Glass est un matériau visuel d’Apple qui donne aux éléments de navigation et de commande l’apparence d’un verre vivant, qui laisse voir le contenu défiler dessous et s’adapte en temps réel à ce qu’il recouvre, tout en restant lisible.

Ce qu’un utilisateur voit changer :

• La navigation flotte. Les barres d’onglets et les barres du haut se détachent du contenu, qui reste visible par transparence quand il défile dessous.
• Les commandes s’arrondissent. Le bouton d’un curseur se transforme même en verre pendant qu’il est manipulé.
• Les fenêtres modales changent de forme. Leurs coins s’arrondissent et, à mi-hauteur, elles se décollent des bords de l’écran.
• Les listes respirent, avec plus de hauteur de ligne et de marges.
• Les icônes deviennent des calques, auxquels le système ajoute reflets, réfraction et ombres. L’utilisateur peut afficher son écran d’accueil en mode clair, sombre, transparent ou teinté.

Ce n’est pas une mode d’une saison : les kits de design publiés par Apple le 23 juin 2026 pour iOS 27 incluent des mises à jour de Liquid Glass. Le design est affiné, pas abandonné.

Que se passe-t-il quand votre application est recompilée avec Xcode 26 ?

Une application native qui utilise les composants standard d’Apple adopte Liquid Glass automatiquement, sans une ligne de code, dès qu’elle est recompilée avec Xcode 26 et qu’elle tourne sur iOS 26 ou plus récent. Et depuis le 28 avril 2026, Apple refuse toute mise à jour qui n’a pas été compilée avec Xcode 26 ou plus récent.

Xcode est l’outil d’Apple qui compile une application iPhone et l’envoie à l’App Store. Chaque version embarque un SDK, c’est-à-dire la boîte à outils du système, et c’est ce SDK qui décide de l’apparence des composants standard.

Conséquence : la première mise à jour publiée après le 28 avril 2026 change l’apparence de l’application chez tous vos utilisateurs passés à iOS 26, même si elle ne corrige qu’un bug. Ceux restés sur iOS 18 ou avant gardent l’ancien rendu. Nous avons détaillé cette exigence, et son équivalent chez Google, dans notre article sur l’obligation Android 16.

La bascule n’est jamais complète. Les barres, menus, fenêtres modales, boutons et interrupteurs standard changent seuls. Tout ce que votre prestataire a dessiné lui-même reste tel quel : barre aux couleurs de la marque, bouton sur mesure, fond dégradé derrière les onglets. Apple prévient que ces fonds personnalisés peuvent perturber le verre et recommande de les retirer. Le résultat le plus courant n’est donc pas une application moderne, mais un patchwork : du verre ici, l’ancien style là.

UIDesignRequiresCompatibility : jusqu’à quand garder l’ancienne apparence ?

La clé UIDesignRequiresCompatibility permet de compiler avec Xcode 26 tout en gardant l’apparence d’avant iOS 26, mais iOS l’ignore dès que l’application est compilée pour iOS 27. Comme Apple exige le SDK d’iOS 27 pour toute mise à jour à partir d’avril 2027, l’option s’éteint de fait à cette date.

UIDesignRequiresCompatibility est un réglage du fichier de configuration d’une application iOS, appelé Info.plist, qui demande au système d’afficher l’interface comme si elle avait été compilée avec une version antérieure du SDK, donc sans Liquid Glass.

La documentation d’Apple sur cette clé est explicite : le système ignore ce réglage quand l’application est compilée pour iOS 27 ou plus récent. Et dans son annonce du 9 septembre 2026, Apple fixe la suite : à partir d’avril 2027, toute application iPhone envoyée sur App Store Connect devra être compilée avec le SDK d’iOS 27 ou plus récent.

Le vrai risque : une application qui vit sous la clé et doit publier un correctif urgent en mai 2027 bascule d’un coup dans Liquid Glass, sans qu’aucun écran n’ait été vérifié. Le même mois, Apple exigera aussi des captures d’écran pour l’iPhone Duo, son iPhone pliable en vente depuis le 23 octobre 2026.

Application native, Flutter ou React Native : qui est concerné par Liquid Glass ?

Tout dépend de qui dessine l’interface : une application native reçoit Liquid Glass automatiquement, une application React Native le reçoit en partie, et une application Flutter ne le reçoit presque pas, parce que Flutter dessine lui-même chaque pixel. Les trois partagent en revanche la même icône et la même obligation de recompiler.

Une application native

Une application native est écrite avec les outils d’Apple : Swift, SwiftUI ou UIKit. Plus elle respecte les composants standard, plus la bascule est propre.

Une application Flutter

Flutter est le framework open source de Google qui produit une application iOS et Android depuis une seule base de code, en dessinant lui-même chaque élément de l’interface au lieu d’utiliser les composants du système, comme le précise sa documentation.

Recompiler une application Flutter avec Xcode 26 ne change donc presque rien à l’écran. Seuls les éléments empruntés à iOS prennent le nouveau style : clavier, feuille de partage, demandes d’autorisation, sélecteur de photos.

La question se pose pour les applications qui imitent iOS. La bibliothèque Cupertino est l’ensemble de composants Flutter qui reproduisent les barres, boutons et interrupteurs d’iPhone. En juin 2025, l’équipe Flutter a annoncé qu’elle n’y développait pas le design de 2026, puis a décidé de sortir d’abord Cupertino du cœur du framework. C’est fait depuis août 2026, avec le paquet séparé cupertino_ui. Dans un billet du 9 septembre 2026, l’équipe indique qu’une implémentation officielle de Liquid Glass est en cours. Au moment où nous écrivons, la version 1.1.1 de cupertino_ui ne la propose pas encore.

Des paquets communautaires insèrent déjà de vrais composants iOS dans une application Flutter. Le prix est réel : chaque composant natif a un coût de rendu sur tout l’écran, et n’affiche rien sur Android.

Notre position, avec Flutter en production chez Krafter depuis 2024 : ne pas courir après Liquid Glass écran par écran. Soignez l’icône et la lisibilité, puis adoptez le style officiel quand il sortira, dans le suivi normal de l’application. Ce suivi régulier est celui de Melimelo, notre application Flutter d’organisation du foyer : plus de 50 versions publiées, 4,7/5 sur 421 notes App Store en octobre 2026. Notre pratique de Flutter détaille la méthode.

Une application React Native

React Native est le framework de Meta qui écrit une application mobile en JavaScript et affiche, pour une partie de l’interface, les vrais composants d’iOS. La documentation d’Expo, un outil courant pour construire une application React Native, le confirme : depuis iOS 26, les en-têtes de la navigation native adoptent Liquid Glass par défaut, sans réglage écran par écran. Les éléments dessinés en JavaScript gardent leur apparence. Résultat fréquent : un en-tête en verre au-dessus d’une barre d’onglets à l’ancienne.

Quels risques visuels Liquid Glass fait-il courir à votre application ?

Le risque n’est pas un refus de l’App Store, mais une application moins lisible : du texte posé sur un verre translucide, des couleurs de marque qui perdent leur contraste, une icône mal rendue en mode teinté. Ces défauts se voient iPhone en main, sans développeur, à condition de savoir où regarder.

Les pièges les plus fréquents :

• Le texte sur le verre. Un titre blanc lisible sur une barre opaque devient illisible quand une photo claire défile dessous. Sur le verre le plus transparent, Apple conseille une couche sombre à 35 % d’opacité sous les éléments posés sur un contenu lumineux.
• Les couleurs de marque. Elles perdent en contraste sur le verre. Apple demande des couleurs déclinées en clair, en sombre et en contraste renforcé.
• Les réglages d’accessibilité. L’utilisateur peut réduire la transparence ou renforcer le contraste : un écran testé avec les seuls réglages par défaut casse chez une partie de vos utilisateurs.
• L’icône. Le système génère lui-même les variantes sombre, transparente et teintée que vous ne fournissez pas. Une icône chargée d’ombres, de reflets ou de texte rend mal dans ces modes, y compris pour une application Flutter ou React Native.

Pour savoir si votre application est concernée :

1. Installez la version publiée sur un iPhone passé à iOS 26 ou iOS 27.
2. Demandez à votre prestataire avec quelle version d’Xcode elle a été compilée, et si la clé UIDesignRequiresCompatibility est activée.
3. Parcourez les écrans principaux en faisant défiler le contenu sous les barres : un texte illisible ou un fond qui jure se voit tout de suite.
4. Activez la réduction de transparence et le contraste renforcé dans les réglages d’accessibilité, puis refaites le parcours.
5. Passez l’écran d’accueil en mode sombre, puis teinté, et regardez votre icône à côté de celles d’Apple.
6. Notez la date de la dernière publication. Antérieure au 28 avril 2026, elle a pu être compilée avec un Xcode plus ancien : la prochaine mise à jour changera alors l’apparence d’un coup.

Combien coûte l’adaptation à Liquid Glass, et quand ne rien faire ?

L’adaptation se facture au temps passé, entre 700 et 1 100 € HT par jour chez Krafter, et son ampleur dépend de la part d’interface dessinée sur mesure. Une application abandonnée commence par un audit de 1 à 3 jours, soit 700 à 3 300 € HT, et le maintien représente ensuite 8 à 12 % du développement par an.

Le maintien couvre la compatibilité avec chaque version d’iOS ; une refonte visuelle complète relève des évolutions. Pour replacer ce poste dans le budget global, voyez le coût d’une application mobile pour une entreprise, ou le simulateur de budget, qui vous situe en 8 questions.

Prenons un scénario type. Une application native de prise de rendez-vous, publiée en 2024, utilise des barres aux couleurs de la marque. Sa dernière version, de mars 2026, a été compilée avec l’ancien Xcode. Un correctif urgent tombe : recompilée avec Xcode 26, la navigation passe en verre, mais le fond coloré reste par-dessus et le titre blanc devient illisible sur les photos. La bonne décision : activer la clé pour publier le correctif tout de suite, puis planifier l’adaptation au calme, publiée bien avant avril 2027.

Quand ne rien faire, ou presque :

• Votre application Flutter a son propre design de marque et n’a jamais imité iOS : soignez l’icône et attendez le style officiel.
• Votre application est interne. La stabilité compte plus que la cohérence avec iOS : recompilez, vérifiez la lisibilité, arrêtez-vous là.
• Votre application sera reconstruite avant avril 2027. Activez la clé, ne payez pas deux fois, et intégrez Liquid Glass dans la nouvelle version.
• Votre application ne porte plus votre activité. Une version publiée ne change pas d’apparence tant que vous n’en publiez pas une nouvelle : ne rien publier est un choix valable.

Liquid Glass n’est pas une obligation de design : aucune exigence de publication d’Apple ne l’impose, ce qui est obligatoire, c’est la version d’Xcode. Mais une application qui ne suit pas paraîtra datée face à celles qui ont suivi, et l’option de compatibilité a une date de fin.

Que faire avant avril 2027 ?

Vérifiez dès maintenant comment votre application s’affiche sur iOS 26 et si sa dernière version utilise la clé de compatibilité, puis planifiez l’adaptation cet hiver, pour qu’elle soit testée et publiée bien avant avril 2027. La review d’Apple prend en général 1 à 2 jours sur Melimelo : le délai qui compte, c’est le travail avant l’envoi.

Si l’application a été développée par un prestataire qui n’est plus là, commencez par un audit de reprise : il dit ce qui est faisable, et à quel prix, avant d’y toucher. Si elle est vivante, le maintien en conditions l’aligne sur chaque version d’iOS sans course de dernière minute, comme nous l’expliquons dans la maintenance d’un logiciel après la livraison.

Dans tous les cas, parlez-nous de votre application : un des deux fondateurs vous répond sous 24 à 48 heures, avec un avis honnête, y compris quand la réponse est de ne rien faire.