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

Les notes de version d’iOS 27 d’Apple donnent un contournement en une ligne pour les apps 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 omet, c’est que le système croise cette déclaration valable pour toute l’app avec les orientations prises en charge par chaque view controller.² Élargissez le jeu au niveau de l’app et vous l’élargissez partout, iPhone compris, sauf si chaque view controller contraint redéfinit supportedInterfaceOrientations.

Mise à jour du 24 août : Le verrou est levé. Les notes de version actuelles indiquent le problème 166422120 comme corrigé – il est sorti des problèmes connus entre l’édition beta 4 et l’édition beta 6, et l’édition beta 7 le confirme : les orientations déclarées ne conditionnent plus le redimensionnement continu, conformément à l’intention affichée citée ci-dessous.¹ Si vous avez livré le contournement des quatre orientations, il n’est plus nécessaire sur les betas actuelles ; avant de le retirer, revérifiez les view controllers pour lesquels vous avez ajouté en même temps des redéfinitions de supportedInterfaceOrientations, car ces redéfinitions restent structurantes à elles seules (le comportement d’intersection décrit dans cet article est inchangé). Les problèmes connus de redimensionnement liés à UIRequiresFullScreen datant de la beta 4 sont eux aussi marqués comme corrigés dans les problèmes résolus. L’analyse ci-dessous est conservée telle quelle, ancrée à la Beta 4, parce que la mécanique des effets de bord du contournement s’applique toujours partout où le contournement subsiste dans des builds livrés. Pour le tableau plus large dans lequel s’inscrit ce changement, voir L’ère de l’iPhone redimensionnable.

La version résumée de ce changement se trompe elle 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 dans les problèmes connus, parce qu’en Beta 4 elles le conditionnent encore.¹

Les deux moitiés comptent. Le comportement est un bug sur le chemin 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.

TL;DR

Dans iOS et iPadOS 27 Beta 4, une app iPad compilée avec le SDK iOS 27 dont UISupportedInterfaceOrientations omet l’une des quatre orientations est traitée comme non redimensionnable en continu, ce qu’Apple répertorie comme un problème connu, aux côtés de l’affirmation selon laquelle les orientations « ne devraient plus être une condition du redimensionnement continu ».¹ Le contournement documenté consiste à déclarer les quatre. Cela élargit le jeu d’orientations de votre app dans son ensemble, et le système détermine la rotation en comparant les orientations de l’app à celles de chaque view controller.² Quatre autres problèmes connus concernent UIRequiresFullScreen, qui délivre des mises à jour de redimensionnement continues là où des changements discrets d’UIScreen sont prévus.¹ Ni UIRequiresFullScreen ni UISupportedInterfaceOrientations n’est déprécié.³⁴

Ce que disent réellement les notes de version

Six entrées de la section UIKit des notes d’iOS et iPadOS 27 Beta 4 portent là-dessus, dont cinq encore ouvertes.¹

Le verrou lui-même, classé dans les problèmes connus :

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

Lisez le temps employé dans la seconde phrase. « Ne devraient plus être une condition » décrit un comportement voulu. L’entrée existe en tant que problème connu parce que le comportement livré ne correspond pas encore à l’intention.

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

Quatre problèmes connus autour d’UIRequiresFullScreen :

Une app 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 au contraire être délivré comme un changement discret vers un nouvel UIScreen doté de nouvelles bounds ». Il en va de même pour une app iPhone uniquement 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 app 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 problème antérieur, où les bounds d’UIScreen.main changeaient au redimensionnement sous UIRequiresFullScreen, figure désormais dans les problèmes résolus.¹ C’était un problème connu ouvert dans une beta 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 » a un sens bien particulier.

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

La différence se voit dans la main de l’utilisateur. Une app redimensionnable en continu refait sa mise en page pendant que la fenêtre bouge. Une app qui ne l’est pas conserve sa mise en page et se cale d’un coup à la fin, ce qui paraît poussif à côté des apps système qui, elles, ne le font pas.

Apple resserre la voie de compatibilité depuis des années. UIRequiresFullScreen est arrivé avec iOS 9 pour se retirer entièrement du multitâche iPad et du redimensionnement dynamique.³ Stage Manager dans iPadOS 16 et le mode Windowed Apps dans 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 app iPad participe au fenêtrage moderne ou reste dans un mode qu’Apple ne cesse de réduire. Cela vaut bien une modification d’Info.plist. Cela ne vaut pas une modification non encadrée, ce qui est tout l’objet de la section suivante.

Le coût du contournement

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

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

« Pour déterminer s’il faut effectuer une rotation, le système compare les orientations prises en charge par le view controller avec celles prises en charge par l’app — telles que déterminées par le fichier Info.plist ou par la [méthode] de l’app delegate — 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 app restée uniquement en portrait en listant une seule orientation dans Info.plist et en ne redéfinissant jamais rien au niveau du view controller perd sa contrainte à l’instant où elle applique le contournement.

Pour une app universelle, cela retombe sur iPhone autant que sur iPad. Et les recommandations d’Apple elles-mêmes plaident contre la déclaration large de ce côté : à propos de l’orientation à l’envers, « il est recommandé 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 l’orientation à l’envers « 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 dit à une app universelle de pivoter à l’envers sur iPhone afin d’obtenir un comportement de fenêtrage 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 aussi que les valeurs par défaut de supportedInterfaceOrientations diffèrent selon l’idiome, et que le système ne la consulte que si shouldAutorotate renvoie true.² Si vous avez redéfini cette dernière, l’interaction mérite d’être relue 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 gagné.

