Universal app pour iPad ?
maxi_mousse
Membre
Bonjour à tous, voici ma problématique :
Nous avons pour projet de porter notre appli iPhone vers l'iPad. Jusque là rien d'étonnant.
Cette même appli iPhone va faire l'objet d'une refonte assez importante ->recodage quasi-complet (File, New project ^^). Le tout en utilisant l'Interface Builder, ce qui n'est pas le cas dans la version actuelle.
Maintenant, je me pose la question de savoir, comment préparer correctement le re-développement de notre appli à la fois pour iPhone et pour iPad.
J'ai commencé à me documenter du côté des guidelines, j'ai bien noté par exemple les différentes possibilités (universal app, target iphone et target ipad, ...), ou encore le fait de gérer des vues avec le UISplitViewController ou le UIPopoverController pour les vues sur iPad. Mais j'avoue tout ça me fait peur.
Je vous sollicite donc pour avoir des retours d'expérience à ce niveau là , des conseils, mises en garde, etc, malgré le fait que le dev iPad est très récent, je pense tout-de-même que la réflexion a du tourner dans la tête de chacun depuis ces dernières semaines...
Nous avons pour projet de porter notre appli iPhone vers l'iPad. Jusque là rien d'étonnant.
Cette même appli iPhone va faire l'objet d'une refonte assez importante ->recodage quasi-complet (File, New project ^^). Le tout en utilisant l'Interface Builder, ce qui n'est pas le cas dans la version actuelle.
Maintenant, je me pose la question de savoir, comment préparer correctement le re-développement de notre appli à la fois pour iPhone et pour iPad.
J'ai commencé à me documenter du côté des guidelines, j'ai bien noté par exemple les différentes possibilités (universal app, target iphone et target ipad, ...), ou encore le fait de gérer des vues avec le UISplitViewController ou le UIPopoverController pour les vues sur iPad. Mais j'avoue tout ça me fait peur.
Je vous sollicite donc pour avoir des retours d'expérience à ce niveau là , des conseils, mises en garde, etc, malgré le fait que le dev iPad est très récent, je pense tout-de-même que la réflexion a du tourner dans la tête de chacun depuis ces dernières semaines...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et puis la taille de l'écran n'étant pas la même cela ne ferait qu'alourdir le binaire et cela pourrait obliger les utilisateurs à passer par l'iTunes Store pour télécharger l'application...
Je suis entièrement d'accord.
Si ton appli iPad n'a pas le même design que l'iPhone, crée 2 projets.
Si c'est la même en plus grand, un seul projet, mais c'est bien dommage de ne pas l'adapter.
Et pourtant je maintiens que maintenir 1 projet semble la solution logique... Aà¯e !
(Le projet est d'une ampleur assez importante avec tout plein de viewController partout, donc ce n'est pas une toute petite appli)
Mais rien ne t'empêche de tout faire dans un seul projet avec des targets définis pour les différents fichiers.
En effet, certes Apple préconise dans le texte de faire du Universal. Mais en pratique, j'ai déjà eu quelques applications sur mon iPhone pour lesquelles il m'a été proposé une mise à jour... qui ne m'a rien apporté, si ce n'est que maintenant au lieu que l'appli iPhone fasse genre 10Mo, elle en fait genre 100Mo, tout ça parce que le bundle intègre les ressources pour l'iPad (images en plus grande résolution, ...) alors qu'elles ne me serviront jamais.
Certes, si j'avais un iPad, je réagirai peut-être autrement, étant alors bien content sans doute d'avoir à ne télécharger (voire acheter si elles est payante) une seule application qui marchera sur les deux devices.
Mais en attendant, ça me prend de la place pour rien... donc je ne suis pas fan de cette façon de faire.
A la limite, publier une version "standard" iPhone only et une version "HD" (optimisée pour iPad, et intégrant aussi la version iPhone) me semble le plus appréciable pour l'utilisateur : si tu as un iPhone et pas d'iPad tu prend la standard, plus légère à télécharger, si tu as un iPad (avec ou sans un iPhone en plus), tu prends la version HD.
Donc par exemple un seul projet Xcode, deux targets (Standard et HD), et à coup de #define et en incluant les fichiers dédiés à l'iPad (en particulier les ressources) uniquement dans le target HD, tu peux dériver une version normale et une HD (et pourquoi pas une Lite aussi sur le même principe).
Ou alors deux projets Xcode, et chacun n'inclut que le strict nécessaire, quitte à ce qu'ils partagent des fichiers communs (après tout les fichiers que l'on inclut dans le projet Xcode par glisser/déposer dans "Groups & Files" n'ont aucune obligation d'être dans la même arborescence que le fichier projet)
PS : Vivement qu'Apple propose dans l'AppStore la possibilité d'avoir une page par application regroupant les différentes versions de l'appli selon la cible (une seule page présentant la version Lite, iPhone only, iPad, Universal, ...).
Je me permet aussi de re-demander votre avis concernant ces "demandes" d'Apple d'utiliser leur SplitViewController & compagnie pour l'iPad, comme dans certains sample code qu'ils fournissent. Je ne me suis pas encore réellement lancé dans des projets de test, mais est-ce que selon vous, adapter une navigation existante sur iPhone pour l'iPad (avec les directives de compilation iPhone/iPad donc) n'est pas un exercice quelque peu périlleux, est-ce relativement facilement adaptable à un projet iPhone existant, est-ce facilement prévisible pour un nouveau projet, et surtout, est-ce "obligatoire" d'utiliser ces nouveaux composant ? (risque de rejet d'app le cas échéant ?)
Je ne crois pas que la non utilisation des composants de type SplitViewController soit synonyme de rejet par Apple, par contre cela pourrait l'être par les utilisateurs si ils ne retrouvent pas l'expérience utilisateur attendu avec l'iPad.
Pour ma part, la migration d'une de mes applications vers l'iPad n'utilisera pas le splitView par contre les pop over c'est sûr car pour moi je trouve que cela apporte beaucoup aux interfaces.
Je viens de rendre disponible une version iPad d'iPocket Draw en version universelle.
La taille de l'application n'a pas augmentée fortement mais je n'ai pas de grandes images (que des icônes communes aux 2).
Je n'utilise pas les UISplit mais les UIPopover qui permettent très facilement et très élégamment d'afficher les vues secondaires appelées sur iPhone avec presentModalViewController, attention toutefois au clavier en mode paysage si la popoverview contient des UITextField.
Par défaut j'ai dédoublé tous les fichiers .xib mais pour certains s'était sans doute superflu.
Tant que l'iPhone pourra supporter les fonctionnalités que j'ajouterai progressivement, je pense rester avec une version universelle.
Après chaque cas est spécifique, dans le mien, l'UI de l'appli est simple et par nature l'appli. s'adapte à la taille de l'écran.
C'est plus pour des jeux (avec les textures en haute résolution) ou des applis embarquant beaucoup de ressources graphiques dans une qualité différente pour iPad et iPhone que ça pose des soucis, la version haute qualité étant inutile sur iPhone et prend de la place pour rien. Mais si ce n'est pas le cas, en effet une version Universelle est bienvenue.
Et comme ce nouveau téléphone aura certainement un processeur A4 comme l'iPad, on comprend mieux les recommandations d'Apple sur le fait de développer les applications en code universel.
Ce n'est qu'une hypothèse pour le moment, mais il convient d'être prudent dans sa stratégie de développement, en attendant fin juin, qu'Apple communique les spécifications graphiques de son iPhone 4G.
ps: Merci à Gray Powell d'avoir brillamment démontré le 18 Mars dans un bar californien que pommes et alcool ne font pas bon ménage !
Les items dans iTunes sont liés à une application. Si vous créez deux applications distinctes, l'utilisateur devra acheter deux fois le même item pour qu'il soit disponible sur iPhone et sur iPad. Si vous choisissez le binaire universel, vous aurez la possibilité de ne le faire payer qu'une seule fois.
Certes, mais pour mon cas l'application est gratuite :P
Et de +, le fait de créer une universal app "oblige" à rendre compatible l'appli pour iPad pendant le dev jusqu'à la soumission, car une fois l'app dispo sur l'appstore, elle doit pouvoir être téléchargeable par les 2 types d'appareil.
Tandis que créer un target pour la compatibilité iPad peut permettre dans un 1er temps de compiler l'appli pour iPhone, puis ensuite dans un second temps de passer du temps sur le dev du target iPad pour compiler celui-ci une fois terminé pour enfin soumettre la version iPad de l'appli.
Bon je ne citerai aucun jeu... Plant vs Zombie, FieldRunners.........
Tout ça pour avoir le suffixe "for iPad" ? Mouaip..
Comme l'ont dit la plupart des personnes, il faudrait vraiment que l'interface soit différente. Et dans le cas d'une appli, c'est souvent le cas fort heureusement.
Concernant le In-App Purchase, dixit doc Apple :
Donc pour moi ça ne pénalise pas l'utilisateur. Si les développeurs implémentent le même système dans l'app iPhone et l'app iPad, il n'y a pas de raisons que ça soit pénalisant. L'utilisateur aura le même contenu tant sur iPhone que sur iPad.
Mais encore une fois, ça dépend fortement du contenu. Si un module supplémentaire pour iPad est plus évolué que celui sur iPhone, c'est possible que certains développeurs décident de faire à nouveau payer.. c'est à eux de juger évidemment.
L'utilisateur moyen n'a simplement pas envie de payer deux fois une application similaire pour l'iPad si il l'a déjà sur iPhone.
Cela ne veut pas forcément dire non plus qu'une application universelle doit proposer juste une interface différente sur les deux plateformes.
En ce qui me concerne, je développe Poker Manager en version universelle en ce moment, et il n'est pas question de donner l'ensemble des fonctionnalités avancées de la version iPad à la version iPhone. Celle-ci sera amputée de certains fonctions qui n'ont pas leur place sur un téléphone. Néanmoins, je suis sûr que les clients potentiels seront ravis de savoir qu'ils n'auront pas besoin de repasser à la caisse si ils achètent un jour un iPad et veulent utiliser Poker Manager dessus.
Bien sûr, reste la question du prix. Comment tarifer une application universelle ?
Je pensais de tout façon augmenter le prix de Poker Manager pour la v2, car elle sera de toute façon beaucoup plus complète, même sur iPhone. Et je pensais céder à la tentation de faire une version lite pour que les gens puissent tester un peu avant d'acheter.
Je serai curieux de savoir ...
Par contre, les informations sur le nouvel iPhone semblent se concrétiser, c'est à dire l'apparition d'un nouvel écran de 960x640 pixels. Avec son processeur A4, sa résolution, et son look, l'iPhone HD ressemble davantage à un mini iPad qu'à un iPhone.
On vas donc avoir 3 configurations différentes :
- iPhone classique 480x320 pixels
- iPhone HD 960x640 pixels
- iPad 1024x768 pixels
Faut-il qu'une application Universal gère ces 3 configurations ?
Comment faire des applications tournant aussi bien sur l'iPhone "classique" que l'iPhone HD ? Bon évidement, une application "classique" fonctionnera sur iPhone HD, mais les acheteurs réclameront des applications utilisant les nouvelles spécifications du HD. Je pense notamment aux applications graphiques et aux jeux vidéos.
En effet je pense que même si la résolution augmente, la taille réelle des contrôles sur l'interface sera la même, ils seront simplement dessinés plus finement ; je ne vois pas du tout la taille des contrôles diminuer parce que la résolution augmente, ça deviendrait inadapté au doigt.
Et les images, icones ? Elles apparaà®traient plus petites.
Personnellement, j'espère que la réso de l'iPhone ne va pas changer...
Mais une application avec des graphismes réellement HD aura un avantage marketing sur les autres, du moins pour les possesseurs d'iPhone HD. C'est pourquoi la question risque de se poser. D'un autre coté, le graphisme HD est très proche de la résolution de l'iPad. On peut imaginer une application Universal App contenant des graphismes normaux pour l'iPhone et des ressources graphiques HD utilisés pour l'iPad et l'iPhone HD.
- upscaler une image 60x60 pour la rendre en taille 120x120, c'est loin de faire profiter de la plus haute résolution de l'iPhone HD, tu auras juste une image plus pixelisée. Oui, même sur un écran de plus haute résolution : il ne peut pas inventer des pixels qu'il ne connait pas.
- comment il peut déterminer s'il doit upscaler l'image ou pas ? Si tu développes aujourd'hui, ou dans quelques mois, une application sur ton futur iPhone HD, avec des images du coup taillées à la résolution de l'iPhone HD... faudrait pas qu'il upscale les image non plus !
Tout le monde aurais crié aux sandales (c'est plus rigolo sans le 'c' :P) mais le pied pour la monté en résolution.
D'ailleurs c'est pas sensé être dans les cartons d'Apple depuis un bout le temps la partie IHM de Cocoa en tout vectoriel? Il me semble avoir lu un article la dessus sur cocoa.fr
Oui c'est là où je voulais en venir. Merci Ali.
Oui enfin, une photo euh ? ça va pour un bouton mais bon.
Des pixels qu'il ne connait pas ? Je ne parle pas d'une opération magique consistant à fabriquer une vraie image HD à partir d'une image basse résolution, mais de grossir une image en convertissant chaque pixel de 4 pixels de même couleur.
Et effectivement cela ne permet pas de profiter de la plus haute résolution de l'iphone HD, juste de l'utiliser pour afficher des graphismes avec la même taille apparente qu'avec un écran iPhone "classique".
Quand au fait de savoir s'il faut l'upscaler ou pas? Je présume qu'il y aura des fonctions dans le SDK pour préciser le mode de compatibilité des graphismes, selon le type de device. Nous verrons bien le moment venu, comment Apple gère ça.
Enfin ce n'est qu'une hypothèse, Jobs n'ayant pas encore annoncé l'iPhone 4G. Mais les révélations du prototype volé et la commande d'Apple pour 24 millions d'écrans tactiles 960x640 pixels me laissent à penser que l'arrivée de la HD est imminente.
L'article en question.
Malheureusement, il n'y a rien de nouveau à ce propos. L'indépendance de la résolution devait déjà être proposée pour Léopard, et on n'a rien vu venir dans Snow Leopard. Le principe du peu de doc qui existe, c'est qu'on fait ses calculs pour une résolution de 72 ppp et le window serveur convertit les coordonnées pour que ça corresponde à la résolution de l'écran.
Pour revenir à l'iPhone, il est probable qu'ils ne fassent pas évoluer le système de coordonnées. Ils utiliseraient la matrice de transformation du CGContext pour qu'un point corresponde à deux pixels.