Pourquoi il est nécessaire de tester mon application iPhone sur un appareil iPhone réel

J'ai développé une application pour iPhone et maintenant je la veux sur l'App Store. Beaucoup de mes amis geek iOS m'ont dit de le tester sur un appareil réel, c'est-à-dire sur un iPhone.

Je me demande donc pourquoi il est nécessaire de tester mon application iPhone sur un appareil iPhone réel alors qu'ils (Apple) ont donné un "simulateur" qui est à peu près le même que mon appareil?

Vous devez tester l'application sur un appareil réel pour au moins voir comment elle se comporte avec:

• Matériel matériel réel
• Connexion Internet réelle (y compris l'utilisation d'un réseau cellulaire vs WiFi)
• Vos doigts au lieu de la souris
• Performances avec d'autres applications s'exécutant en arrière-plan
• Les limites de l'iPhone, comme le processeur, la capacité du disque et la mémoire ( un simulateur n'est pas un émulateur ).
• Contexte réel: est-il facile d'utiliser votre application dans le train ou en marchant dans la rue? Que diriez-vous en plein soleil ou sous la pluie?

Développeurs iOS, veuillez continuer cette liste.

Une chose que vous ne saurez jamais lorsque vous testez avec l'émulateur est ce que cela fait vraiment pour un utilisateur tenant un vrai appareil dans sa main, en faisant glisser ses doigts sur son écran. En conséquence, les actions des utilisateurs qui semblaient fluides lors de la simulation avec le pavé tactile de votre ordinateur portable peuvent s'avérer assez lourdes pour une utilisation réelle de l'appareil. Pour vous assurer que votre application est OK, testez-la avec un appareil réel.

Une autre chose qui mérite d'être testée avec un appareil réel est la consommation de la batterie. Celui-ci est vraiment plus sûr de simplement tester avec un appareil réel que de compter sur la capacité des développeurs de simulateurs à le reproduire dans leur outil.

Il peut y avoir d'autres choses qui ne sont tout simplement pas assez proches dans le simulateur. Le volume et l'équilibre audio par exemple - la façon dont cela sonne sur votre ordinateur portable peut différer de ce qu'il sera sur un vrai téléphone. La vibration est un autre exemple qui est à peine possible pour réussir avec le simulateur. La façon dont les capteurs gyroscopiques fonctionnent sur le vrai téléphone. Trucs liés au GPS / à la localisation. Etc etc etc ...

Le test du simulateur par rapport à un appareil réel est un problème assez important. Dans l'un de mes projets antérieurs, une partie importante du succès commercial a été un équilibre prudent entre ces types de tests, qui se résume essentiellement à une nouvelle question permanente, comme pourquoi sur l'appareil?

Le vrai travail commence quand on demande pourquoi , en choisissant les raisons de choisir entre les tests sur appareil et sur simulateur dans des cas et des situations particuliers.

Ignorer les tests de périphérique expose votre produit à un risque (assez élevé) de tomber entre les mains de l'utilisateur final, détruisant complètement tous les efforts que vous consacrez au développement. Mais le fait est que les tests sur simulateur sont BEAUCOUP moins chers et beaucoup plus faciles à automatiser. Si l'on s'en tient aveuglément aux tests sur appareil uniquement, leurs versions pourraient devenir beaucoup plus tardives et plus chères que celles des concurrents.

L'expérience et le décollage de la meilleure réponse votée:

• Vos doigts au lieu de la souris étaient la plus grande différence lorsque nous avons développé Decimation X2 pour Windows Phone 7. Il était codé sur un émulateur, car nous n'avions pas de WP7 et c'était avant la sortie du WP7. Nous aurions pu potentiellement recevoir un WP7 gratuit avant sa sortie, au cas où cette dernière phrase n'aurait aucun sens pour vous, car nous avons été invités par Microsoft à avoir un titre de lancement sur leur téléphone. Il s'est avéré que ce que nous voulions que l'utilisateur fasse avec ses doigts était très dur sur le vrai téléphone, mais facile avec une souris. Et cela avait à voir avec les cas bord d'écran. Malheureusement, notre jeu exigeait que vos doigts soient tout le temps au bord de l'écran, ce que certains téléphones ont rendu difficile à faire en raison de leur écran coulé ainsi que des étuis épais. Nous avons en fait mis un correctif pour résoudre ce problème. Cela signifie que tous nos utilisateurs pour la première fois se sont vus présenter un mauvais comportement, et potentiellement inutilisable, version de notre jeu. :(

• La vitesse matérielle différente était la deuxième plus grande différence. Nous devions littéralement deviner par la méthode inexacte de prendre notre version Xbox 360 du jeu et de la rétrograder en conséquence à la moitié de la fréquence d'images (60fps à 30fps) et au tiers du GHz (3,0 GHz à 1,0 GHz), et nous avons deviné faux. Les processeurs étaient différents, bien sûr, et nous le savions. Sans le matériel, nous nous sommes retrouvés avec des conjectures boiteuses. Ce n'était pas notre choix car nous n'avions pas de WP7, mais nous avons appris la leçon que je partage avec vous maintenant. Sur certains téléphones, pendant les parties les plus intensives du jeu, il a perdu des images. :( Personne ne semblait s'en soucier car ils supposaient que le ralentissement était approprié pour des parties aussi intenses. Ce n'était donc pas un gros problème, mais le fait est que si cela avait été un gros problème, l'application aurait été rompue avec nos conjectures boiteuses.

Testez sur du vrai matériel. Et lorsque vous codez pour divers matériels de téléphone, testez sur les terminaux les plus bas si les performances sont un problème.

