TestFlightApp vous en pensez quoi?
Freyskeyd
Membre
::
Salut à tous,
J'aimerai avoir votre avis sur TestFlightApp.com.
J'aimerai utiliser ce service pour un déploiement ad hoc, le service semble de qualité au vue des tests que j'ai fais, mais j'aimerai quand même avoir des retours d'expériences ou d'utilisations.
Notamment au niveau de la politique du site.
Merci à vous.
Salut à tous,
J'aimerai avoir votre avis sur TestFlightApp.com.
J'aimerai utiliser ce service pour un déploiement ad hoc, le service semble de qualité au vue des tests que j'ai fais, mais j'aimerai quand même avoir des retours d'expériences ou d'utilisations.
Notamment au niveau de la politique du site.
Merci à vous.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour les bêtas, c'est super efficace.
Les clients trouvent ça pratiques aussi.
Certes, TestFlight s'engage à ne faire que du push d'app mais on est pas à l'abris d'une erreur humaine.
Pire, TestFlight étant un service mutualisé, c'est une cible de choix si quelqu'un veut faire chier. En attaquant TestFlight, sur combien de machine prendrait-on la main ?
Bref, c'est que dalle à monter un MDM, surtout avec OS X Server, autant en profiter et faire un truc propre en interne plutôt que toujours passer par du cloud sur lequel vous n'avez pas la main...
Si tu veux en dire plus, n'hésite pas.
Pour info, OSX.7 Server inclus déjà un serveur MDM (cf le What's New, tout en bas)
Merci de vos réponses.
J'aurai aimé monter un système MDM mais je ne possède pas de serveur OSX et le client n'en financera pas... y'a t'il un moyen ou une alternative sous linux?
En gros comment fonctionne leur service?
Ils ont une licence Developer Entreprise, il ajout les devices à leur licence et partage ensuite l'ipa signé par leur mobileprovision?
Merci à vous!
Ok donc si je résume :
Licence Developer Program normal :
- Doit ajouter les devices à la mano au provisionprofile?
- Limité à 100 devices
Licence Developer Program Enterprise :
- Pas besoin de spécifier les devices? il s'ajout tout seul?
- Illimité au niveau des devices
Je pense que je vais passer par une solution interne mais j'aimerai ne pas avoir à ajouter un device via le developer.apple.com et faire un nouveau provisionprofile...
Merci à vous!
Son vrai nom est le "Enterprise Program". C'est un programme qui permet la distribution "In House", c'est à dire avec des profils qui n'ont simplement pas besoin de spécifier le UDID (tout comme les profils pour l'AppStore). C'est pas qu'ils s'ajoutent tout seuls, c'est qu'ils n'ont pas besoin de valider l'UDID.
Ce programme / cette license est légalement liée à des conditions et limitations d'usage. A la base, c'est fait pour la distribution "In House" c'est à dire "Au sein de l'entreprise", le but étant pour une entreprise qui ferait des applications iPhone utiles uniquement pour la société (par exemple une application pour que les salariés puissent faire leur imputation, ou servant d'assistant dans leur métier mais ne fonctionnant qu'avec les serveurs propriétaires de la société, etc) et pas ouverte au public (donc la mettre sur l'AppStore n'aurait pas trop de sens).
En pratique, cette license est souvent utilisée pour non pas publier des applications "In House" stricto sensu mais pour faire des livraisons OTA intermédiaires à des clients par exemple, sans avoir à leur demander leur UDID. Apple tolère cet usage, dans la mesure où cela reste dans le but de faciliter la distribution, pour les prestataires de services réalisant des applications pour des clients, de versions démo ou d'essai lors des phases de développement (c'est en fait l'usage qu'on en fait pour la plupart d'entre nous, et TestFlight ne fait rien d'autre que ça finalement), mais à condition bien sûr que cela ne serve pas à créer un "AppStore alternatif" façon boutique concurrente d'applis iOS
(logiquement comme à chaque installation d'une appli le certificat est validé, ils peuvent voir si l'usage de ces licenses dépassent un certain seuil et bloquer le mauvais usage du certificat si besoin par exemple)
Ok,
Dans mon cas le client à environ 30iPad et l'application doit être utilisable uniquement par eux.
Il est donc préférable de prendre le Standard Program dans mon cas non?
@yoann :
Quels sont les avantages réels d'un serveur OSX, comparer à un déploiement on the air?
Comme expliqué par AliGator, si ton client veut distribuer l'application juste pour ses employés, il lui faut un Programme "Entreprise Program"
Sinon ce n'est pas légal ?
Sachant que nous sommes le propriétaire du Program en tant que référent technique...
Il n'est pas légal de distribuer une application privé via Standard Program ?
Qu'est-ce que tu appelle un déploiement on the air ? On the air ne veut pas dire grand chose sinon que tu es capable de déployé sur un iPhone sans brancher un câble USB.
Le MDM d'OS X Server (comme celui de testflight) te permet d'envoyer les applications en push sur tes utilisateurs enregistré, ainsi dès qu'une MAJ est dispo où qu'un nouveau produit l'est ils reçoivent une notification pour l'installer.
En gros si tu trouve un intérêt à TestFlight, bah tu as le même avec OS X Server (ou n'importe quel MDM inhouse, OS X Server étant le moins cher) avec en plus un contrôle total et de la sécu.
Pour le programme entreprise, il est écrit qu'il faut avoir un numéro DUNS, en pratique, cela s'obtient facilement ?
Bonsoir,
avec OSX server on peu faire de la distribution d'applie sans prendre le contrôle des iPhones ? (question naà¯ve).
(j'entend par "vraie entreprise" : enregistrée au RCS et reconnue comme société, pas une personne ayant un statut d'Auto-Entrepreneur par exemple, qui n'est pas une société)
Oui et non.
La distribution d'app inhouse sur iOS se fait de deux façons :
OS X Server sait faire les deux (le premier n'étant qu'un simple site web), par contre pour faire du push de MAJ c'est impérativement avec un MDM et donc un contrôle complet des iOS depuis le serveur.
Dans le cadre du Push, l'avantage d'OS X Server c'est que vous avez la main dessus, une fois que vous l'avez mis en place il vous appartient. Cela veux dire une exposition aux attaques plus faible et une stabilité à long terme, votre OS X Server ne sera pas revendu à un tiers ou ne décidera pas de vous facturer le service X euro par mois sans votre accord.
(Et encore une fois je parle d'OS X Server car c'est la solution la moins cher en inhouse pour ça, vous avez d'autres MDM qui existe et qui tourne sur Windows et qui gèrent aussi Android, Blackberry et Windows Phone, mais c'est pas un ticket à 1000 € ou 2000 € tout compris...)
La question que nous nous posons concerne le déploiement conjoint d'applications maisons via une licence In House et des applications AppStore achetée par notre société pour diffusion sur les iPad mini.
J'ai cru comprendre que les deux fonctionnalités de mise à jour ne peuvent coexister.
Ce que j'ai compris :
1) les applis maisons pourront être mise à jour automatiquement via le MDM,
2) pour les applis AppStore, il faut passer par un mail avec un lien vers l'appli pour inviter l'utilisateur à faire la mise à jour.
Quid du compte Apple ID ?
- Apple ID par utilisateur + carte iTunes d'une valeur de 10euros pour mise à jour ?
- un seul Apple ID compte entreprise ?
C'est pas très clair en fait. Je cherche toujours la meilleur solution...
Pour ce qui vient de l'AppStore, c'est le bordel.
Déjà , il te faut passer tes commandes groupé d'application via des VPP (Volume Purchase Program) pour acquérir légalement le nombre de licence nécessaire.
Ensuite, deux options :
Lors d'un test depuis le MDM Apple, le push d'App téléchargées sur l'App Store fonctionne. Cependant, au premier lancement de l'application, il demandait à s'authentifier avec l'Apple ID ayant téléchargé l'application.
Tu as fait le test avec une application récupéré via un VPP ? Perso je n'ai jamais eu la possibilité de le tester avec un VPP, mais normalement c'est prévu pour, la signature du VPP est différente semble-t-il.
Ah non, pas testé avec du VPP. Mais si c'est bien une signature différente, c'est bon à savoir...
C'est en tout cas ce qui a été dit sur le sujet. Je ne l'ai pas vu personnellement mais c'est comme ça que ça marche normalement.
La version "de base" est hebergée par HockeyApp mais tout est open source et on peut facilement l'utiliser sur une de ses propres machines.
Par ailleurs si tu intègres le sdk hockey app ton application propose directement la mise à jour au lancement. (sans push).
J'aimerai revenir sur ce qui a été dit précédemment :
Je ne suis absolument pas d'accord avec ce propos. On parle de "MDM" alors que TestFlight (tout comme Appaloosa) est un "MAM" (Mobile Application Management). Il s'agit de 2 choses différentes mais qui peuvent être complémentaire.
MDM : utilisé pour gérer principalement des devices
MAM : utilisé pour gérer principalement des applications
Cependant, je suis d'accord que la façon dont Testflight enregistre les utilisateurs dans leur système depuis un téléphone peut s'apparenter à un "enrollement" du téléphone mais ils ne vont pas jusqu'au bout du processus comme un MDM. Ce que je veux dire, c'est qu'ils ont connaissance du téléphone et de son identifiant mais ils sont incapables de gérer le téléphone des utilisateurs (rôle justement d'un MDM) mais ils sont capable de gérer l'application et les populations à qui il faut pousser la nouvelle version d'une application (envoie d'un mail).
En conclusion, il faut bien faire attention à la distinction entre un MDM et un MAM. Le MDM permet de gérer un device à l'insu de l'utilisateur et donc comme la citation le dit : d'effacer un terminal, restreindre des choses (ex : installation d'applications, ...), pousser des configs, ajouter/supprimer des apps, ... Alors que le MAM gère des applications et seulement des applications mais l'utilisateur a encore la main sur ces dernières. (ex : le MAM peut forcer la mise à jour d'une application, c'est à dire qu'au lancement de l'application, un appel est effectué pour vérifier si une mise à jour est disponible et propose à l'utilisateur de la faire ==> ainsi l'utilisateur a encore un "certain" contrôle sur l'application : s'il dit oui, la MAJ s'installe, s'il dit non, l'application peut ne plus fonctionner).