Por que é necessário testar meu aplicativo para iPhone no dispositivo real do iPhone

Desenvolvi um aplicativo para iPhone e agora quero na App Store. Muitos dos meus amigos geeks do iOS me disseram para testá-lo no dispositivo atual, ou seja, no iPhone.

Então, eu me pergunto por que é necessário testar meu aplicativo para iPhone no dispositivo real do iPhone, apesar de eles (Apple) terem dado "simulador", que é quase o mesmo que o meu dispositivo?

Você precisa testar o aplicativo no dispositivo real para, pelo menos, ver como ele se comporta com:

• Hardware de dispositivo real
• Conexão de internet real (incluindo o uso de uma rede celular vs WiFi)
• Seus dedos em vez de mouse
• Desempenho com outros aplicativos em execução em segundo plano
• As limitações do iPhone, como CPU, capacidade do disco e memória ( um simulador não é um emulador ).
• Contexto real: é fácil usar seu aplicativo no trem ou andando na rua? Que tal sob luz solar intensa ou na chuva?

Desenvolvedores de iOS, continue esta lista.

Uma coisa que você nunca saberá ao testar com emulador é como realmente se sente para um usuário segurando um dispositivo real na mão, deslizando os dedos na tela. Como resultado, as ações do usuário que pareceram suaves ao simular com o touchpad no seu laptop podem se tornar bastante complicadas para o uso real do dispositivo. Para garantir que seu aplicativo esteja bom, teste-o com o dispositivo real.

Outra coisa que vale a pena testar com o dispositivo real é o consumo de bateria. Esse é realmente mais seguro testar apenas com dispositivos reais do que depender de quão bem os desenvolvedores de simuladores conseguiram reproduzi-los em suas ferramentas.

Pode haver outras coisas que simplesmente não estão próximas o suficiente no simulador. O volume e o equilíbrio do áudio, por exemplo - a maneira como soa no seu laptop, pode diferir de como será em um telefone real. A vibração é outro exemplo que dificilmente é possível acertar com o simulador. A maneira como os sensores de giroscópio funcionam no telefone real. Material relacionado ao GPS / localização. Etc etc etc ...

Simulador vs teste de dispositivo real é uma questão bastante importante. Em um dos meus projetos anteriores, uma parte importante do sucesso comercial foi um cuidadoso equilíbrio entre esses tipos de teste, que basicamente se resume a re-perguntas permanentes, como por que no dispositivo?

O trabalho real começa quando se pergunta o porquê , escolhendo os motivos para escolher entre os testes no dispositivo e no simulador em casos e situações específicos.

Ignorar o teste do dispositivo expõe seu produto a um risco (bastante alto) de invadir as mãos do usuário final, destruindo completamente todos os esforços que você coloca no desenvolvimento. Mas o fato é que o teste em simulador é MUITO mais barato e muito mais fácil para automação. Se alguém cegamente aderir a testes apenas no dispositivo, seus lançamentos poderão se tornar substancialmente mais tarde e mais caros do que os dos concorrentes.

Por experiência e uma decolagem da melhor resposta votada:

• Seus dedos em vez do mouse foram a maior diferença quando desenvolvemos o Decimation X2 para o Windows Phone 7. Ele foi codificado em um emulador, pois não tínhamos um WP7 e foi antes do lançamento do WP7. Poderíamos ter potencialmente recebido um WP7 gratuito antes do lançamento, caso essa última frase não fizesse sentido para você, pois fomos convidados pela Microsoft a ter um título de lançamento em seu telefone. Aconteceu que, o que queríamos que o usuário fizesse com os dedos era muito duro com o telefone real, mas fácil com o mouse. E isso tinha a ver com casos extremos da tela. Infelizmente, nosso jogo exigia que seus dedos estivessem na borda da tela o tempo todo, o que alguns telefones dificultavam devido à tela afundada e às caixas grossas. Na verdade, lançamos um patch para corrigir isso. Isso significa que todos os nossos usuários iniciantes foram prejudicados e potencialmente inutilizáveis, versão do nosso jogo. :(

• A velocidade diferente do hardware foi a segunda maior diferença. Tivemos que adivinhar, literalmente, pelo método impreciso de pegar nossa versão do jogo para Xbox 360 e rebaixá-la de acordo com metade da taxa de quadros (60fps a 30fps) e um terço da GHz (3.0GHz a 1.0GHz), e adivinhamos errado. Os processadores eram diferentes, é claro, e sabíamos disso. Sem o hardware, ficamos com suposições sujas. Não foi nossa escolha, pois não tínhamos WP7, mas aprendemos a lição que estou compartilhando com você agora. Em alguns telefones, durante as partes mais intensas do jogo, os quadros foram perdidos. :( Ninguém parecia se importar, pois eles supunham que a desaceleração era apropriada para partes tão intensas. Portanto, não era grande coisa, mas o ponto é: se isso tivesse sido um grande problema, o "aplicativo" teria sido quebrado de nossas suposições.

Teste em hardware real. E quando você codifica para vários hardwares de telefone, teste nos inferiores, se o desempenho for um problema.

O iPhone Simulator implementa algumas APIs que o próprio iPhone não implementa (a principal delas é a API DOM XML, onde o iPhone suporta apenas SAX, pelo que sei, isso pode ter mudado agora.)

Também permitirá que você "sinta" o aplicativo. Seus botões têm o tamanho certo? Os botões certos caem sob o polegar? O iPhone está pronto para executar o aplicativo? O simulador não é um emulador e funciona apenas adicionando o Cocoa Touch ao Mac da área de trabalho para esse aplicativo. Você precisa simular avisos de falta de memória e similares.

Porque você não terá muitos usuários andando com um simulador no bolso.

EDIT: Sempre que você está testando seu aplicativo em um simulador (ou emulador), está usando um dispositivo falso que não pode ser, por definição, uma representação 100% precisa da coisa real. Um emulador pode ser mais preciso que um simulador, mas ainda haverá diferenças. O único emulador 100% preciso é o próprio dispositivo.

Projetar, testar e otimizar o código em um simulador resulta em um aplicativo aprimorado para otimizar o trabalho em um simulador. Seus usuários não terão simuladores; você está segmentando o dispositivo errado. Um muito parecido; mas não o mesmo dispositivo que seus usuários usarão.

Isso pode levar a vários tipos de problemas. Problemas graves como bugs, falhas são certamente a sua principal prioridade. Mas existem outros; como ergonomia. Tente segurar o simulador na sua mão. Apenas tente. Os elementos da interface do usuário são renderizados em uma tela diferente, com renderização de cores possivelmente diferente e certamente dimensões diferentes (um problema exacerbado pelas belas telas da retina, não totalmente resolvido usando também um macbook de retina, por exemplo). Esses requintados tons de cinza são igualmente distinguíveis em um dispositivo ao sol?

Diferenças sutis de velocidade e emulação de sensor diferente (ou falta dela), às vezes podem alterar drasticamente a experiência.

Se seu aplicativo depende da conectividade com a Internet, não há como alternar entre LTE, 3G, EDGE ou GPRS, para testar diferentes cenários ou até para diferentes operadoras.

Você suporta dispositivos jailbroken? Talvez você não esteja, mas se estiver, provavelmente está disposto a testar seu aplicativo com um. Ou, se não estiver, tem certeza de que está detectando um ambiente com jailbreak?

O jogo para iPad que você está desenvolvendo no simulador é igualmente utilizável quando um usuário está segurando seu peso e usando os dedos para jogar? Vários toques não intencionais são capazes de interromper seu aplicativo, algo que você não conseguiu antecipar no ambiente seguro do simulador de toque único (ou toque duplo simétrico)?

Você se sentiria confortável em embarcar em um avião comandado por um piloto que nunca saiu do chão?

A linha inferior é: antes do envio, use o mesmo dispositivo que seus usuários vão usar. Nenhum deles vai usar um simulador.

razão prática:

1) Você não tem "enviar email" funcionando.

2) Você não pode colocar o dispositivo de cabeça para baixo.

e, claro, já disse o motivo:

3) baixa largura de banda

4) poder computacional muito pequeno comparado ao simulador

5) As chamadas GL abertas são implementadas um pouco diferentes no simulador

6) espaço em disco / RAM ..

Embora tenha sido mencionado que o desempenho do hardware geralmente é pior, deve-se notar que esse não é o caso do OpenGL ES. O simulador o implementa no software, para que não seja incomum, perceber um grande aumento de desempenho durante a execução no próprio dispositivo.

Além disso, existem algumas pequenas diferenças entre as implementações de software e hardware do Open GL ES, por exemplo, dicas de precisão do sombreador podem ter saídas diferentes.

Quando implementamos coisas para iOS (ou Android ou Windows Phone), desenvolvemos não para a área de trabalho, mas para o dispositivo. Para algumas aplicações de cálculo / com muitos recursos, isso pode significar um comportamento normal no simulador, mas com problemas no dispositivo real.

Portanto, situações como essa podem ser encontradas em estágios posteriores se não testarmos no dispositivo desde o início: -

• Avisos / falhas de memória
• Taxas de quadro OpenGL de um dígito

Existem alguns recursos, como PushNotification , usando a câmera , etc., que só podemos testar em um dispositivo; esses são recursos que não podem ser testados em um simulador.

E testar seu aplicativo em um dispositivo real antes do envio à App Store reduz as chances de rejeição do aplicativo; Às vezes, um aplicativo funciona bem no simulador, mas trava em um dispositivo real, o que é o principal motivo de rejeições de aplicativos.

Pode haver diferenças reais de desempenho entre o dispositivo real e o emulador. Descobrimos que apenas o teste com o emulador resultou em um aplicativo muito lento em muitos casos, o que não esperávamos.

A experiência do usuário varia de um dispositivo para outro devido a diferentes sistemas operacionais e sistemas operacionais.

especificações de hardware. Portanto, é necessário testar um aplicativo para iPhone no

dispositivos - dispositivos móveis executando várias versões do iOS no mercado.

Embora um simulador seja útil para identificar quaisquer problemas enfrentados pelo usuário final,

testar o aplicativo no dispositivo original ajudará a identificar e abordar os principais

preocupações do usuário.