Redimensionnement de l'iPad sous iOS 27 : le contournement a un coût

Les notes de version d’iOS 27 publiées par Apple proposent un contournement en une phrase pour les applications iPad qui ne sont pas redimensionnables en continu : déclarer la prise en charge des quatre orientations d’interface dans votre Info.plist¹. Ce que la note passe sous silence, c’est que le système croise cette déclaration globale avec les orientations prises en charge par chaque contrôleur de vue². Élargissez le jeu global et vous l’élargissez partout, iPhone compris, à moins que chaque contrôleur de vue contraint ne redéfinisse supportedInterfaceOrientations.

La version « titre » de ce changement se trompe aussi sur l’état actuel. L’intention d’Apple est que les orientations déclarées cessent de conditionner le redimensionnement continu. La note de version qui consigne cette intention est classée sous Known Issues, précisément parce qu’en bêta 4 elles le conditionnent encore¹.

Les deux moitiés comptent. Le comportement est un bug sur la route d’un changement délibéré, et le contournement de ce bug a un effet de bord que personne ne documente au même endroit.

En bref

Dans la bêta 4 d’iOS et iPadOS 27, une application iPad compilée avec le SDK iOS 27 dont le UISupportedInterfaceOrientations omet l’une des quatre orientations est traitée comme non redimensionnable en continu — un problème qu’Apple répertorie comme connu, tout en affirmant que les orientations « ne devraient plus conditionner le redimensionnement continu »¹. Le contournement documenté consiste à déclarer les quatre. Cela élargit le jeu d’orientations de toute l’application, et le système détermine la rotation en comparant les orientations globales à celles de chaque contrôleur de vue². Quatre autres problèmes connus concernent UIRequiresFullScreen, qui délivre des mises à jour de redimensionnement continues là où des changements discrets d’UIScreen sont attendus¹. Ni UIRequiresFullScreen ni UISupportedInterfaceOrientations ne sont dépréciés³⁴.

Ce que disent réellement les notes de version

Six entrées de la section UIKit des notes de la bêta 4 d’iOS et iPadOS 27 touchent à ce sujet, dont cinq encore ouvertes¹.

Le verrou lui-même, classé sous Known Issues :

« Sur iPad, si votre application iPad est compilée avec le SDK iOS 27 et que son UISupportedInterfaceOrientations n’inclut pas les quatre orientations d’interface, l’application est traitée comme non redimensionnable en continu. À partir d’iOS 27, les orientations d’interface prises en charge ne devraient plus conditionner le redimensionnement continu. »

Observez le temps du verbe dans la seconde phrase. « Ne devraient plus conditionner » décrit un comportement voulu. L’entrée figure parmi les problèmes connus parce que le comportement livré ne correspond pas encore à l’intention.

Cette nuance change ce que vous devez faire. Si les orientations avaient réellement cessé de conditionner le redimensionnement, le conseil serait de retirer les contournements. Comme elles le conditionnent toujours, le conseil est d’en appliquer un — et de s’attendre à ce que sa raison d’être disparaisse.

Quatre problèmes connus autour de UIRequiresFullScreen :

Une application iPad compilée avec le SDK iOS 27 qui définit UIRequiresFullScreen reçoit des mises à jour de redimensionnement continues, alors que « chaque redimensionnement devrait plutôt être délivré comme un changement discret vers un nouvel UIScreen dont les bounds ont été mises à jour ». Il en va de même pour une application exclusivement iPhone exécutée sur iPad, et de nouveau au sein d’iPhone Mirroring¹.

Un quatrième couvre la gestion des orientations dans iPhone Mirroring : une application compilée avec le SDK iOS 27 obtient une scène prenant en charge toutes les orientations « quelles que soient les orientations déclarées dans UISupportedInterfaceOrientations ou renvoyées par UIViewController.supportedInterfaceOrientations », alors que celles-ci « devraient être respectées jusqu’à ce que l’utilisateur commence à redimensionner la fenêtre »¹.

Un problème résolu : un point antérieur, où les bounds d’UIScreen.main changeaient lors d’un redimensionnement sous UIRequiresFullScreen, figure désormais sous Resolved Issues¹. C’était un problème connu actif dans une bêta précédente. Si vous travaillez à partir de notes prises il y a quelques semaines, vérifiez celui-là avant de le répéter.

Ce que vous apporte le redimensionnement continu

