Perché è necessario testare la mia app per iPhone sul dispositivo iPhone reale

Ho sviluppato un'applicazione per iPhone e ora la voglio su App Store. Così tanti miei amici geek iOS mi hanno detto di testarlo sul dispositivo reale, cioè su iPhone.

Quindi mi chiedo perché sia ​​necessario testare la mia app per iPhone sul dispositivo iPhone reale anche se (Apple) hanno dato il "simulatore" che è quasi uguale al mio dispositivo?

Devi testare l'applicazione sul dispositivo reale almeno per vedere come si comporta:

• Hardware del dispositivo reale
• Connessione Internet reale (incluso l'uso di una rete cellulare vs WiFi)
• Le dita invece del mouse
• Prestazioni con altre app in esecuzione in background
• I limiti di iPhone, come CPU, capacità del disco e memoria ( Un simulatore non è un emulatore ).
• Contesto reale: è facile usare l'app sul treno o mentre si cammina per strada? Che ne dici di una luce solare intensa o sotto la pioggia?

Sviluppatori iOS, continua questo elenco.

Una cosa che non saprai mai durante i test con l'emulatore è come ci si sente davvero per un utente che tiene in mano un dispositivo reale, facendo scorrere le dita sullo schermo. Di conseguenza, le azioni dell'utente che sembravano fluide durante la simulazione con il touchpad sul laptop, possono risultare piuttosto ingombranti per un utilizzo reale del dispositivo. Per assicurarti che la tua applicazione sia OK, testala con un dispositivo reale.

Un'altra cosa che vale la pena testare con un dispositivo reale è il consumo della batteria. Quello è davvero più sicuro testare con un dispositivo reale piuttosto che fare affidamento su quanto gli sviluppatori di simulatori sono riusciti a riprodurlo nel loro strumento.

Potrebbero esserci altre cose che non sono abbastanza vicine al simulatore. Il volume e il bilanciamento dell'audio, ad esempio, il modo in cui suona sul tuo laptop, può differire da come sarà su un telefono reale. La vibrazione è un altro esempio che è appena possibile ottenere con il simulatore. Il modo in cui i sensori giroscopici funzionano sul telefono reale. GPS / cose relative alla posizione. Ecc ecc ecc ...

Il test simulatore vs dispositivo reale è un problema piuttosto importante. In uno dei miei progetti passati, una parte importante del successo commerciale è stata un attento bilanciamento tra questo tipo di test, che si riduce essenzialmente a domande permanenti come il perché sul dispositivo?

Il vero lavoro inizia quando ci si chiede perché , scegliendo i motivi per scegliere tra test sul dispositivo e simulatore in casi e situazioni particolari.

Ignorare i test sui dispositivi espone il tuo prodotto a un rischio (piuttosto elevato) di rottura nelle mani dell'utente finale, distruggendo completamente tutti gli sforzi fatti nello sviluppo. Il fatto è che il test del simulatore è molto più economico e molto più semplice per l'automazione. Se ci si attiene ciecamente a test solo su dispositivo, le loro versioni potrebbero diventare sostanzialmente successive e più costose di quelle dei concorrenti.

Per esperienza e un decollo dalla risposta più votata:

• Le tue dita invece del mouse sono state la differenza più grande quando abbiamo sviluppato Decimation X2 per Windows Phone 7. Era codificato su un emulatore, poiché non avevamo un WP7 ed era prima che il WP7 fosse rilasciato. Potremmo aver potenzialmente ricevuto un WP7 gratuito prima del rilascio, nel caso in cui l'ultima frase non avesse senso per te, poiché siamo stati invitati da Microsoft ad avere un titolo di lancio sul loro telefono. Si è scoperto che ciò che volevamo che l'utente facesse con le dita era molto difficile sul telefono reale, ma facile con un mouse. E aveva a che fare con i casi sullo schermo. Sfortunatamente il nostro gioco ha richiesto che le tue dita fossero sempre sul bordo dello schermo, cosa che alcuni telefoni hanno reso difficile da fare a causa del loro schermo infossato e delle custodie spesse. In realtà abbiamo pubblicato una patch per risolvere questo problema. Ciò significa che tutti i nostri utenti principianti hanno mostrato un cattivo, e potenzialmente inutilizzabile, versione del nostro gioco. :(

• La successiva differenza hardware era la differenza maggiore. Abbiamo dovuto indovinare letteralmente con il metodo impreciso di prendere la nostra versione Xbox 360 del gioco e declassarla di conseguenza a metà del frame rate (da 60fps a 30fps) e un terzo di GHz (da 3,0 GHz a 1,0 GHz), e abbiamo indovinato sbagliato. I processori erano diversi, ovviamente, e lo sapevamo. Senza l'hardware, ci rimanevano ipotesi sbagliate. Non è stata una nostra scelta in quanto non avevamo WP7, ma abbiamo imparato la lezione che sto condividendo con te adesso. Su alcuni telefoni, durante le parti più intense del gioco, è caduto frame. :( A nessuno sembrava importare, dato che presumevano che il rallentamento fosse appropriato per parti così intense. Quindi non è stato un grosso problema, ma il punto è: se questo fosse stato un grosso problema, la "app" sarebbe stata interrotta dalle nostre congetture insignificanti.

Test su hardware reale. E quando codifichi vari hardware del telefono, verifica su quelli di fascia bassa se le prestazioni sono un problema.

IPhone Simulator implementa alcune API che l'iPhone stesso non ha (La principale che viene in mente è l'API DOM XML, dove l'iPhone supporta solo SAX per quanto ne so, questo potrebbe essere cambiato anche se ora.)

Ti farà anche 'sentire' l'app, i tuoi pulsanti hanno le dimensioni giuste? I pulsanti giusti cadono sotto il pollice? L'iPhone è in grado di eseguire l'app? Il simulatore non è un emulatore e funziona semplicemente aggiungendo Cocoa Touch al Mac desktop per quell'app. Devi simulare avvisi di memoria esaurita e simili.

Perché non avrai molti utenti in giro con un simulatore in tasca.

EDIT: Ogni volta che testate la vostra app su un simulatore (o emulatore), utilizzate un dispositivo falso che non può essere, per definizione, una rappresentazione accurata al 100% della realtà. Un emulatore potrebbe essere più preciso di un simulatore, ma ci saranno comunque differenze. L'unico emulatore preciso al 100% è il dispositivo stesso.

La progettazione, il test e l'ottimizzazione del codice su un simulatore si traducono in un'applicazione ottimizzata per funzionare in modo ottimale su un simulatore. Tuttavia, i tuoi utenti non avranno simulatori; stai prendendo di mira il dispositivo sbagliato. Molto simile; ma non lo stesso dispositivo utilizzato dagli utenti.

Questo può portare a diversi tipi di problemi. Problemi gravi come bug e arresti anomali sono sicuramente la tua priorità assoluta. Ma ce ne sono altri; come l'ergonomia. Prova a tenere il simulatore in mano. Prova. Gli elementi dell'interfaccia utente vengono visualizzati su uno schermo diverso, con una resa cromatica possibilmente diversa e certamente dimensioni diverse (un problema aggravato dai bellissimi display retina, non del tutto risolto utilizzando anche un macbook retina, ad esempio). Quelle squisite tonalità di grigio sono ugualmente distinguibili su un dispositivo al sole?

Le sottili differenze di velocità e la diversa emulazione del sensore (o la sua mancanza) possono talvolta alterare drasticamente l'esperienza.

Se l'applicazione si basa sulla connettività Internet, non è possibile alternare tra LTE, 3G, EDGE o GPRS, testare scenari diversi o testare operatori diversi.

Supporterai i dispositivi jailbreak? Forse non lo sei, ma se lo sei, probabilmente sei disposto a testare la tua app con uno. Oppure, se non lo sei, sei sicuro di rilevare un ambiente jailbreak?

Il gioco per iPad che stai sviluppando sul simulatore è ugualmente utilizzabile quando un utente tiene il suo peso e usa le dita per giocare? I tocchi multipli non intenzionali sono in grado di interrompere la tua app, cosa che non sei stato in grado di anticipare nell'ambiente simulatore a singolo tocco (o doppio simmetrico)?

Ti sentiresti a tuo agio a bordo di un aereo comandato da un pilota che non ha mai lasciato il suolo?

La linea di fondo è: prima della spedizione, si prega di utilizzare lo stesso dispositivo che verranno utilizzati dagli utenti. Nessuno di loro utilizzerà un simulatore.

motivo pratico:

1) Non hai "invia posta" funzionante.

2) Non è possibile mettere il dispositivo sottosopra.

