Lorsque l’on crée son compte de développeur iOS pour distribuer des applications sur l’AppStore, une des questions qui nous ait posée est la suivante : Quelle langue principale voulez-vous choisir ?

Alors que cache cette question et pourquoi est-elle très importante ? La réponse dans cet article

Quelle est l’influence de la langue principale d’un compte développeur iOS ?

Cette langue est la langue de référence de votre compte, elle définie donc également la langue de référence de vos applications. C’est à dire que si vous choisissez le Français comme langue de référence, la langue de référence pour la localisation de vos applications sera le Français.

Très bien, mais quelles en sont les conséquences ? Les conséquences sont les suivantes : Pour proposer une application à l’international, iTunes Connect (la plateforme de mise en ligne des applications sur l’AppStore pour les développeurs) vous propose de localiser la description et les screenshots de votre application. L’idée est ici de pouvoir proposer une description en Allemand pour les utilisateurs de l’AppStore allemand, une description en Anglais pour les utilisateurs du store aux Etats-Unis… etc…

Jusque la, la langue de référence de votre compte n’a pas d’influence, sauf que, l’AppStore fonctionne de la manière suivante :

• 1. Vous entrez la description et les screenshots pour votre langue de référence
• 2. Vous entrez la description et les screenshots pour CHACUN des autres PAYS pour lesquels pour souhaitez proposer une localisation

Ce qui signifie que les utilisateurs verront soit la description dans la langue de référence si aucune localisation pour leur pays n’est proposée, soit la localisation pour leur pays si vous en avez entrée une.

Un exemple concret

Ma langue de référence est le Français

J’ajoute une application sur l’AppStore en la rendant disponible dans le monde entier. Je dois alors tout d’abord entrer la description et les screenshots en Français, puisque c’est ma langue de référence.
Ceci étant fait, je choisis d’ajouter une description et des screenshots en Anglais pour les utilisateurs du store des Etats-Unis.

Voici maintenant ce que différents utilisateurs verront :

• Utilisateur vivant en France : Description et screenshots en Français
• Utilisateur vivant aux Etats-Unis : Description et screenshots en Anglais
• Utilisateur vivant en Espagne : Description et screenshots en Français
• Utilisateur vivant en Angleterre : Description et screenshots en Français

Une influence considérable : Prudence

Le soucis est donc le suivant : La localisation n’est pas propre à la langue mais au pays, si j’ai choisis comme langue de référence le Français et que je souhaite proposer une applications avec descriptions et screenshots en Anglais pour tout le monde sauf en France, je devrai donc entrer autant de localisations qu’il existe de pays !

Il faut donc réfléchir et choisir la langue de référence de son compte avec prudence. En général, il vaut mieux choisir l’Anglais, de tel sorte que l’on soit sur que tout le monde va bien voir la description en Anglais de base et qu’on n’ai uniquement à proposer une localisation pour certains pays.

HTML 5 est un langage cross-platform très puissant permettant de créer des webapp performantes. Cependant si la technologie est la, il manque toujours un éco-système de distribution afin de pouvoir faire connaître sa webapp. La question est donc : Comment publier une webapp sur l’AppStore de l’iPhone et de l’iPad ou sur l’Android Market ?

Les composants WebView

Les webview (UIWebView pour iOS et WebView pour Android) sont des composants du SDK natif du téléphone qui permettent d’intégrer du contenu web dans une application native. C’est ce composant qu’il va falloir utiliser.

En effet, l’idée est d’empacketer votre web-app dans une application native afin de pouvoir la distribuer sur les stores. Pour ce faire, on va donc faire pointer la webview sur notre webapp et donc donner l’impression à l’utilisateur d’utiliser directement notre webapp alors qu’il passe en fait par une application native et une webview.

Une fois ce principe compris : vous n’avez plus qu’a créer une application iPhone/iPad avec une UIWebView et/ou une application Android avec une Webview. Le code de chacune des applications ne dépasse donc pas les 15 lignes.

On a donc notre webview, mais encore faut-il la faire pointer sur notre webapp. La question qui se pose alors est la suivante : Comment et ou stocker notre webapp ?