Vérifiez ce que votre Info.plist déclare réellement, cible par cible. Les clés d’orientation sont souvent définies une seule fois à la création du projet puis jamais revues, et une app 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é, donc jamais de mode de compatibilité.

Trouvez les controllers 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 étroite dans Info.plist, c’est exactement le profil qui casse : l’app est uniquement en portrait par la seule grâce de la property list, si bien que l’élargir supprime la seule contrainte qui existait.

Regardez ensuite l’app, sur les deux idiomes. L’échec est visuel et le signal automatisé est faible. Un test d’interface 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 avant, ce qui suppose de lancer le build 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 à ratio fixe sont les endroits où une rotation inattendue coûte le plus cher, et ce sont aussi ceux où les redéfinitions par controller ont le plus évidemment leur place.

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

Quatre des cinq problèmes ouverts concernent UIRequiresFullScreen.¹ La clé qui retire une app du multitâche iPad est désormais la condition dans 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é ni de beta.³ UISupportedInterfaceOrientations ne l’est pas davantage, disponible depuis iOS 3.2.⁴

Cette combinaison mérite d’être nommée. Une app qui définit UIRequiresFullScreen en 2026 compile sans avertissement, se livre 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 : dans iPadOS 26 et versions ultérieures sur les iPad prenant en charge le mode Windowed Apps, et dans iPadOS 16 ou version ultérieure sur les iPad prenant en charge Stage Manager, le système « maintient une taille de scène cohérente pour votre app, mais ne présente pas la scène de votre app 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 schéma : c’est le SDK de compilation qui décide

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

Même source, binaire différent, comportement différent. Cela revient sans cesse dans cette version : les images des éléments de menu dépendent du SDK avec 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 dans macOS 27 semble être le cas inverse, une politique au niveau de l’OS sans qualificatif de SDK, ce qui est précisément pourquoi la distinction mérite d’être vérifiée plutôt que supposée.

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

Quoi faire maintenant

Décidez si vous avez seulement besoin du redimensionnement continu. Si votre app iPad déclare déjà les quatre orientations, rien de tout ceci ne s’applique. 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 controller. La modification d’Info.plist est un plafond ; la contrainte doit passer dans supportedInterfaceOrientations sur les controllers 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 ceux d’une cible que vous ne considérez pas comme une app iPad, puisque l’un des problèmes couvre les apps iPhone uniquement exécutées sur iPad.

Attendez-vous à la disparition du verrou. Apple affirme que les orientations ne devraient plus conditionner le redimensionnement continu. Quand ce sera effectif, la raison de déclarer les quatre disparaîtra, mais le jeu d’orientations élargi restera dans votre Info.plist jusqu’à ce que quelqu’un le retire. 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 des problèmes connus aux problèmes résolus. Cet article reflète la Beta 4 au 2 août 2026.

Points clés à retenir

Pour les développeurs d’apps iPad : - Les orientations déclarées verrouillent toujours le redimensionnement continu en Beta 4, alors même qu’Apple affirme le contraire. Traitez cela comme un bug assorti d’un contournement, pas comme le nouveau comportement. - Le contournement élargit le plafond d’orientations de toute votre app. Ajoutez des redéfinitions de supportedInterfaceOrientations par controller, sinon votre build iPhone se met à 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 app 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éduire. Auditez-le explicitement. - Chaque problème évoqué ici est conditionné à une compilation avec le SDK iOS 27, pas à l’OS exécuté par l’utilisateur.

FAQ

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

Pas en Beta 4. Apple affirme qu’« à partir d’iOS 27, les orientations d’interface prises en charge ne devraient plus être une condition du redimensionnement continu », et classe cette affirmation dans les problèmes connus parce que le comportement actuel les prend encore comme condition.¹

Quel est le contournement exact ?

Déclarer les quatre orientations d’interface dans UISupportedInterfaceOrientations.¹ Associez-le à des redéfinitions de supportedInterfaceOrientations sur les view controllers qui doivent rester contraints, car le système croise le jeu de toute l’app avec celui de chaque controller.²

Est-ce que cela affectera mon build iPhone ?

Si vous livrez une app universelle et que vous vous reposez sur le seul Info.plist pour contraindre l’orientation, oui. Apple recommande de désactiver entièrement l’orientation à l’envers 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 encouragement.

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 app prend réellement en charge. Les redéfinitions de supportedInterfaceOrientations par controller devraient rester quoi qu’il arrive, car exprimer les contraintes d’orientation là où la contrainte a sa place est plus durable que de se reposer sur un plafond valable pour toute l’app.

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

Comment savoir si mon app est actuellement redimensionnable en continu ?

Redimensionnez la fenêtre sur un iPad et regardez si la mise en page suit le glissement ou se cale d’un coup à la fin. Si elle suit, c’est redimensionnable en continu. Si elle se cale, vérifiez deux choses : si UIRequiresFullScreen est défini, ce qui retire entièrement l’app du redimensionnement dynamique, et si UISupportedInterfaceOrientations liste les quatre orientations, ce qui est la condition décrite par ce problème connu.¹³

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

Chaque entrée est conditionnée à une compilation avec le SDK iOS 27.¹ Un SDK plus ancien évite ces problèmes précis, et retarde le changement à venir plutôt que de l’empêcher.

Sources