Comment empaqueter une application Mac OS pour l'installation?
Je sais que sur Windows, il existe un tas d'outils d'installation que vous pouvez utiliser pour créer un programme d'installation, mais sur Mac OS, j'ai vu deux façons d'installer des applications:
Un fichier DMG que vous téléchargez, double-cliquez, puis exécutez une application à l'intérieur - l'application vous fait généralement glisser une icône vers une autre icône (représentant le dossier Applications) pour installer l'application
Un autre type de fichier qui lance un programme d'installation apparemment standard, qui affiche parfois un avertissement du type "Ce programme d'installation peut exécuter un programme pour déterminer si vous pouvez poursuivre l'installation"
Quelle est la manière "standard" de conditionner une application pour une installation sur Mac OS? Est-ce que l'une des méthodes ci-dessus est recommandée par Apple?
Merci.
Apple établit très clairement la "norme" pour télécharger un programme sur l'App Store. Cela a l'avantage de rendre l'installation de l'application transparente pour l'utilisateur normal. Et, croyez-le ou non, les gens normaux ont beaucoup de mal avec le concept d'installation d'un programme. Bien sûr, cet avantage entraîne certains coûts, mais ce n'est pas le lieu pour ce débat - il y a beaucoup d'autres endroits pour cela.
En supposant que vous ne vouliez pas ou ne puissiez pas suivre la voie de l'App Store, PKG et DMG sont des moyens courants de distribuer un programme. Utilisez un PKG si vous devez installer des fichiers en dehors de votre ensemble d'applications (ce qui ne devrait pas être un cas d'utilisation courant). Dans tous les autres cas, utilisez un DMG qui invite l'utilisateur à copier l'application dans le dossier Applications. Mais beaucoup de vos utilisateurs ne comprendront pas qu'ils doivent le faire (à moins que votre public cible ne soit que des utilisateurs informatiques avertis). Ils exécuteront votre application à partir de l'image disque. Idéalement dans ce cas, votre programme détectera qu'il s'exécute à partir d'une image disque et proposera de se copier dans le dossier Applications.
Les packages fonctionnent bien. Si votre processus de déploiement doit rester simple, c'est parfait.
Le Quick build consiste à faire glisser votre .app sur Package et c'est fait.
Pour un emballage avancé, vous pouvez également fournir un certificat.
Nous discutons de deux choses:
- tout d'abord et surtout, la méthode standard par laquelle les bits d'un exécutable sont déposés sur le disque de manière accessible et correctement enregistrée par le système
- deuxièmement, le mécanisme de préparation du .app, comme recommandé par Apple
Une ancienne page marketing sur site d'Apple indique qu'il est recommandé de créer des packages (afin que l'application Installer puisse déplacer les bits en place) avec l'application PackageMaker. Son utilisation est décrite ici: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
Mais comme d'autres l'ont mentionné, l'éléphant dans la pièce est le MacAppStore (MAS pour faire court). Jusqu'à ses débuts, ce qui était standard pour les grandes entreprises était leurs propres scripts personnalisés intégrés dans un package de type ancien ou utilisant un exécutable comme le programme d'installation VISE. Les petits développeurs essayaient généralement de rendre leur application installable par glisser-déposer, distribuée dans des archives Zip ou des images de disque (par souci de simplicité). Le MAS est différent: à partir de 10.7, il utilise un format de package (qui a fait ses débuts en 10.5) appelé package plat (vraiment une archive xar, explication ici ) qui est transféré via http dans un dossier caché , s'installe directement dans les applications (après quoi le dossier temporaire dans lequel il est téléchargé est supprimé). Il dépose sa réception et un fichier de facture ou de matériaux dans/private/var/db, et est donc auditable par l'outil de ligne de commande intégré pkgutil, décrit ici: mactech.com/articles/mactech/Vol.25/25.12 /2512MacEnterprise-PackagesReceiptsandSnow/index.html
Un avantage de l'utilisation du format de package plat est que vous pouvez tirer des choses sur le réseau de manière plus sûre et plus efficace, mais il n'est pas aussi facile de travailler avec des packages groupés si vous testez et modifiez le package régulièrement, ou en itérant pour garantir que les scripts effectuer des actions ou des contrôles fonctionnent bien. Même à plat, il est recommandé de placer le paquet dans une archive ou une image disque pour plus de flexibilité. Plus d'outils de distribution attendent des DMG que des Zip, il y en a donc aussi.
Outre ce que Apple recommande et ce qui est la pratique courante et courante, il y a cet article: https://www.afp548.com/2010/06/03/the-commandments-of -packaging-in-os-x / qui explique le pourquoi et le comment (bien que principalement pour les administrateurs système) de l'empaquetage pour une distribution plus large. Il est fortement recommandé d'avoir une meilleure idée de comment et pourquoi les choses tournent mal, et quoi éviter.
Essayez Iceberg ! Un autre créateur de package.
Sous OS X, de nombreuses applications sont simplement créées en tant que bundles d'applications relocalisables que l'utilisateur a juste besoin de copier dans le dossier/Application (ou tout autre emplacement). Dans d'autres cas, lorsque vous devez effectuer certaines opérations sur la machine (telles que l'ajout d'utilisateurs ou la modification des autorisations), vous pouvez utiliser un programme d'installation PKG (par exemple, construit à l'aide de PackageMaker ), qui permet d'exécuter certains pré et les scripts de post-installation et prennent en charge une configuration d'installation de base, comme la sélection du lecteur d'installation.
Parfois, comme avec un logiciel serveur complexe, vous avez besoin de plus de flexibilité, par exemple pour afficher des pages personnalisées à l'utilisateur final demandant des informations nécessaires pour installer votre application, comme le port et le mot de passe MySQL ou des informations de proxy pour télécharger les exigences à la volée (ou simplement pour faire paraître plus chic :)). Dans ce cas, il existe d'autres solutions d'installation comme notre BitRock InstallBuilder (avertissement, je suis l'un des développeurs). InstallBuilder a également l'avantage de générer des installateurs multiplateformes utilisant le même projet avec très peu de personnalisation par plate-forme.