TestFlightApp vous en pensez quoi?

::



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.
«1

Réponses

  • Je m'en sers pour mes besoins personnels et professionnels... Autant dire que c'est efficace pour balancer des bêtas je trouve.
  • muqaddarmuqaddar Administrateur
    Idem.

    Pour les bêtas, c'est super efficace.

    Les clients trouvent ça pratiques aussi.
  • Perso je suis pas fan du truc, question de sécurité. La techno utilisé par TestFlight (MDM) est faite à  la base pour qu'une entreprise gère son parc de terminaux mobile, cela entend qu'elle peut avec ça effacer les terminaux, les restreindre, pousser de la config ou des apps.



    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...
  • muqaddarmuqaddar Administrateur
    janvier 2013 modifié #5
    Que veut dire MDM que je me couche moins bête ?

    Si tu veux en dire plus, n'hésite pas.
  • AliGatorAliGator Membre, Modérateur
    janvier 2013 modifié #6
    MDM : Mobile Device Managment



    Pour info, OSX.7 Server inclus déjà  un serveur MDM (cf le What's New, tout en bas)
    OS X now supports configuration profiles similar to those on iOS-based devices. As part of this functionality, OS X Server provides a full mobile-device-management (MDM) server. This configuration service provides you with the ability to administer both OS X clients and iOS clients.



    To enable the MDM server, launch Server Center and enable the Device Config service. Then manage devices using the device-configuration web interface. There is no need to use the iPhone Configuration Utility when working with this service.
  • muqaddarmuqaddar Administrateur
    Merci Ali.
  • Alors pour mémoire 10.7 est la beta de 10.8, des propos mêmes des ingé Apple, si vous n'êtes pas satisfait du MDM 10.7, passez à  10.8, maintenant ça marche ^^
  • Et sinon pour faire du MDM proprement avec OS X Server c'est pas très complexe, il faut mettre en place ce que l'on appelle un split DNS (go google) et choisir l'option "Internet" lors de l'installation de votre serveur Mountain Lion.
  • ::



    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!
  • AliGatorAliGator Membre, Modérateur
    Je suppose qu'ils ont une licence Developer Enterprise, ce qui fait qu'ils n'ont pas à  ajouter les UDID des devices (c'est comme ça qu'on fait en interne avec notre système maison -- sans MDM d'ailleurs, juste avec un Jenkins-CI qui compile et signe nos projets pour les livraisons OTA)
  • ::



    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!
  • AliGatorAliGator Membre, Modérateur
    'Freyskeyd' a écrit:


    Licence Developer Program normal :

    - Doit ajouter les devices à  la mano au provisionprofile?

    - Limité à  100 devices
    Son vrai nom est le "Standard Program" ("Standard Individual" pour les indépendants, genre une personne physique, et "Standard Company" pour les sociétés) mais oui, c'est ça


    'Freyskeyd' a écrit:
    Licence Developer Program Enterprise :

    - Pas besoin de spécifier les devices? il s'ajout tout seul?

    - Illimité au niveau des devices
    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)
  • Juste pour mémoire, un MacMini Server ça coute 1029 € TTC... Et une fois en place ça vous sert à  faire serveur de distri, de build, de git etc...
  • ::

    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?

  • Hello,



    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 ?
  • 'Freyskeyd' a écrit:


    @yoann :

    Quels sont les avantages réels d'un serveur OSX, comparer à  un déploiement on the air?




    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.
  • 'AliGator' a écrit:


    Son vrai nom est le "Standard Program" ("Standard Individual" pour les indépendants, genre une personne physique, et "Standard Company" pour les sociétés) mais oui, c'est ça



    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)




    Pour le programme entreprise, il est écrit qu'il faut avoir un numéro DUNS, en pratique, cela s'obtient facilement ?
  • 'yoann' a écrit:


    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.




    Bonsoir,

    avec OSX server on peu faire de la distribution d'applie sans prendre le contrôle des iPhones ? (question naà¯ve).
  • AliGatorAliGator Membre, Modérateur
    'denis_13' a écrit:


    Pour le programme entreprise, il est écrit qu'il faut avoir un numéro DUNS, en pratique, cela s'obtient facilement ?
    Il faut que tu soies une vraie entreprise, enregistrée au RCS, à  partir de ce moment là  tu auras un DUNS, un KBis, etc. Bref tout ce qu'il faut fournir à  Apple ça fait partie des papiers classiques qu'on a qd on monte et déclare une vraie entreprise



    (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é)
  • 'denis_13' a écrit:


    Bonsoir,

    avec OSX server on peu faire de la distribution d'applie sans prendre le contrôle des iPhones ? (question naà¯ve).




    Oui et non.



    La distribution d'app inhouse sur iOS se fait de deux façons :
    • mise à  disposition sur un serveur web, l'utilisateur viens chercher son app et sa MAJ de lui même ;
    • envois en push via un MDM lorsque l'iPhone est géré par l'entreprise ;


    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...)
  • Je pense déployer pour mon entreprise un MDM sur OX Server pour 200 à  250 iPad mini.



    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 In House le MDM c'est parfait.



    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 :
    • tu offre les voucher aux employées et ils s'en servent sur leurs AppleID perso, à  3€ l'application ça passe en consommable sur la compta, une boite de trombone c'est plus cher...
    • tu télécharge une fois l'ipa avec un code et tu le pousse avec le MDM, par contre la mise à  jour ne pourra se faire du coté client (les AppleID ne possédant pas cette application), il te faudra donc repousser les MAJ à  chaque fois via le MDM.
  • 'yoann' a écrit:
    • tu télécharge une fois l'ipa avec un code et tu le pousse avec le MDM, par contre la mise à  jour ne pourra se faire du coté client (les AppleID ne possédant pas cette application), il te faudra donc repousser les MAJ à  chaque fois via le MDM.





    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.
  • 'Thibaut' a écrit:


    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.
  • merci Ali et Yoann, pour les informations :-)
  • ThibautThibaut Membre
    janvier 2013 modifié #28
    'yoann' a écrit:


    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...
  • 'Thibaut' a écrit:


    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.
  • MarcioMarcio Membre
    février 2013 modifié #30
    Personnellement je passe par http://hockeyapp.net. C'est payant si on les utilise pour héberger mais ça me remonte aussi des crashs et d'autres stats intéressantes sur les tests, notamment le temps passé sur chaque device à  tester.



    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).
  • Moi j'utilise http://www.appaloosa-store.com/. Cela me permet également de gérer d'autres plateformes qu'iOS.



    J'aimerai revenir sur ce qui a été dit précédemment :


    [font=helvetica, arial, sans-serif]La techno utilisé par TestFlight (MDM) est faite à  la base pour qu'une entreprise gère son parc de terminaux mobile, cela entend qu'elle peut avec ça effacer les terminaux, les restreindre, pousser de la config ou des apps.[/font]




    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).
Connectez-vous ou Inscrivez-vous pour répondre.