Avant de peser le coût, il vaut la peine d’être précis sur ce qui est verrouillé, car « redimensionnable en continu » recouvre un travail bien particulier.

Une fenêtre iPad peut changer de taille de deux façons. Elle peut sauter entre des états discrets, ce que reçoit une application en mode de compatibilité : le système, selon les mots d’Apple, « maintient une taille de scène cohérente pour votre application, mais ne présente pas sa scène en plein écran »³. Ou bien elle peut suivre le geste, recevant un flux de tailles intermédiaires à mesure que l’utilisateur déplace la poignée de redimensionnement.

La différence se sent dans la main de l’utilisateur. Une application redimensionnable en continu recompose sa mise en page pendant que la fenêtre bouge. Une application qui ne l’est pas fige sa mise en page et se recale à la fin, ce qui paraît poussif à côté des applications système qui, elles, suivent le geste.

Apple resserre la voie de compatibilité depuis des années. UIRequiresFullScreen est arrivé avec iOS 9 pour permettre à une application de se retirer entièrement du multitâche iPad et du redimensionnement dynamique³. Stage Manager sous iPadOS 16 puis le mode Windowed Apps sous iPadOS 26 ont chacun élargi ce qu’une fenêtre peut faire, et la documentation décrit désormais le mode de compatibilité par ce qu’il retire plutôt que par ce qu’il accorde.

La question à laquelle répond le contournement est donc de savoir si votre application iPad participe au fenêtrage moderne ou reste dans un mode qu’Apple continue de rétrécir. Cela vaut une modification d’Info.plist. Cela ne vaut pas une modification sans garde-fou — et c’est tout l’objet de la section suivante.

Le coût du contournement

Le contournement d’Apple tient en une phrase : déclarer les quatre orientations d’interface dans Info.plist¹. Sa conséquence, elle, vit sur une autre page.

UIViewController.supportedInterfaceOrientations documente la façon dont la rotation est décidée² :

« Pour déterminer s’il faut pivoter, le système compare les orientations prises en charge par le contrôleur de vue avec celles prises en charge par l’application — telles que déterminées par le fichier Info.plist ou par la [méthode] du délégué de l’application — et avec celles prises en charge par l’appareil. »

Trois ensembles, croisés. La déclaration dans Info.plist est un plafond, pas une instruction. Une application restée en portrait uniquement parce qu’elle ne liste qu’une orientation dans Info.plist, sans jamais rien redéfinir au niveau des contrôleurs de vue, perd sa contrainte à l’instant même où elle applique le contournement.

Pour une application universelle, cela retombe sur iPhone autant que sur iPad. Et les recommandations d’Apple elles-mêmes déconseillent la déclaration large de ce côté : à propos de l’orientation portrait inversé, « il est préférable de l’activer pour l’idiome iPad. Les appareils iOS sans bouton d’accueil, comme l’iPhone 12, ne prennent pas en charge cette orientation. Vous devriez la désactiver entièrement pour l’idiome iPhone »². La documentation d’Info.plist dit la même chose dans l’autre sens, en notant que le système ignore le portrait inversé « sur les appareils sans bouton d’accueil »⁴.

L’instruction honnête tient donc en deux étapes, pas une :

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

Sautez la seconde étape et vous aurez demandé à une application universelle de pivoter en portrait inversé sur iPhone afin d’obtenir un comportement de fenêtrage sur iPad. L’échec n’est ni un plantage ni une erreur de compilation. C’est une vue caméra qui bascule pendant que quelqu’un s’en sert.

Notez également que les valeurs par défaut de supportedInterfaceOrientations diffèrent selon l’idiome, et que le système ne consulte cette propriété que si shouldAutorotate renvoie true². Si vous avez redéfini cette dernière, l’interaction mérite une relecture avant de supposer que votre contrainte tient.

Savoir si vous êtes concerné

Rien de tout cela ne produit d’erreur de compilation : l’audit est donc manuel. Trois vérifications, par ordre décroissant de temps épargné.

Vérifiez ce que votre Info.plist déclare réellement, cible par cible. Les clés d’orientation sont souvent définies une fois à la création du projet et jamais revues, et une application universelle peut porter des déclarations différentes pour iPhone et pour iPad via UISupportedInterfaceOrientations~ipad. Lisez les deux.

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

PlistBuddy sort avec un code non nul quand une clé est absente, ce qui constitue en soi la réponse pour UIRequiresFullScreen : pas de clé signifie que vous n’avez jamais été en mode de compatibilité.