e ovviamente già detto motivo:

3) larghezza di banda ridotta

4) potenza computazionale molto piccola rispetto al simulatore

5) Le chiamate Open GL sono implementate in modo leggermente diverso nel simulatore

6) spazio su disco / RAM ..

Mentre è stato menzionato che le prestazioni dell'hardware sono generalmente peggiori, va notato che questo non è il caso di OpenGL ES. Il simulatore lo implementa nel software, quindi non è raro notare un enorme aumento delle prestazioni durante l'esecuzione sul dispositivo stesso.

Inoltre, ci sono alcune piccole differenze tra le implementazioni software e hardware di Open GL ES, ad esempio i suggerimenti sulla precisione dello shader potrebbero avere output diversi.

Quando implementiamo cose per iOS (o Android o Windows Phone), sviluppiamo non per il desktop ma per il dispositivo. Per alcune applicazioni di calcolo / ricche di risorse, ciò può comportare un comportamento normale sul simulatore, MA problemi sul dispositivo reale.

Quindi situazioni come questa possono essere incontrate in fasi successive se non testiamo sul dispositivo dall'inizio: -

• Avvisi / arresti anomali della memoria
• Frame rate OpenGL a una cifra

Ci sono alcune funzionalità come PushNotification , utilizzo della fotocamera , ecc. Che possiamo testare solo su un dispositivo; queste sono funzionalità che non possono essere testate su un simulatore.

E testare l'app su un dispositivo reale prima dell'invio all'App Store riduce le possibilità di rifiuto dell'app; a volte un'app funziona bene nel simulatore ma si arresta in modo anomalo su un dispositivo reale, motivo principale per il rifiuto dell'app.

Ci possono essere reali differenze di prestazioni tra il dispositivo reale e l'emulatore. Abbiamo scoperto che solo i test con l'emulatore hanno prodotto un'app molto lenta in molti casi, cosa che non ci aspettavamo.

L'esperienza dell'utente varia da un dispositivo all'altro a causa del diverso sistema operativo e

specifiche hardware. Quindi, è necessario testare un'app per iPhone sul reale

dispositivi: dispositivi mobili che eseguono varie versioni di iOS sul mercato.

Sebbene un simulatore sia utile per identificare eventuali problemi incontrati dall'utente finale,

testare l'app sul dispositivo originale aiuterà a identificare e indirizzare i principali

preoccupazioni dell'utente.