Le stockage de la webapp

Ici il existe 2 possibilités distinctes qui ont chacun leurs avantages et leurs inconvénients :

1. Le stockage local dans le téléphone
La première possibilité est d’intégrer votre webapp dans l’application native directement. Il est donc alors possible de faire pointer la webview directement sur votre dossier contenant l’HTML local.
Les avantages sont la rapidité d’exécution et le fait de ne pas demander de connexion internet pour exécuter l’application.

2. Le stockage en ligne sur un serveur
La seconde possibilité est stocker votre webapp sur un serveur web en ligne et de faire pointer votre webview sur l’url du serveur.
L’avantage est alors de pouvoir faire des traitements serveur (php, stockage dans une base de donnée en ligne etc…) directement depuis la webapp.

Libre à vous, selon votre application de choisir l’une des deux possibilités.

Les spécifications de l’AppStore d’Apple

Attention cependant, il est précisé dans les guidelines d’Apple pour la soumission de votre application pour l’AppStore que votre app ne doit pas être simplement une webview qui pointe sur un site web classique. L’idée est de protéger l’appstore contre une invasion de sites web non optimisés mobiles.

Veillez donc bien à ce que votre webapp soit pertinente, optimisé pour le mobile et qu’elle apporte un réel plus à l’utilisateur, sinon vous avez de grande chance de voir la soumission de votre application refusée par Apple.

Deux exemples de webapp HTML 5

Voici deux exemples de webapp HTML 5 empacketés dans des applications native et qui sont donc disponibles sur les stores Android et iOS :

1. Open RSS Reader
Un lecteur de flux RSS réalisé en jQuery mobile HTML 5, l’application est disponible sur l’Android Market et sur l’AppStore. Elle utilise la deuxième méthode de stockage à savoir le stockage en ligne sur un serveur afin de pouvoir effectuer les traitements sur les flux en ligne.

• Lien Android Market : Open RSS Reader Android
• Lien AppStore : Open RSS Reader iPhone / iPad

2. Save the Pig
Save the Pig est un mini-jeu pour iPhone réalisé en HTML 5 avec la librairie Easel JS. Il utilise le stockage local dans l’application afin d’offrir des performances maximales. Le jeu est disponible gratuitement sur l’AppStore :

• Lien AppStore : Save the Pig iPhone

A l’heure où avoir une application sur le store des smartphones et plus particulièrement sur l’AppStore et l’Android Market est devenue une habitude pour toutes les personnes soucieuses d’être à la pointe de la technologie, il est nécessaire d’avoir une réflexion sur les différentes manière de monétiser son app, notamment car avec la plateforme iTunes d’Apple, les possibilités sont nombreuses. Voici un petit tour d’horizon de ce qu’il est possible de faire.

Modèle de l’application payante

Dans ce modèle, l’utilisateur final doit payer avant de pouvoir télécharger et lancer l’application. Ce modèle est probablement le plus rentable et le plus utilisé pour monétiser à l’heure actuel même si les choses sont entrain de changer (voir la partie sur les achats intégrés).

Avantages :

• Entrées d’argent directes et fixes pour chaque téléchargement
• Les revenues augmentent proportionnellement aux téléchargements

Inconvénients :

• Application plus difficile à vendre car payante
• Attentes de l’utilisateur plus importantes

Ce modèle est donc une valeur sure si vous pouvez vous assurer que votre application va être téléchargée suffisamment pour être rentable. Il faut donc être soucieux de la qualité de l’app et la promouvoir de manière efficace.

Modèle de l’application gratuite

Ce modèle est le plus apprécié des utilisateurs car il consiste à laisser la possibilité de télécharger et d’utiliser l’application gratuitement. Ce modèle est très souvent couplé à un autre modèle afin d’assurer la monétisation.

Avantages :

• Grand nombre de téléchargements (une application gratuite est en moyenne 10 fois plus téléchargée qu’une app payante)
• Utilisateur moins exigent car application gratuite

Inconvénients :

• Pas de monétisation directe (nécessité de le coupler avec un autre business model)

