Distribution de l'application bêta aux utilisateurs distants

Il semble qu'il n'y ait pas de solution simple pour fournir mon application iOS bêta à des personnes en dehors des contacts physiques. Les moyens que j'ai trouvés pour le faire SANS utiliser l'App Store (ce qu'Apple dit explicitement n'est pas pour les tests bêta) sont les suivants:

1. Utiliser Developer Enterprise Program; Cher et excessif

2. Utilisez TestFlight; Seulement jusqu'à 25 maigres testeurs "internes" autorisés avant que des directives extrêmes soient mises en place pour plus de gens (pourquoi ne pas simplement les mettre sur l'App Store à ce stade ...?)

3. Donnez-leur tout mon projet Xcode et demandez à l'utilisateur de le construire dans leur propre environnement Xcode; Impossible de demander aux personnes non technophiles + Je ne souhaite pas donner mon projet à des personnes extérieures à mon entreprise

4. Développement ad hoc; Faire en sorte que tout le monde me donne ses UDID ... énormes tracas pour les autres / Les gens pourraient ne pas vouloir le faire en dehors de mon entreprise

L'application que je développe va être utilisée par des membres de la communauté scientifique pour contrôler un appareil spécifique que ma société fabrique. Il est possible qu'il ne soit jamais conforme aux normes d'Apple pour les applications sur l'App Store, mais pourrait être utilisé par plus de 100 personnes dans un avenir proche. Je suppose que la vraie question que je pose est la suivante: comment puis-je obtenir mon application bêta "inférieure à la normale" à un grand groupe de personnes?

Dans le passé, vous deviez choisir entre l'application Hockey et TestFlight pour les grands groupes bêta - mais maintenant qu'Apple a acheté TestFlight et que vous devez passer en revue pour obtenir une version bêta, le cadre de test bêta de l'application Hockey est le mieux adapté à vos besoins. répertoriés.

Il permet de gérer l'inscription des utilisateurs et la gestion de la notification des builds et de leur diffusion aux utilisateurs finaux. Vous êtes toujours prêt à gérer votre pool de tests AppleID, mais maintenant que la limite de 100 appareils a été assouplie, vous pouvez effectuer des tests bêta assez larges en utilisant Hockey et les limites normales des comptes de développeur payants d'Apple.

• http://hockeyapp.net/features/

À long terme, vous voudrez mettre l'application dans l'un des magasins d'Apple, car «abuser» de la signature de distribution d'entreprise est à la fois coûteux en temps et en argent à configurer et au fil du temps, il n'est pas si difficile d'obtenir une application après examen. Oui, vous pourriez être retardé d'un mois ou deux ou plus, mais si vous persistez, c'est une application rare qui ne peut pas être déployée à moins que vous enfreigniez l'une des règles dont Apple se soucie beaucoup, comme l'inclusion de cadres qui utilisent une API privée ou qui s'exécutent code qu'ils téléchargent après que l'application a été signée et soumise pour approbation.

Votre seule autre option consiste à envoyer le code source à chaque utilisateur et à lui faire utiliser Xcode pour créer, signer automatiquement puis installer sa propre application. Cela pourrait voler pour les utilisateurs motivés d'une application spécialisée. GitHub ou d'autres outils sources vous aideraient à publier des mises à jour, mais vous soutiendriez les gens et les factureriez peut-être au lieu de l'application elle-même sous ce modèle.

Vous pouvez utiliser TestFlight pour les bêta-testeurs externes. Cela vous permettra de tester avec jusqu'à 2 500 testeurs externes. Vous n'avez pas besoin de connaître leurs UDID, seulement leurs adresses e-mail.

Cependant, je suppose que vous pensez que votre application ne pourra pas passer même l'examen de l'application bêta moins restrictif.

Dans ce cas, vous pouvez distribuer votre application sous une forme "semi-cuite". Au lieu de distribuer le projet Xcode, y compris les sources, dont vous dites que vous ne voulez pas, vous pouvez distribuer votre application sous forme de binaires compilés, mais pas encore signés.

Afin de faciliter la tâche de vos clients, vous devez créer ou créer un outil simple que l'utilisateur peut exécuter et qui code les binaires avec son AppleID. Ils n'auraient pas besoin d'être des développeurs Apple enregistrés.

L'outil devrait modifier le nom du bundle dans Info.plist et utiliser l'outil "codesign" pour signer l'application:

Pour rendre le nom de l'ensemble unique, ajoutez simplement des identificateurs aléatoires au nom de l'ensemble dans le fichier plist.

L'outil de conception de codes peut être utilisé avec une commande comme celle-ci:

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

où "mon identité" est l'identité (apple-id) de l'utilisateur final.

Fabric.io est vraiment génial.

Vous pouvez envoyer une invitation par email et vous recevrez l'UDID correspondant par email.

Et le très bon point de Fabric est les fonctionnalités Crashlytics et Analytics .

La plate-forme Fabric est composée de quatre kits modulaires qui répondent à certains des défis les plus courants et omniprésents auxquels sont confrontés tous les développeurs d'applications: stabilité, distribution, revenus et identité. Il combine les services de Crashlytics, MoPub, Answers, Twitter et autres pour vous aider à créer des applications plus stables, générer des revenus via le plus grand échange d'annonces mobiles au monde et vous permettre de profiter des systèmes de connexion de Twitter et des flux riches de contenu en temps réel pour une plus grande distribution et une identité plus simple. Et Fabric a été construit avec une facilité d'utilisation à l'esprit. L'installation ne prend que quelques minutes et la plupart des fonctionnalités ne nécessitent que quelques lignes de code - vous passez donc moins de temps à gérer les SDK et plus de temps à créer la meilleure expérience pour vos utilisateurs.

http://frabric.io

Diawi est une excellente plateforme pour ce que vous cherchez à faire.

Essentiellement, vous téléchargez votre application sur cette plate-forme et vous obtenez un lien court que vous pouvez envoyer à vos testeurs. Lorsqu'ils ouvrent le lien sur leur appareil iOS, ils sont invités à installer l'application.

Comme détaillé sur leur site Web, le problème est que vous devez ajouter l'appareil de chaque utilisateur au profil d'approvisionnement utilisé pour installer l'application.

C'est probablement aussi simple que possible pour les utilisateurs, sans distribution via TestFlight.