Repérez les contrôleurs qui contraignent l’orientation dans le code. Ce sont eux qui continuent de fonctionner après la modification d’Info.plist, et c’est leur absence qui rend cette modification dangereuse.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Un résultat vide combiné à une déclaration Info.plist étroite, c’est exactement le profil qui casse : l’application est en portrait uniquement du seul fait du fichier de propriétés, si bien que l’élargir supprime la seule contrainte qui existait.

Puis regardez l’application, sur les deux idiomes. L’échec est visuel et le signal automatisé est faible. Un test d’UI qui pilote un écran et vérifie son contenu passe dans n’importe quelle orientation. Ce que vous cherchez, c’est une vue qui pivote alors qu’elle ne le pouvait pas auparavant — ce qui suppose de lancer la version iPhone et de tourner physiquement l’appareil ou le simulateur après la modification d’Info.plist.

La capture média, la numérisation de documents, les champs de signature, les jeux et tout ce qui repose sur un canevas à rapport d’aspect fixe : voilà où une rotation inattendue coûte le plus cher, et voilà aussi où les redéfinitions par contrôleur ont le plus évidemment leur place.

UIRequiresFullScreen n’est pas déprécié, il est vidé de sa substance

Quatre des cinq problèmes ouverts concernent UIRequiresFullScreen¹. La clé qui retire une application du multitâche iPad est désormais la condition sous laquelle la livraison des redimensionnements se comporte mal.

Elle n’est pas dépréciée. La documentation d’UIRequiresFullScreen indique une disponibilité iOS 9.0 et iPadOS 9.0, sans marqueur de dépréciation, d’indisponibilité ou de bêta³. UISupportedInterfaceOrientations non plus, disponible depuis iOS 3.2⁴.

Cette combinaison mérite d’être nommée. Une application qui définit UIRequiresFullScreen en 2026 compile sans avertissement, se distribue sans avis de migration, et atterrit dans un mode de compatibilité qu’Apple ne cesse de rétrécir. La documentation décrit déjà ce que ce mode signifie sur les systèmes modernes : sous iPadOS 26 et ultérieur sur les iPad prenant en charge le mode Windowed Apps, et sous iPadOS 16 et ultérieur sur les iPad prenant en charge Stage Manager, le système « maintient une taille de scène cohérente pour votre application, mais ne présente pas sa scène en plein écran »³.

La clé ne fait plus ce que son nom annonce. Elle n’a pas été retirée, et rien dans votre build ne vous le dira.

Le motif récurrent : c’est l’édition de liens au SDK qui décide

Chaque entrée ci-dessus partage une même condition, et ce n’est pas la version du système. Chacune s’applique aux applications « compilées avec le SDK iOS 27 »¹.

Même source, binaire différent, comportement différent. Le cas est revenu à plusieurs reprises dans cette version : les images des éléments de menu dépendent du SDK contre lequel vous avez fait l’édition de liens, avec trois comportements distincts sur deux générations de SDK. Et le refus d’accès aux conteneurs entre équipes sous macOS 27 semble être le cas inverse : une règle au niveau du système, sans qualificatif de SDK — ce qui est précisément la raison pour laquelle cette distinction se vérifie plutôt qu’elle ne se suppose.

La conséquence pratique pour les tests : une compilation contre le SDK iOS 26 et une compilation contre le SDK iOS 27 sont deux sujets différents. Si votre matrice CI ne comporte qu’une seule version d’Xcode, elle n’en teste qu’un.

Que faire maintenant

Décidez si vous avez réellement besoin du redimensionnement continu. Si votre application iPad déclare déjà les quatre orientations, rien de tout ceci ne vous concerne. Le contournement n’a d’intérêt que si vous avez délibérément contraint les orientations.

Si vous appliquez le contournement, associez-le à des redéfinitions par contrôleur. La modification d’Info.plist est un plafond ; la contrainte doit migrer vers supportedInterfaceOrientations sur les contrôleurs qui en ont besoin, en fonction de l’idiome.

Auditez UIRequiresFullScreen séparément. Quatre problèmes ouverts le concernent, et rien ne le signale dans votre build. Passez vos fichiers Info.plist au grep, y compris pour les cibles que vous ne considérez pas comme des applications iPad, puisque l’un des problèmes couvre les applications exclusivement iPhone exécutées sur iPad.