Ce modèle est donc une manière de toucher le plus grand nombre, mais pour monétiser il est souvent couplé soit à une application payante qui propose plus de fonctionnalités (modèle de l’app « lite » ou de la « démo »), soit à un autre business model (voir achats intégrés ou publicité)

Modèle de la publicité intégrée

Ce modèle consiste à intégrer de la publicité dans son application afin de généré des revenues. Si ce modèle est beaucoup utilisé couplé à une app gratuite, il n’est pas forcément le plus apprécié de l’utilisateur final.

Avantages :

• Grand nombre de téléchargements si il est utilisé dans une app gratuite
• Permet de monétiser sans forcément faire payer l’utilisateur

Inconvénients :

• Monétisation dépendante de l’utilisation de l’application (Une app peut être beaucoup téléchargée mais ne pas rapporter beaucoup si elle n’est pas utilisée souvent)
• Part de la somme générée par la publicité reçue dépendante de la régie publicitaire utilisée

Ce modèle présente donc des avantages dont le principal est bien sur de pouvoir mettre une application gratuite à disposition de l’utilisateur et de monétiser quand même. On voit même des app payantes utiliser de la publicité pour augmenter encore les revenues. L’intégration dans une application est également très simple (surtout sur la plateforme Apple avec iAd). Cependant méfiance car les utilisateurs n’aiment généralement pas la publicité, il faut donc l’utiliser avec parcimonie.

Modèle de l’achat intégré

Avec ce modèle, l’utilisateur peut effectuer des achats directement dans l’application grâce à des achats intégrer. Cela lui permet alors de s’abonner ou de débloquer des fonctionnalités supplémentaires. Dans ce domaine en grande expansion, Apple à pris un ascendant considérable sur la concurrence en proposant des achats intégrés très simplifiés et même un système d’abonnement automatique pour la presse dans le nouvel iOS 4.3

Avantages :

• Permet à l’utilisateur de payer très simplement sans quitter l’application
• Permet de générer des revenues avec une application gratuite et sans publicité
• Très simple à intégrer sur iPhone et iPad

Inconvénients :

• Revenues dépendant des usages de l’utilisateur
• Plus difficile à implémenter sur Android

Ce modèle est de plus en plus utilisé car il permet de coupler les avantages d’une application gratuite et ceux d’une application payante via les achats intégrés. Cependant, cette solution n’est viable que si l’utilisateur se décide à utiliser l’achat intégré, il faut donc proposer des fonctionnalités intéressantes à débloquer.

Et les Web app alors ?

Il restait un dernier point à traiter concernant la monétisation, c’est celui de la web app HTML 5. En effet, si HTML 5 propose un outil technique pour réaliser une app de qualité, il n’existe pas vraiment d’éco système puissant comme celui de l’AppStore et du Market pour les monétiser. Il y a donc plusieurs solutions possible :

• Empaqueter sa web-app dans une webview au sein d’une application native et la mettre en vente sur l’AppStore ou le Market Android : voir cet article
• Vendre sa web app sur un store HTML 5 alternatif (exemple : Open App Mkt). Cependant, il est assez difficile de vendre sur ce genre de marchés. Le plus souvent les apps payantes ne sont pas téléchargées
• Intégrer de la publicité : Solution la plus simple à mettre en place et qui est la plus utilisée à l’heure actuelle pour monétiser une web app
• Intégrer une solution de paiement intégré : Très peu utilisé car assez difficile à mettre en place, il n’y a en effet pas de plateforme de référence pour ce type de transactions (même si des outils comme Paypal peuvent fonctionner)

Conclusion : Il existe donc de nombreuses façon de monétiser une app sans forcément la rendre payante directement pour l’utilisateur. Selon vous, quel modèle économique et le plus viable ?

Après un article sur la création d’une application multi-plateformes en utilisant HTML 5, j’ai décidé cette fois de me lancer dans la création d’un mini jeu pour iPhone en utilisant les canvas. Découvrez comment créer simplement un jeu complet pour iPhone et toutes les plateformes compatibles HTML 5

La librairie Easel JS : Les canvas accessibles

