Apple a pris son temps avec les téléphones pliables, assez longtemps pour que les fabricants Android en sortent plusieurs générations, puis a fait ce qu'Apple fait toujours : arriver après tout le monde, avec un joli nom et un étui folio. L'iPhone Duo a été présenté le 9 septembre, les précommandes ouvrent le 16 octobre et il arrive en boutique le 23 octobre, France comprise dès la première vague, à partir de 1 999 dollars aux États-Unis. À ce prix, peu de vos utilisateurs l'achèteront le premier jour, mais ceux qui le font sont souvent du genre enthousiaste et bavard, celui qui poste des captures d'écran, alors autant savoir ce qu'ils vont voir en ouvrant votre app.
Une app, un nombre étonnant de formes
Fermé, l'iPhone Duo est un téléphone avec un écran extérieur de 5,4 pouces, plus large et moins haut que celui de n'importe quel autre iPhone. Ouvert, il devient un écran intérieur de 7,6 pouces avec une charnière au milieu, et les gens vont le tenir à moitié plié comme un livre, le poser sur une table, le tourner dans tous les sens et, pour la première fois sur un iPhone, afficher deux apps côte à côte en Split View. Votre app n'a donc plus « la taille d'un iPhone », elle a n'importe quelle taille, et c'est le message principal du guide développeur d'Apple : le redimensionnement, c'est la fonctionnalité.
La bonne nouvelle, c'est que si votre app se comporte déjà bien sur iPad et Mac, ou se redimensionne correctement dans la recopie de l'iPhone sur Mac, Apple estime que vous avez fait l'essentiel du chemin. La moins bonne concerne l'app mise en page pour une seule largeur d'écran en 2019 et jamais revue depuis. Les conseils d'Apple se lisent comme une liste de vieux péchés : dimensionner les vues par rapport à leur conteneur et non aux dimensions fixes d'un iPhone, calculer la mise en page à partir de la scène ou des limites de la vue plutôt que de l'écran, s'appuyer sur les size classes, et arrêter de décider de la mise en page selon le type d'appareil ou l'orientation. Si votre code garde quelque part un UIScreen.main.bounds.width qui décide de la largeur d'une carte, c'est la semaine où il se fait prendre.
Votre barre d'onglets a déménagé sur le côté
C'est le changement qui surprendra le plus de monde. Sur l'écran extérieur, et sur l'écran intérieur en paysage, le système place la barre d'état, la barre de navigation, la barre d'outils et la barre d'onglets verticalement le long d'un bord pour laisser la hauteur au contenu. Seul l'écran intérieur en portrait garde les barres horizontales habituelles.
Si vous utilisez les conteneurs standard (un NavigationStack avec .toolbar en SwiftUI, des éléments posés sur un contrôleur de vue dans un contrôleur de navigation en UIKit), vous l'obtenez sans rien faire. Si votre équipe a construit sa propre barre avec un UIToolbar ou, pire, une rangée de boutons dans un HStack, le système ne peut pas la déplacer, et votre app ressemblera à l'invité qui n'a pas reçu le message sur le code vestimentaire. Un dernier détail piège pas mal de monde : un élément avec un titre mais sans icône, ou une vue personnalisée, n'est pas du tout affiché à la verticale. Donnez à chaque élément de barre d'outils un titre et un symbole, et laissez le système choisir ce qui rentre :
import SwiftUI
struct FactureScreen: View {
var body: some View {
NavigationStack {
Text("Facture n° 1024")
.navigationTitle("Facture")
.toolbar {
ToolbarItem(placement: .cancellationAction) {
Button("Fermer", systemImage: "xmark") {}
}
ToolbarItem(placement: .primaryAction) {
Button("Partager", systemImage: "square.and.arrow.up") {}
}
}
}
}
}
Quand la place manque, les éléments partent dans le menu de débordement du système en commençant par le bas, et une priorité de visibilité sur chaque élément décide lesquels restent le plus longtemps. L'exemple d'Apple, c'est le bouton Nouveau message de Mail : l'action que les gens utilisent toute la journée doit être la dernière à disparaître.
Rien d'important dans le pli
Le schéma parcourt les quatre situations que votre app va rencontrer. Fermé, elle tourne sur le petit écran extérieur avec ses barres sur le côté. Ouvert, la même app profite du grand écran intérieur, et une vue partagée affiche la liste et le détail ensemble, comme Mail. À moitié plié comme un livre, le milieu de l'écran devient une zone réservée que le contenu doit éviter. Et en Split View, votre app partage l'écran intérieur avec une autre et garde ses commandes sur son propre bord extérieur.
Cette position à moitié pliée est la vraie nouveauté. iOS appelle le pli et les deux caméras avant des zones réservées : la caméra extérieure couvre toujours un coin, la caméra intérieure seulement quand elle est active, et le pli ne compte que lorsque le téléphone est entrouvert. Les alertes, les feuilles, les menus contextuels et les vues partagées s'en écartent d'eux-mêmes. Vos vues personnalisées, non, et un gros bouton « Payer » centré à l'écran peut finir pile dans le pli, là où personne n'a envie de taper. Pour ces vues-là, SwiftUI et UIKit gagnent une API ReservedRegion pour repérer le pli et écarter le contenu, ainsi qu'une nouvelle vue d'arrangement qui place une vue principale et une vue secondaire de part et d'autre. Cet exemple vient tout droit du guide d'Apple :
ArrangementView {
PrimaryView()
} secondary: {
SecondaryView()
}
.arrangementViewStyle(.split.axes(.horizontal))
Compilée avec Xcode 26 ? Vous aurez un cadre
Voici la partie qui touche toutes les apps, mises à jour ou non. D'après Apple, une app compilée avec Xcode 26 ou une version plus ancienne ne s'étend pas sous la barre d'état et la caméra sur l'iPhone Duo, elle tourne donc avec une marge visible, un peu comme un tableau encadré à la va-vite. Pour occuper tout l'écran, il faut compiler avec le dernier Xcode ; la bêta d'Xcode 27.1 sortie le 18 septembre est celle qui apporte le SDK et le simulateur de l'iPhone Duo, et Apple a annoncé la prise en charge de l'iPhone Duo dans le Device Hub d'Xcode pour prévisualiser chaque position. Si vous êtes passé par la mise à jour vers Xcode 26 cette année, l'exercice vous semblera familier.
Deux remarques plus petites. L'App Store voudra des captures d'écran iPhone Duo dans deux nouvelles tailles, une par écran, même si App Store Connect ne les accepte que « plus tard cette année ». Et si votre app prend des photos ou des vidéos, la caméra utilisée peut soudain regarder dans l'autre sens quand on ouvre ou ferme le téléphone, ce qui n'est drôle qu'une seule fois.
Concrètement, je ferais quoi ?
J'installerais la bêta d'Xcode 27.1, je lancerais l'app dans le simulateur iPhone Duo et je parcourrais chaque écran fermé, ouvert, à moitié plié et tourné, feuilles et popovers compris, avec un bloc-notes à côté. La liste s'écrit toute seule : les barres maison restées coincées en bas, les boutons sans icône, les mises en page mesurées sur l'écran, tout ce qui trône au milieu de l'écran intérieur. La plupart des corrections sont petites une fois qu'on sait où elles sont, et celles qui ne le sont pas concernent en général les mêmes mises en page à largeur fixe qui avaient déjà une drôle d'allure sur iPad. Ensuite, je livrerais ces corrections avec la prochaine version normale plutôt qu'avec une version spéciale en urgence, puisque le téléphone n'arrive dans aucune poche avant le 23 octobre de toute façon.
Si vous voulez de l'aide
Vérifier comment une app tient le coup sur les nouveaux appareils et les nouvelles versions d'iOS fait partie de l'audit d'application mobile en cinq jours, et l'article sur ce que je vérifie pendant un audit montre ce qu'il couvre d'autre.
Sources : Apple Newsroom, Apple unveils iPhone Duo, Preparing your app for iPhone Duo, Human Interface Guidelines, Designing for iPhone Duo, page développeur iPhone Duo, Build for iPhone Duo with new resources, Screenshot specifications.