Distribuindo o aplicativo beta para usuários remotos

8

Parece que não há uma solução simples para fornecer meu aplicativo beta para iOS a pessoas fora do contato físico. As maneiras que eu descobri para fazer isso SEM usar a App Store (que a Apple diz explicitamente que não é para testes beta) são:

  1. Use o Developer Enterprise Program; Caro e excessivo

  2. Use TestFlight; Somente 25 testadores "internos" são permitidos antes que diretrizes extremas sejam implementadas para mais pessoas (por que não colocá-lo na App Store neste momento ...?)

  3. Dê a eles todo o meu projeto Xcode e peça ao usuário que o construa em seu próprio ambiente Xcode; Impossível pedir a pessoas que não entendem de tecnologia + Não quero dar meu projeto a pessoas fora da minha empresa

  4. Desenvolvimento Ad-Hoc; Faça com que todos me dêem seus UDIDs ... Enorme aborrecimento para os outros / As pessoas podem não querer fazer isso fora da minha empresa

O aplicativo que estou desenvolvendo será usado por pessoas da comunidade científica para controlar um dispositivo específico que minha empresa está fabricando. Há uma chance de que talvez nunca atenda aos padrões da Apple para aplicativos na App Store, mas possa ser usado por mais de 100 pessoas em um futuro próximo. Acho que a verdadeira pergunta que faço é: como faço para obter meu aplicativo beta "sub-par" para um grande grupo de pessoas?

Jel
fonte

Respostas:

2

No passado, você teria que escolher entre o aplicativo Hockey e o TestFlight para grandes grupos beta - mas agora que a Apple comprou o TestFlight e você precisa passar por uma revisão para obter uma versão beta, a estrutura de testes beta do aplicativo Hockey é a mais adequada às suas necessidades listados.

Ele ajuda a lidar com a inscrição e o gerenciamento de usuários para que as construções sejam notificadas e entregues aos usuários finais. Você ainda está decidido a gerenciar seu pool de testes de AppleID, mas agora que o limite de 100 dispositivos foi diminuído, é possível fazer testes beta bastante amplos usando os limites normais de conta de desenvolvedor pagos da Hockey e da Apple.

A longo prazo, você desejará colocar o aplicativo em uma das lojas da Apple, já que "abusar" da assinatura de distribuição corporativa custa caro em tempo e dinheiro para configurar e ao longo do tempo, não é tão difícil obter um aplicativo através da revisão. Sim, você pode demorar um mês ou dois ou mais, mas se persistir, é um aplicativo raro que não pode ser implantado, a menos que você esteja violando uma das regras que a Apple mais se importa, como incluir estruturas que usam API privada ou que são executadas código que eles baixam após o aplicativo ser assinado e enviado para aprovação.

Sua única outra opção é enviar o código-fonte para cada usuário e fazer com que eles usem o Xcode para criar, assinar automaticamente e instalar seu próprio aplicativo. Isso pode levar a usuários motivados de um aplicativo especializado. O GitHub ou outras ferramentas de origem o ajudariam a enviar atualizações, mas você apoiaria as pessoas e possivelmente cobraria por isso, em vez do próprio aplicativo nesse modelo.

bmike
fonte
Portanto, não há como distribuir meu aplicativo sem obter previamente os UDIDs de todas as pessoas para quem eu quero entregá-lo? Ugh, explode em minha mente que eu não posso simplesmente enviar e-mail o arquivo .ipa a ninguém e tê-los soltá-lo em suas próprias itunes
Jel
@jel - não. Você pode usar o AppleID via TestFlight ou um serviço que colhe o UDID para você. Isso ocorre por design - o iOS não deseja carregar aplicativos lateralmente. Desde 29 de junho de 2007, esse é o padrão e não vejo mudanças tão cedo. Especialmente porque o iOS 9 e o Xcode permitem que qualquer pessoa assine "seus próprios" aplicativos.
bmike
2

Você pode usar o TestFlight para testadores beta externos. Isso permitirá que você teste com até 2.500 testadores externos. Você não precisa conhecer os UDIDs, apenas os endereços de email.