Si vous avez déjà essayé d’utiliser les balises canvas d’HTML 5, vous avez sans remarquer qu’il n’est pas évident de maitriser l’ensemble des fonctionnalités. C’est pour cela que Grant Skinner a créé la librairie Easel JS

Le but de cette librairie est de retrouver ce qui fait la force du Flash et de l’AS3 dans les canvas, c’est à dire : Une scène (stage), des DisplayObject et une DisplayList. Le tout compatible avec l’ensemble des navigateurs modernes puisque les canvas commencent à être bien implantés.

Pour mieux comprendre, jetez un oeil à la documentation d’Easel JS : Documentation Easel JS

La communication entre Objective-C et JavaScript

Pour lancer le jeu sur l’AppStore, j’ai du créer une app qui utilise une UIWebView pour l’affichage. Cependant, même si l’ensemble du jeu est programmé en JavaScript, il peut être utile de communiquer entre JavaScript et Objective-C.

Appeler une fonction javascript depuis Objective-C

Appeler du code Objective-C depuis JavaScript

Depuis JavaScript :

Puis, en Objective-C :

Tout cela vous permettra de communiquer facilement entre Objective-C et JavaScript. Le fonctionnement est semblable sur Android avec une WebView

Mise en application : Save the Pig

Pour mettre en application tout cela, j’ai donc créé un mini jeu iPhone entièrement créé en HTML 5 avec Easel JS : Save the Pig

Ce jeu utilise la balise canvas pour l’affichage graphique et l’interaction avec l’utilisateur et utilise les fonctions d’appel de code Objective-C pour le multi-taches et le Game Center

L’application est disponible sur l’AppStore gratuitement :

Plus d’infos sur le jeu sur son mini-site officiel : Save the Pig – site officiel

Qu’en pensez vous? Pour ou contre l’HTML 5 dans le monde des jeux mobiles ?

Jquery Mobile, pourquoi et comment ?

L’une des difficultés lorsque l’on se lance dans la création d’une application cross-platform (comprenez compatible avec plusieurs plateformes) est de trouver un framework efficace et multi-plateformes. Pour mon application j’ai choisis d’utiliser Jquery Mobile car il propose une syntaxe simple et est très facile à utiliser. D’autres framework sont possibles, notamment Sensha Touch qui a l’air très convaincant et efficace.

J’ai donc choisi Jquery Mobile couplé à une structure HTML 5 classique (voir la structure d’un site html 5). La prise en main de Jquery Mobile est très simple, surtout si vous connaissez déjà Jquery. On arrive très rapidement à faire des structures de données et a naviguer entre les différents écrans de l’application. La version actuelle (alpha 2) de Jquery mobile propose des animations de transitions très convaincantes, surtout sur iPhone ou l’on retrouve vraiment l’impression d’une application native.

Jquery Mobile propose des éléments d’interface mobile tout faits qu’il ne reste qu’à implémenter pour les utiliser. La barre de navigation, les boutons d’interface, les listes, les boutons etc… Tout est très simple à utiliser et à mettre en place.

Vraiment multi-plateforme ?

La réponse est oui! Difficile de le nier, en effet on arrive au même résultat que l’on lance l’application sur Android (2.2 minimum) et iOS (4.0 minimum) ainsi que sur les derniers BlackBerry. Nul doute que le contrat est donc rempli de ce coté la.

NB : Si l’application a la même apparence sur les différents terminaux, il ne faut pas négliger les différences de résolution d’écran et de rapidité d’exécution. Si l’iPhone 3GS et 4 ainsi que le Nexus One s’en sortent très bien, les téléphones moins récents ont un peu plus de mal a faire tourner l’application de manière fluide

En revanche, si nous avons la possibilité de créer une application, il faut encore pouvoir la distribuer sur toutes ces plateformes.

Distribution : AppStore et Android Market

Pour distribuer mon application, j’ai donc essayer de mettre en vente sur l’AppStore et sur L’Android Market. Pour toucher ces 2 plateformes, vous devez absolument disposer d’une application native (.apk pour Android et .ipa pour iPhone), il a donc fallu créer des applications incluants une webView qui charge notre webapp.

