Une application portage iPhone pour iPad - application unique, ou une fourchette?

Question

J'ai une application iPhone, je suis sur le point de modifier pour l'iPad.

Mon problème est le suivant: l'application est conçue pour fonctionner pour iPhone OS 2.0 et si je le fais pour l'iPad, je vais devoir concevoir pour OS 3.2

.

Je ne peux pas changer la version iPhone, parce que je risque certains de mes utilisateurs avec les anciennes versions de l'iPhone ne pas être en mesure d'exécuter l'application.

Il est évident que je peux faire une application hybride qui peut fonctionner sur iPad / iPhone OS 3.2 et iPhone / iPhone OS 2.0, mais ce sera un enfer pour maintenir, avec de nombreux changements d'appels API et autres.

Quelle est la meilleure approche: une version hybride ou une fourchette de code distinct pour l'iPad

Answer 1

Définissez votre SDK de base pour iPhone 3.2 périphériques. Réglez votre iPhone cible de déploiement à 2.0. Utilisez AvailibilityMacros lorsque vous appelez iPhone 3.2 API. Ensuite, créez le code différent de l'interface utilisateur pour l'iPad et de faire une application universelle. C'est le meilleur de tous les mondes. Sauf que vous ne recevrez pas un nouvel achat si la personne a un iPhone et déjà acheté votre application. Si vous êtes plus intéressés à obtenir plus de revenus en raison de la version iPad (peut-être la version iPad a beaucoup plus de fonctionnalités?) Ensuite, vous devez bifurquer votre code afin que vous pouvez définir un prix différent pour l'application iPad. Si je comprends bien, vous pouvez toujours garder la fourche dans le même projet Xcode afin que vous puissiez utiliser les modèles partagés et les contrôleurs et quand vous construisez juste choisir la cible à construire pour. Ainsi, vous en tant que dev obtenir le meilleur des deux mondes.

Par AdMob statistiques: iPhone OS Statistiques si vos clients ne sont alors les gens iPhone pas 3,0 <3%. C'est un assez petit pour moi, ils peuvent facilement mettre à jour gratuitement, donc je ne retiendrais pas votre application en arrière pour eux. Peut-être que votre application pourrait convaincre quelques personnes de mettre à jour également. Maintenant, si votre application prend en charge l'iPod Touch, votre marché cible est encore 32% 2.X

Answer 2

1) Chape le code, mais ...

2) Créer une application universelle.

En gros, faire une nouvelle version qui ne supporte qu'un OS3.2 à partir de maintenant. Cette version unique peut contenir à la fois l'application iPhone mise à jour et la nouvelle application iPad, vous permettant de les développer ensemble facilement à l'avenir, et de réutiliser les contrôleurs et les modèles vue entre eux. Voici comment Apple que vous le faites. Consultez la documentation sur les applications universelles.

Answer 3

Fork votre code. Vous allez probablement vouloir une nouvelle interface utilisateur ou nouveau code graphique pour accueillir le plus grand écran de toute façon, vous cherchez vraiment à une application « nouvelle » qui utilise beaucoup de vos classes existantes.

Answer 4

Votre application a une composante d'abonnement (qui est de vous faire de l'argent après l'achat initial) ou d'un contrat de service?

Si la réponse est non, je très simplement envisager de tout ce qui bouge à 3,2 - Voulez-vous vraiment être le portage dos changements? Les utilisateurs qui utilisent encore 2.0 OS (probablement une petite minorité, même y compris Jailbreakers comme 3.1 a été jailbreaké pour un certain temps) ne doivent pas passer à la nouvelle version. L'attente avec des applications iPhone est que les nouvelles versions seront libres, pas que de nouvelles versions seront libres et toujours travailler sur un ancien système d'exploitation.

En tant qu'utilisateur qui conserve mon système d'exploitation à jour, je serais effectivement inquiétez pas si vous passé beaucoup de temps à travailler sur les utilisateurs de soutien qui ne sont pas d'amélioration; Je sens votre temps serait mieux dépensé ajouter de nouvelles fonctionnalités.