L'expiration des profils d'approvisionnement est un problème avec les applications distribuées en entreprise. Et c'est quelque chose qui nécessitera une maintenance continue de votre équipe de développement interne, des équipes de support mobile. D'abord, je tiens à souligner que vous ne mentionnez pas les certificats. Parce qu'ils n'expirent que tous les trois ans (à l'heure où ils sont écrits - ils expiraient à l'origine chaque année), les développeurs oublient souvent d'eux. Cependant, leur expiration est en réalité plus gênante que les profils. Lorsqu'un profil expire, vous devez simplement obtenir un autre profil valide sur l'appareil. Cela peut être fait de plusieurs façons. Vous pouvez utiliser une solution de gestion des appareils mobiles (MDM) pour simplement ajouter un nouveau profil. Ou si une autre application avec un profil valide (qui utilise un ID générique) a été transmise à l'appareil plus récemment, cela peut également obtenir un profil valide sur l'appareil.
Si le certificat expire, vous devrez réellement reconstruire l'application avec le nouveau certificat. Les anciennes versions signées avec le certificat expiré ne seront pas exécutées à moins. Techniquement, vous pouvez démissionner de l'ancien IPA, mais la chose principale à noter est que le binaire actuel est invalide et ne fonctionnera pas tant qu'un nouveau binaire avec une signature de code correcte n'est pas généré. Heureusement, ce n'est que tous les 3 ans, donc c'est moins fréquent, mais je peux presque vous promettre que quand cela arrivera, vous aurez un désordre sur vos mains si vous ne le planifiez pas. Encore une fois, comme avec le profil de provisionnement, vous pouvez gérer cela en utilisant MDM pour pousser quelque chose de nouveau à l'appareil. Dans ce cas, vous utiliseriez MDM pour remplacer l'application while, pas seulement le profil. Un peu plus de travail, mais cela pourrait être fait.
Bien sûr, il y a des raisons pour lesquelles vous ne souhaitez pas utiliser MDM. Le coût pourrait être une préoccupation. Les employés ne souhaitent peut-être pas que l'entreprise gère leurs appareils personnels (si ces applications sont destinées à des appareils personnels). Capacité de gérer l'infrastructure/la charge de travail MDM. Si MDM n'est pas une excellente solution pour votre organisation, je recommanderais une autre approche qui n'est pas idéale d'une expérience utilisateur, mais qui pourrait résoudre votre problème. Vous pourriez construire vos applications pour être auto-mise à jour. En d'autres termes, au lancement, votre application vérifie un serveur pour voir si une nouvelle version est disponible. Si c'est le cas, il invite l'utilisateur à mettre à jour.Cela ne nécessiterait pas la gestion de l'appareil, et vous pourriez facilement créer un cadre partagé pour le rendre plus facile pour les développeurs d'applications. Un inconvénient de cette approche est que si l'utilisateur ne lance pas l'application entre le moment où vous postez la nouvelle version (avec nouveau profil/cert) et le moment où le profil ou le certificat expire, l'application ne démarre pas, donc la mise à jour automatique la fonctionnalité ne peut pas s'exécuter pour indiquer à l'utilisateur d'obtenir une nouvelle version. Il semblera juste à l'utilisateur comme si l'application plante. C'est le problème UX avec cette approche. Mais si vous pouvez gérer cela, il peut fournir une alternative à la route MDM.