Il suffit ensuite de mettre en vente cette application native sur les plateformes Android et Apple afin de pouvoir toucher un maximum de personnes avec notre webapp

Open RSS Reader, un premier jet

Pour mettre en avant la possibilité de créer dès maintenant une webapp HTML 5 et de la vendre sur l’AppStore et sur l’Android Market, j’ai décidé de commercialiser ma WebApp de lecture de flux RSS : Open RSS Reader

La voici disponible :

• Sur l’AppStore d’Apple
• Sur l’Android Market
• Sur OpenAppMkt

Si vous voulez voir le résultat ou juste supporter mon travail, achetez l’application et n’hésitez pas a me donner votre sentiment vos feedbacks

L’une des caractéristiques qui fait la force de Flash est la simplicité avec laquelle on peut créer très rapidement des animations avec l’IDE composé d’une scène et d’une timeline. Aujourd’hui, il est possible de réaliser la même chose très simplement pour une animation CSS 3 et HTML 5, avec l’outil Sencha Animation

Un outil simple et efficace

Le but de cet outil est de proposer une interface simple et intuitive pour construire des animations HTML 5 et CSS 3 capables de rivaliser avec des animations Flash. On dispose donc d’une scène et d’une timeline et on va pouvoir construire notre animation en ajoutant simplement des objets sur notre scène et en les animant en utilisant la timeline.

Vous pouvez dors et déjà télécharger cet outil sur le site de Sencha Animator : sencha.com

Une expérimentation rapide

L’interface est très claire et le logiciel propose d’entrée un tutoriel bien conçue sous la forme d’une petite animation qui nous montre l’essentiel à connaitre pour démarrer. Nul doute que les habitués de Flash s’approprieront très rapidement l’outil

Pour ma part, en guise de découverte j’ai réalisé une animation très simple avec juste un rectangle et une zone de texte qui se déplacent. La découverte, la prise en main du logiciel et la création de l’animation n’a pris en tout que 5 minutes, ce qui montre bien la simplicité du logiciel. Vous pouvez voir cette animation ici

Il ne vous reste plus qu’à vous lancer et à essayer cet outil très prometteur.

Le support de cours : Découverte de l’environnement et de l’objective C

Télécharger le PDF du cours

Les exercices

Exercice du HelloWorld avec les 2 boutons : Télécharger les sources

Exercice du TextInput : Télécharger les sources

Comment débugger cette erreur et réussir à en trouver la source ? Vous trouverez la réponse dans cet article.

1. Ajouter la variable d’environnement NSZombieEnabled

L’erreur exc_bad_access est souvent due à un accès à une variable qui a déjà été supprimée et relachée. La variable d’environnement NSZombieEnabled permet de garder un traceur sur chaque variable relachée et renvoi une alerte lors de l’accès à l’une d’entre elle. Elle vous permettra donc de remonter à la source de l’erreur.

Pour ce faire, aller dans le menu « Project » dans Xcode et sélectionner « Edit active executable » :

Ensuite allez dans l’onglet « Arguments » puis ajoutez la variable NSZombieEnabled et donnez lui la valeur YES. N’oubliez pas de bien cocher cette variable afin qu’elle soit active :

Arguments -> NSZombieEnabled : YES

2. Voir la source d’une erreur

Après s’être assuré d’être bien en mode Debug, vous pouvez lancer votre programme.
Lors d’une erreur de type exc_bad_access, vous verrez un message comme celui-ci dans la console :

NSZombieEnabled message

Puis allez dans le débugger pour récupérer la source de l’erreur :

Voici le stack de l'erreur avec EXC_BAD_ACCESS

Les méthodes en noir sont les méthode de votre code, il vous suffit de cliquer sur la dernière pour avoir la source de l’erreur :

Stack d'erreur avec NSZombieEnabled

Voilà, vous pouvez voir d’où vient votre erreur et donc la corriger facilement. Une fois fini, n’oubliez pas de décocher la variable NSZombieEnabled car elle ne vous sert plus à rien. Pas besoin de la supprimer, juste de la décocher.

