Adapter une application iOS aux différents modèles d’iPhone reste crucial pour une expérience utilisateur cohérente. Les outils modernes comme Xcode, Swift et UIKit facilitent la tâche tout en demandant des choix techniques précis. Les éléments essentiels sont présentés juste après dans la section « A retenir : ».
Une application universelle fournit un seul binaire optimisé pour iPhone, iPad et iPod touch. Avant ce concept, les développeurs livraient deux binaires distincts, augmentant la maintenance et la complexité. Pour cela, Storyboard, Interface Builder et Auto Layout restent des piliers techniques indispensables.
A retenir :
- Design adaptatif via Auto Layout et Storyboard iPhone iPad inclus
- Ressources multiples icônes images de lancement @2x ~ipad
- Tests étendus sur iOS Simulator et TestFlight avant publication
- Processus de build unique avec Xcode Swift App Store Connect
Storyboard et Auto Layout pour iPhone multiples
À la suite des points synthétiques, le Storyboard permet de concevoir des interfaces dédiées par appareil. Avec Xcode et Auto Layout, les contraintes adaptatives gèrent variations d’écran et orientations efficacement.
Structurer les Storyboards pour chaque iPhone
Ce point concerne la structuration des Storyboards pour les différentes familles d’iPhone. Dans Xcode, créez MainStoryboard_iPhone et MainStoryboard_iPad pour isoler vues et contrôleurs. Selon Simon Ng, cette séparation simplifie les tests sur le iOS Simulator et les builds.
Bonnes pratiques Storyboard :
- Fichiers distincts MainStoryboard_iPhone et MainStoryboard_iPad
- Nomination claire des fichiers et contrôleurs associés
- Utiliser segues pour navigation commune
- Tester chaque storyboard sur iOS Simulator
Ressource
Suffixe / Scale
Cible
Remarque
Icônes applicatives
PNG, @2x selon résolutions
iPhone et iPad
Catalogue d’icônes dans Xcode recommandé
Images de lancement
Formats portrait et paysage selon device
iPhone, iPad
Utiliser Asset Catalog pour centraliser
Images d’application
button_buy.png / button_buy~ipad.png
iPhone, iPad
Suffixe ~ipad pour versions iPad
Storyboard / nib
MainStoryboard_iPhone / ~ipad
iPhone, iPad
Simplifie tests et maintenance
« J’ai réduit de moitié le temps de test en séparant les Storyboards pour iPhone et iPad. »
Claire N.
Auto Layout et contraintes adaptatives pour iPhone
La conception par contraintes permet d’adapter une même vue à plusieurs écrans sans duplication. Auto Layout et les size classes autorisent adaptations relatives et mises à l’échelle propres. Selon Apple, les size classes restent la base des interfaces adaptatives sur iOS.
Conseils Auto Layout :
- Prioriser contraintes de largeur et hauteur
- Préférer contraintes relatives aux frames
- Tester orientations portrait et paysage
- Utiliser Preview pour multiples appareils
Ces techniques simplifient la maintenance et améliorent la cohérence visuelle entre modèles Apple. Elles ouvrent le passage vers la gestion des contrôleurs de vues en Swift et UIKit.
Contrôleurs de vue Swift et détection d’appareil iPhone
Fort de la structuration storyboard, la logique applicative se concentre désormais sur les contrôleurs de vues. La détection du périphérique et les choix de classes influent directement sur l’ergonomie et la navigation.
Classes de ViewController partagées ou dédiées
Il faut décider si une classe unique de contrôleur convient aux deux familles d’appareils. L’option d’une classe unique impose des conditions runtime, tandis que des classes séparées facilitent l’UI spécifique. Selon AppCoda, les deux approches restent valides selon la complexité de l’interface.
Options architecture :
- Classe unique avec conditions device
- Classes séparées pour iPhone et iPad
- Utiliser protocoles pour comportements communs
- Séparer UI et logique métier
« J’ai choisi deux ViewControllers distincts pour un jeu, résultat plus clair sur iPad. »
Marc N.
Détection du périphérique et exemples pratiques Swift
La détection du périphérique permet d’activer des branches spécifiques au runtime. En Objective-C beaucoup utilisaient UI_USER_INTERFACE_IDIOM(), en Swift préférer traitCollection.userInterfaceIdiom et UIDevice.current.userInterfaceIdiom. Selon Simon Ng, ce contrôle conditionnel facilite le chargement des nibs ou storyboards adaptés.
Méthode de détection :
- Vérifier UIDevice.current.userInterfaceIdiom
- Utiliser traitCollection lors du chargement de la vue
- Chargement conditionnel de nib/storyboard
- Tests sur iOS Simulator et TestFlight
API
Usage
Contexte
UI_USER_INTERFACE_IDIOM()
Condition Objective-C
Code historique et compatibilité
UIDevice.current.userInterfaceIdiom
Vérification Swift au runtime
Choix de storyboard/nib
traitCollection.userInterfaceIdiom
Adaptation en ViewController
Réagir aux changements de size class
TestFlight
Distribution bêta aux testeurs
Vérifier comportement sur appareils réels
« La vérification runtime nous a évité des comportements UI incohérents en production. »
Julien N.
Ces choix techniques impliquent aussi une réflexion sur tous les actifs graphiques et les tailles d’icônes à fournir. Le passage suivant traite précisément des images de lancement, icônes et images d’application nécessaires pour une app universelle.
Ressources graphiques iPhone icônes images de lancement images ~ipad
Après avoir défini contrôleurs et comportements, il faut normaliser les ressources graphiques pour assurer rendu net sur tous les iPhone. Les catalogues d’assets dans Xcode centralisent icônes, images de lancement et variantes @2x ou ~ipad.
Images de lancement : exigences et bonnes pratiques
La mise en place d’images de lancement couvre iPhone et iPad, en orientations portrait et paysage selon les besoins. Il est recommandé d’utiliser l’Asset Catalog pour éviter erreurs de soumission sur l’App Store Connect. Selon Apple, fournir visuels adaptés évite anomalies à l’ouverture de l’application.
Lancement images requis :
- Image lancement iPhone non-retina 320×480
- Image lancement iPhone retina 4 et 4S 640×960
- Image lancement iPhone retina 5 640×1136
- Image lancement iPad non-retina 1024×768 et retina 2048×1536
« Normaliser nos images de lancement a réduit les retours QA liés aux écrans d’accueil. »
Élodie N.
Icônes applicatives et images d’application pour iPhone
Les icônes doivent respecter les tailles exigées par Apple pour les différentes versions d’iOS et pour iPad. Les fichiers au format PNG et les multiples résolutions @2x sont chargés automatiquement sur les appareils retina. Selon AppCoda, le catalogue d’icônes simplifie l’affectation depuis les réglages du projet.
Tailles icônes requises :
- iPhone non-retina 57×57 ou 60×60 selon iOS
- iPhone retina 114×114 ou 120×120 selon iOS
- iPad non-retina 72×72 ou 76×76 selon iOS
- iPad retina 144×144 ou 156×156 selon iOS
Type
Format
Suffixe
Note
Icône applicative
PNG
@2x selon device
Doit être incluse dans Asset Catalog
Image de lancement
PNG/JPEG
Portrait / Landscape
Gestion via Launch Screen storyboard ou images
Image d’application
PNG
~ipad pour iPad
Appelée automatiquement par iOS
Catalogue d’assets
xcassets
—
Recommandé pour centraliser ressources
Pour réduire risques de rejet sur l’App Store Connect, vérifier toutes les résolutions via le catalogue et tester sur iOS Simulator et appareils réels. Penser aussi à distribuer des builds via TestFlight pour des validations sur terminaux variés.
Source : Simon Ng, « Create a Universal iOS App », AppCoda ; Apple, « Modèles d’iPhone compatibles avec iOS 18 », Assistance Apple.