Attendez-vous à la disparition du verrou. Apple annonce que les orientations ne devraient plus conditionner le redimensionnement continu. Le jour où cela arrivera, la raison de déclarer les quatre disparaîtra, mais le jeu d’orientations élargi, lui, restera dans votre Info.plist jusqu’à ce que quelqu’un l’enlève. Laissez un commentaire expliquant pourquoi il est là.

Revérifiez les notes avant d’agir. L’une de ces six entrées est déjà passée de Known Issues à Resolved. Ce billet reflète l’état de la bêta 4 au 2 août 2026.

À retenir

Pour les développeurs d’applications iPad : - Les orientations déclarées conditionnent toujours le redimensionnement continu en bêta 4, malgré ce qu’annonce Apple. Traitez-le comme un bug assorti d’un contournement, pas comme le nouveau comportement. - Le contournement élargit le plafond d’orientations de toute l’application. Ajoutez des redéfinitions de supportedInterfaceOrientations par contrôleur, sinon votre version iPhone se mettra à pivoter. - Quatre problèmes ouverts concernent UIRequiresFullScreen, qui délivre des mises à jour de redimensionnement continues plutôt que discrètes.

Pour quiconque maintient une application plus ancienne : - UIRequiresFullScreen n’est pas déprécié et ne produit aucun avertissement, alors que le comportement qu’il demande ne cesse de se rétrécir. Auditez-le explicitement. - Chaque problème évoqué ici est conditionné par la compilation avec le SDK iOS 27, pas par le système que fait tourner l’utilisateur.

FAQ

Les orientations déclarées ont-elles cessé de conditionner le redimensionnement continu ?

Pas en bêta 4. Apple affirme qu’« à partir d’iOS 27, les orientations d’interface prises en charge ne devraient plus conditionner le redimensionnement continu », et classe cette affirmation sous Known Issues, parce que le comportement actuel les prend toujours comme condition¹.

Quel est le contournement, concrètement ?

Déclarer les quatre orientations d’interface dans UISupportedInterfaceOrientations¹. Associez-le à des redéfinitions de supportedInterfaceOrientations sur les contrôleurs de vue qui doivent rester contraints, car le système croise le jeu global avec celui de chaque contrôleur².

Cela va-t-il affecter ma version iPhone ?

Si vous publiez une application universelle et que vous comptez sur Info.plist seul pour contraindre l’orientation, oui. Apple recommande de désactiver entièrement le portrait inversé pour l’idiome iPhone, et note que le système l’ignore sur les appareils sans bouton d’accueil²⁴.

UIRequiresFullScreen est-il déprécié ?

Non. Sa documentation indique une disponibilité iOS et iPadOS 9.0, sans marqueur de dépréciation³. Quatre des problèmes ouverts évoqués ici le concernent : l’absence de marqueur de dépréciation ne doit donc pas se lire comme un blanc-seing.

Faut-il retirer le contournement une fois qu’Apple aura corrigé le verrou ?

Retirez la partie dont vous n’avez plus besoin, et gardez celle qui vous protège. Quand les orientations déclarées cesseront de conditionner le redimensionnement continu, la raison de lister les quatre disparaîtra, et vous pourrez ramener UISupportedInterfaceOrientations à ce que votre application prend réellement en charge. Les redéfinitions de supportedInterfaceOrientations par contrôleur, elles, devraient rester dans tous les cas : exprimer les contraintes d’orientation là où la contrainte a sa place est plus durable que de s’en remettre à un plafond global.

Le scénario d’échec à éviter est l’inverse : resserrer Info.plist en oubliant que les redéfinitions étaient la seule chose qui maintenait un écran de capture à l’endroit.

Comment savoir si mon application est actuellement redimensionnable en continu ?

Redimensionnez la fenêtre sur un iPad et observez si la mise en page suit le geste ou se recale à la fin. Si elle suit, c’est qu’elle est redimensionnable en continu. Si elle se recale, vérifiez deux choses : si UIRequiresFullScreen est défini, ce qui retire entièrement l’application du redimensionnement dynamique, et si UISupportedInterfaceOrientations liste les quatre orientations, condition que décrit précisément ce problème connu¹³.

Compiler contre un SDK plus ancien permet-il d’éviter tout cela ?

Chaque entrée est conditionnée par la compilation avec le SDK iOS 27¹. Un SDK plus ancien évite ces problèmes précis, et repousse le changement à venir plutôt qu’il ne l’empêche.

Sources