La réponse dans cet article !

HTML 5

Pour la première partie de mon test j’ai donc décidé de tester l’animation de BlackCj sur mon iPhone 4, afin d’avoir un point de comparaison avec Flash sur le même iPhone, voici le résultat :

http://www.youtube.com/watch?v=GNy1Q39wXRI

Le résultat : L’animation tourne à environ 13 images par seconde. Globalement l’animation est très peu fluide et on voit nettement les saccades.

Flash

En utilisant le plugin Frash disponible grâce à @comex qui permet de lire les animations flash sur iPhone et iPad, j’ai lancé le test de BlackCj, voici le résultat :

http://www.youtube.com/watch?v=d-I7PCiWdEk

Le résultat : L’animation affiche une convaincante vitesse moyenne de 30 images par seconde ce qui est bien meilleur que l’animation en HTML 5 canvas. Le résultat est très fluide.

Bilan

Malgré les efforts de Steve Jobs pour lancer l’HTML 5 sur l’iPhone et iPad, on voit encore clairement que Flash est bien plus optimisé et bien plus performant (même la version non officielle de @comex). Les animations HTML 5 canvas ne sont pas prise en charge par le GPU et elles souffrent de performances très faibles. Apple a donc encore du travail à faire sur son iOS

Dans cet article, je vais m’intéressé particulièrement à Android et l’iOS d’Apple, afin de tenter de comprendre pourquoi l’iPhone reste largement devant les autres et pourquoi il a du soucis à se faire.

L’interface utilisateur

Sur ce point, c’est Apple qui a proposé en premier des innovations, en effet, le lancement du premier iPhone a été une révolution planétaire dans le monde du smartphone avec une interface et une facilité d’utilisation qui a bluffé l’ensemble des utilisateurs. Mais qu’en est-il aujourd’hui ?

En effet, depuis, Google a beaucoup progressé et Android en est maintenant à sa version 2.2. Cependant, même si Android reste agréable à utiliser, je trouve que l’interface manque d’intuitivité. Mettons nous dans la peau d’un utilisateur novice, comprendre le fonctionnement d’un iPhone ne lui prendra pas plus de 5 minutes, en revanche pour Android l’affaire se complique.

Tout d’abord dans le choix des couleurs, globalement l’iPhone propose des couleurs lumineuse qui font ressortir les contrastes, ce qui n’est pas du tout le cas d’Android. Les icones sont plus petits et moins colorés, de même le menu principal est très désordonné et on s’y perd très facilement.
La où l’écart se creuse encore plus c’est lorsque l’on se trouve dans un menu tableau comme dans les réglages du téléphone. Lorsque l’iPhone sépare les différentes options en catégories et les présentent de manière synthétique, Android se contente d’une liste sur fond noir de tous les sous menu. Globalement l’interface d’Android demande encore beaucoup de travail pour pouvoir rivaliser avec son rival à la Pomme.

AppStore versus Android Market

Lorsque qu’Android a fait son apparition, tous les pro-iPhone ont parlés de l’AppStore comme de la principale force de l’iPhone du fait de ses nombreuses applications et développeurs. Mais maintenant qu’Android propose l’Android Market, la donne a changé puisque les développeurs ont le choix.

La force de l’Android Market : La liberté des développeurs
En effet, face à l’AppStore d’Apple, la principale force d’Android est de proposer un marché d’applications totalement libre et ouvert. Les développeurs sont libres d’utiliser les librairies, api, outils qui leurs plaisent pour créer leurs applications sans aucune restriction.

Mais au final, que trouve t’on de plus sur l’Android Market que sur l’AppStore : Tout d’abords des applications qui influent sur le fonctionnement du téléphone (sur l’iPhone, une application a sa sand-box de laquelle elle ne peut pas sortir), des widgets (Steve si tu lis cet article, pense-y pour l’iPhone 5), et du porno !
La liberté accordée au développeurs se traduit donc par des applications plus « puissantes » mais pas plus nombreuses ni de meilleure qualité.

L’AppStore : La qualité plutôt que la quantité :