L'iPhone Simulator implémente certaines API que l'iPhone lui-même ne fait pas (la principale qui me vient à l'esprit étant l'API DOM XML, où l'iPhone ne prend en charge que SAX à ma connaissance, cela pourrait avoir changé cependant maintenant.)

Il vous permettra également de «sentir» l'application, vos boutons sont-ils de la bonne taille? Les bons boutons tombent-ils sous le pouce? L'iPhone est-il prêt à exécuter l'application? Le simulateur n'est pas un émulateur et fonctionne en ajoutant simplement Cocoa Touch à votre Mac de bureau pour cette application. Vous devez simuler des avertissements de mémoire insuffisante, etc.

Parce que vous n'allez pas avoir beaucoup d'utilisateurs qui se promènent avec un simulateur dans leur poche.

EDIT: Chaque fois que vous testez votre application sur un simulateur (ou émulateur), vous utilisez un faux appareil qui ne peut pas, par définition, être une représentation 100% précise de la réalité. Un émulateur peut être plus précis qu'un simulateur, mais il y aura toujours des différences. Le seul émulateur 100% précis est l'appareil lui-même.

La conception, le test, l'optimisation du code sur un simulateur se traduisent par une application qui est finement ajustée pour fonctionner de manière optimale sur un .. simulateur. Vos utilisateurs n'auront cependant pas de simulateurs; vous ciblez le mauvais appareil. Un très similaire; mais pas le même appareil que vos utilisateurs utiliseront.

Cela peut entraîner plusieurs types de problèmes. Les problèmes graves comme les bugs, les plantages sont certainement votre priorité absolue. Mais il y en a d'autres; comme l'ergonomie. Essayez de tenir le simulateur dans votre main. Essayez. Les éléments de l'interface utilisateur sont rendus sur un écran différent, avec éventuellement un rendu des couleurs différent et certainement des dimensions différentes (un problème exacerbé par les beaux écrans rétine, pas entièrement résolu en utilisant également un macbook rétine, par exemple). Ces nuances de gris exquises se distinguent-elles également sur un appareil au soleil?

De subtiles différences de vitesse et différentes émulations de capteurs (ou leur absence) peuvent parfois modifier considérablement l'expérience.

Si votre application repose sur la connectivité Internet, vous n'avez aucun moyen de basculer entre LTE, 3G, EDGE ou GPRS, pour tester différents scénarios, ou même tester différents opérateurs.

Allez-vous prendre en charge les appareils jailbreakés? Peut-être pas, mais si vous l'êtes, vous êtes probablement prêt à tester votre application avec une. Ou, si vous ne l'êtes pas, êtes-vous sûr de détecter un environnement jailbreaké?

Le jeu iPad que vous développez sur le simulateur est-il également utilisable lorsqu'un utilisateur tient son poids et utilise ses doigts pour jouer? Des touches multiples involontaires sont-elles capables de casser votre application, quelque chose que vous ne pouviez pas anticiper dans l'environnement de simulateur sécurisé à une seule touche (ou à deux touches symétriques)?

Seriez-vous à l'aise à bord d'un avion commandé par un pilote qui n'a jamais réellement quitté le sol?

L'essentiel est: avant l'expédition, veuillez utiliser le même appareil que vos utilisateurs vont utiliser. Aucun d'entre eux n'utilisera de simulateur.

raison pratique:

1) Vous n'avez pas de fonction "envoyer du courrier".

2) Vous ne pouvez pas mettre l'appareil à l'envers.

et bien sûr déjà dit la raison:

3) faible bande passante

4) très petite puissance de calcul par rapport au simulateur

5) Les appels Open GL sont implémentés un peu différemment dans le simulateur

6) espace disque / RAM ..

Bien qu'il ait été mentionné que les performances du matériel sont généralement moins bonnes, il faut noter que ce n'est pas le cas avec OpenGL ES. Le simulateur l'implémente dans un logiciel, il n'est donc pas rare de constater une énorme augmentation des performances lors de l'exécution sur l'appareil lui-même.

De plus, il existe quelques différences mineures entre les implémentations logicielles et matérielles d'Open GL ES, par exemple les indices de précision des shaders peuvent avoir des sorties différentes.

Lorsque nous implémentons des choses pour iOS (ou Android, ou Windows Phone), nous développons non pas pour le bureau mais pour l'appareil. Pour certaines applications de calcul / gourmandes en ressources, cela peut signifier un comportement normal sur le simulateur MAIS des problèmes sur le périphérique réel.

Donc, des situations comme celle-ci peuvent être rencontrées dans les étapes ultérieures si nous ne testons pas sur l'appareil depuis le début: -

• Avertissements / plantages de mémoire
• Fréquences d'images OpenGL à un chiffre

Il existe certaines fonctionnalités comme PushNotification , l' utilisation de la caméra , etc. que nous ne pouvons tester que sur un appareil; ce sont des fonctionnalités qui ne peuvent pas être testées sur un simulateur.

Et tester votre application sur un appareil réel avant de la soumettre à l'App Store réduit les chances de rejet de l'application; Parfois, une application fonctionne bien dans le simulateur, mais elle se bloque sur un appareil réel, ce qui est la principale raison des rejets d'applications.

Il peut y avoir de réelles différences de performances entre le périphérique réel et l'émulateur. Nous avons constaté que seuls les tests avec l'émulateur entraînaient une application très lente dans de nombreux cas, ce à quoi nous ne nous attendions pas.

L'expérience utilisateur varie d'un appareil à l'autre en raison de différents OS et

spécifications matérielles. Par conséquent, il est nécessaire de tester une application iPhone sur le

appareils - appareils mobiles exécutant diverses versions d'iOS sur le marché.

Bien qu'un simulateur soit utile pour identifier les problèmes rencontrés par l'utilisateur final,

tester l'application sur l'appareil d'origine aidera à identifier et à traiter les principaux

préoccupations de l'utilisateur.