iOS 27 : pourquoi les devs iOS vont devoir rendre leurs apps adaptables (et penser iPad dès maintenant)

Note importante : toutes les exigences techniques citées dans cet article sont documentées officiellement par Apple (notes techniques, session WWDC26, notes de version iOS 27). La partie « iPhone pliable », elle, repose sur des fuites sérieuses mais non confirmées : Apple ne l'a jamais présentée comme la raison de ces changements.

À la WWDC25, Apple avait prévenu. À la WWDC26, l'avertissement est devenu une règle en vigueur : le SDK iOS 27 impose une façon moderne de construire les applications, et trois certitudes historiques du développement iOS viennent officiellement de tomber : le cycle de vie centré sur l'AppDelegate, les interfaces pensées pour une orientation fixe, et l'idée qu'une app iPhone ne vivra jamais ailleurs que sur un écran d'iPhone.

1. UIScene devient obligatoire avec le SDK iOS 27

C'est écrit noir sur blanc dans la note technique TN3187 : à partir d'iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27 et visionOS 27, une application compilée avec le dernier SDK doit adopter le cycle de vie basé sur les scènes, faute de quoi elle refuse tout simplement de se lancer. Dans la session « Modernize your UIKit app » (WWDC26), Apple le formule sans détour : « UIScene lifecycle is now required when building with the latest SDKs. Without it, your application will no longer launch. »

Deux nuances importantes tout de même : les binaires existants compilés avec d'anciens SDK continuent de fonctionner, et seule l'adoption du cycle de vie par scènes est exigée, pas la prise en charge complète du multi-fenêtres. Mais comme Apple finit chaque année par imposer un SDK récent pour toute soumission sur l'App Store, personne n'y échappera bien longtemps. L'écosystème multiplateforme en fait déjà les frais : chez Expo / React Native, des développeurs signalent que des projets fraîchement générés ne se lancent plus sur iOS 27, la question agite la communauté Unity, et Flutter a publié son propre guide de migration vers UISceneDelegate.

2. Sur iPad : la fin du refuge UIRequiresFullScreen

Pendant des années, la clé UIRequiresFullScreen permettait d'échapper au multitâche de l'iPad : plein écran forcé, une seule taille d'écran à gérer, affaire classée. C'est terminé. La note technique TN3192 indique que cette clé et son mode de compatibilité sont dépréciés depuis iPadOS 26 et seront ignorés dans une prochaine version. Les notes de version iOS / iPadOS 27 ajoutent une condition très concrète : pour qu'une application soit « continuously resizable » sur iPad, elle doit déclarer les quatre orientations dans son Info.plist. Et ce n'est pas de la théorie : des développeurs voient déjà s'afficher dans la console le message « UIRequiresFullScreen will soon be ignored », et certains envois vers l'App Store sont refusés avec l'avertissement « Support for all orientations will soon be required ».

Il faut toutefois se garder d'un raccourci : le plein écran ne disparaît pas pour l'utilisateur. iPadOS conserve un mode « Apps en plein écran » dans les réglages, et une fenêtre peut toujours être agrandie. Ce qui disparaît, c'est la possibilité pour le développeur de s'exempter durablement du nouveau système de fenêtres. Apple prévoit d'ailleurs un régime particulier pour les jeux, avec un redimensionnement par paliers (« discrete resizing ») sur iPhone.

3. Les apps réservées à l'iPhone ne sont plus à l'abri

C'est le point qui change la donne pour beaucoup d'équipes. Dès qu'elle est recompilée avec le dernier SDK, une application conçue uniquement pour l'iPhone devient automatiquement redimensionnable dans deux contextes : la recopie d'iPhone sur Mac (iPhone Mirroring) et l'exécution sur iPad : « fully resizable like any other iPad app », selon les mots d'Apple dans la session UIKit. L'application reste techniquement en « phone idiom », mais Apple est claire : l'idiom ne doit plus guider la mise en page. Il faut désormais raisonner en size classes et en espace réellement disponible. Autrement dit, une interface iPhone ne peut plus partir du principe qu'elle aura un seul écran, une seule taille et une seule orientation.

4. La piste que tout le monde a en tête : l'iPhone pliable