No entanto, suponho que você ache que seu aplicativo não será aprovado na revisão menos restritiva do aplicativo beta.

Nesse caso, você pode distribuir seu aplicativo em um formulário "semi-cozido". Em vez de fornecer o projeto Xcode incluindo fontes, que você afirma que não deseja, você pode distribuir seu aplicativo como binários compilados, mas ainda não assinados.

Para facilitar para seus clientes, você teria que criar ou criar uma ferramenta simples que o usuário possa executar que assine códigos de binários com o AppleID do usuário. Eles não precisariam ser registrados Apple Developers.

A ferramenta precisaria alterar o nome do pacote no Info.plist e usar a ferramenta "codesign" para assinar o aplicativo:

Para tornar o nome do pacote exclusivo, adicione quaisquer identificadores aleatórios ao nome do pacote no arquivo plist.

A ferramenta codesign pode ser usada com um comando como este:

codesign --force --sign "my identity"  <path for .app file>

onde "minha identidade" é a identidade (ID da maçã) do usuário final.

jksoegaard
fonte
Você pode mencionar que a Apple pediu recentemente aos criadores do F.lux que parassem de fazer exatamente essa prática.
GhostLyrics
2
Sim, está certo - mas a diferença que eu vejo entre isso e o F.lux é principalmente o fato de o grupo F.lux ter registrado Apple Developers. Eles estavam violando um acordo que tinham com a Apple - e para garantir que seus outros aplicativos ou programas em potencial não fossem proibidos, eles optaram por parar de recomendar o carregamento lateral do aplicativo para iOS. Além disso, o aplicativo F.lux tinha um grande número de usuários em potencial. Parece um equipamento de pesquisa especializado que pode ser usado por algumas centenas de usuários no máximo. Nesse caso, a Apple provavelmente não demonstrará interesse nele.
Jksoegaard
1
Bem, os dois primeiros parágrafos estavam lá para garantir que você soubesse das regras menos rígidas relacionadas à revisão do aplicativo beta, em comparação com o processo comum de revisão do aplicativo. Sobre a ferramenta, não vejo por que você acha que é terrivelmente complicado. É uma questão de executar as ferramentas de linha de comando existentes fornecidas pela Apple. Ou seja, colando uma GUI fácil de usar em cima das ferramentas existentes. Não vejo como isso é inútil.
Jksoegaard
Eu adicionei informações específicas sobre como executar o comando codesign, etc. Você também pode consultar a documentação da Apple: developer.apple.com/library/mac/documentation/Security/…
jksoegaard
1

Fabric.io é realmente ótimo.

Você pode enviar um convite por email e receberá o correspondente UDID por email.

E o ponto realmente bom do Fabric são os recursos Crashlytics e Analytics .

A plataforma Fabric é composta por quatro kits modulares que abordam alguns dos desafios mais comuns e difundidos que todos os desenvolvedores de aplicativos enfrentam: estabilidade, distribuição, receita e identidade. Ele combina os serviços de Crashlytics, MoPub, Answers, Twitter e outros para ajudá-lo a criar aplicativos mais estáveis, gerar receita através da maior troca de anúncios para celular do mundo e permitir que você utilize os sistemas de entrada do Twitter e os ricos fluxos de conteúdo em tempo real para maior distribuição e identidade mais simples. E o Fabric foi construído com a facilidade de uso em mente. A instalação leva apenas alguns minutos, e a maioria dos recursos requer apenas algumas linhas de código - para que você gaste menos tempo gerenciando SDKs e mais tempo criando a melhor experiência para seus usuários.

http://frabric.io

StrawHara
fonte
0

Diawi é uma ótima plataforma para o que você está procurando fazer.

Essencialmente, você faz o upload do seu aplicativo para esta plataforma e recebe um link curto que pode enviar aos testadores. Quando eles abrem o link no dispositivo iOS, eles são solicitados a instalar o aplicativo.

Conforme detalhado em seu site, o problema é que você deve adicionar o dispositivo de cada usuário ao perfil de provisionamento usado para instalar o aplicativo.

Provavelmente é o mais fácil possível para os usuários, sem distribuir via TestFlight.

aidanb.01
fonte