Apple a toujours souhaité mettre en avant la qualité de ses produits et l’appStore n’échappe pas à la règle. Apple vérifie chaque application avant de la mettre sur l’AppStore et les règles sont plutot strictes : Interdiction du porno, controle du contenu, interdiction des versions béta, interdiction des api externes etc…
Mais au final, lorsque l’on regarde le contenu de l’AppStore, on y trouve un plus d’applications de qualité que sur Android, et beaucoup plus d’applications tout court. En effet, Apple a su conserver ses développeurs depuis le début et propose donc toujours un marché d’application très dynamique.

Et l’interface utilisateur ?
Si il y a une chose qui fait la force de l’AppStore face à l’Android Market, c’est bien son interface. En effet, face au Market de Google qui présente les applications en seulement 5 catégories globales et qui laisse l’utilisateur se retrouver au beau milieu de tout ça, Apple propose une sélection de nouveautés de qualité, de nombreuses catégories et sous-catégories et un top 50 des applications gratuites/payantes.
Encore une fois, l’iPhone propose une interface bien plus « user-friendly » qu’Android et c’est encore une fois la principale force d’Apple : l’ergonomie

Les outils de développement : Eclipse VS Xcode

Eclipse : Le paradis du développeur ? Oui ! Sans aucun doute Eclipse est fait pour les développeurs, mais dans le cadre d'une application mobile où l'on aime soigner l'interface et l'ergonomie, il est bien souvent plus difficile qu'avec un outil graphique de produire une interface facilement pour son application Android.
Ceci étant dit, le SDK d’Android s’installe très facilement sur Mac / PC / Linux et permet avec un simple plugin Eclipse de programmer très facilement et très rapidement. Google propose donc un bon outil de développement très accessible, mais qui ne plaira pas forcément aux graphistes.

Xcode, le Mac pour le Mac
Apple propose lui aussi une gamme d’outil pour développer pour l’iPhone, ces outils sont les suivants : Xcode pour le code, Interface Builder pour l’interface graphique et le Simulateur iPhone pour tester votre applications. Ces outils sont, comme ceux de Google, gratuits.
La où Apple fait fort, c’est qu’il a su réutiliser les outils pour développer pour Mac OS pour l’iPhone, on a donc un panel d’applications très bien pensés, et très bien rodés qui sont a la fois très pratique pour coder, et qui propose également un outil spécial pour créer son interface graphique, idéal pour satisfaire graphistes et développeurs. Notons également que la documentation et les examples de codes sont très fournis et très complets.
Cependant, tout n’est pas parfait puisque ces outils ne sont disponibles que sur Mac, il vous faut donc une machine Apple pour produire une application pour l’iPhone.

Un seul terminal contre des centaines

Un dernier point important à souligner est le fait que l’iPhone est fait par Apple et pour Apple. L’OS est donc optimisé et les mise à jours sont régulières. Apple a toujours adopté cette philosophie, c’est la raison pour laquelle ils fabriquent eux même tout leurs ordinateurs et périphériques.
En revanche, un des problèmes (mais aussi une des forces) d’Android est le fait que plusieurs marques fabriquent des téléphones fonctionnant sous Android et certains ne possèdent pas toutes les fonctionnalités du système. De même, les mise à jours doivent être adaptées par les constructeurs pour leurs mobiles et c’est souvent très long, voir même impossible des fois (ex : le HTC Hero qui ne verra jamais Android Froyo 2.2).

Récapitulatif

Afin de synthétiser l’ensemble, voici un petit tableau récapitulatif des avantages et problèmes de chacun :

Vous l’aurez compris, selon moi, Apple a encore de nombreux atouts face à Google, même si Android rattrape de plus en plus son retard et propose beaucoup de fonctionnalités exclusives. Apple joue la carte de la qualité pour l’utilisateur final et reste fidèle à ses convictions : proposer le meilleur produit possible pour l’utilisateur, ce qui reste pour le moment, un choix payant. Cependant, Android va prendre de plus en plus de parts de marché et nul doute que la marque à la pomme a du soucis a se faire.