Officiellement, Apple justifie tout cela par la recopie d'écran sur Mac et par les apps iPhone sur iPad. Le mot « pliable » n'apparaît nulle part. Mais les indices s'accumulent. Des chaînes de caractères « foldState » et « angleDegrees » ont été repérées dans les frameworks d'iOS 27, ainsi qu'une clé renvoyant le nombre d'écrans intégrés de l'appareil (MacRumors, juin 2026). Côté presse, Mark Gurman décrit dans Bloomberg (mars 2026) un pliable dont l'écran interne approcherait la taille d'un iPad mini, avec une interface « façon iPad » et deux apps côte à côte, mais qui ne ferait pas tourner les apps iPad telles quelles. Reuters rapportait en avril des difficultés d'ingénierie susceptibles de peser sur le calendrier.

Ce détail du reportage de Gurman est décisif : Apple ne prépare pas une fusion entre iPhone et iPad, mais un iOS dans lequel l'application iPhone doit savoir s'afficher en grand. Très exactement ce que les nouvelles règles du SDK 27 imposent déjà.

5. Vers des apps iPhone pensées comme des apps iPad

Sur le papier, Apple n'oblige personne à publier une véritable version iPad, et aucune annonce ne va dans ce sens. Mais la frontière devient largement théorique : une fois recompilée avec le SDK 27, une application iPhone sera affichée dans des tailles et des proportions dignes d'un iPad, que son équipe l'ait anticipé ou non. Pour rester présentable en 2027, une app réservée à l'iPhone devra migrer vers UIScene, abandonner toute logique fondée sur l'orientation ou l'idiom, adopter les size classes, déclarer les quatre orientations, et être testée en mode fenêtré, dans Stage Manager, en plein écran et via la recopie sur Mac. En pratique, cela représente 80 % du travail d'une vraie application iPad.

S'y prendre tôt relève aussi d'un simple calcul de dette technique : chaque nouvelle fonctionnalité construite sur des écrans non adaptatifs est un écran de plus qu'il faudra reprendre le jour où la migration deviendra inévitable. Plus l'application grossit, plus la facture s'alourdit, alors qu'une base de code déjà adaptative absorbe les nouveautés sans surcoût. À l'inverse, chaque trimestre d'attente ajoute des vues à corriger, des parcours à re-tester et des régressions potentielles.

Il y a enfin un enjeu de visibilité. À chaque nouveau format, Apple a systématiquement mis en avant les applications qui exploitaient le matériel dès le premier jour : les premières apps optimisées pour le Vision Pro ou pour l'iPad ont largement profité des sélections éditoriales de l'App Store. Si l'iPhone pliable se concrétise, tout indique qu'Apple réservera le même traitement aux apps déjà à l'aise sur son grand écran interne. Les équipes prêtes ce jour-là partiront avec un avantage de visibilité difficile à rattraper.

Ce qu'il faut retenir : puisque ce chantier d'adaptation est de toute façon imposé, les équipes qui ne développent que pour l'iPhone ont tout intérêt à en profiter pour voir plus loin : concevoir dès maintenant des interfaces qui tirent réellement parti des grands écrans (colonnes, barres latérales, vues divisées) plutôt que de se contenter d'une interface iPhone simplement étirée. Le jour où le pliable arrivera (et tout le SDK 27 semble construit pour lui), ces applications seront prêtes. En attendant, elles cesseront de ressembler à de simples apps de téléphone agrandies sur iPad.

Sources

• Apple – TN3187 : Migrating to the UIKit scene-based life cycle
• Apple – TN3192 : Migrating from the deprecated UIRequiresFullScreen key
• Apple – WWDC26, session 278 « Modernize your UIKit app »
• Apple – Notes de version iOS & iPadOS 27
• Apple – Documentation UIRequiresFullScreen
• Bloomberg (Mark Gurman) – iPhone pliable : interface façon iPad, apps côte à côte
• MacRumors – iOS 27 laisse entrevoir un iPhone pliable (foldState, angleDegrees)
• Reuters – iPhone pliable : des difficultés d'ingénierie
• GitHub Expo – projet iOS 27 qui ne se lance plus sans UIScene