Comment fait-on un standalone d'un prog depuis Xcode ?
shub
Membre
Question qui a l'air toute bête: comment fait on une fois un programme écrit en Objective-C et debuggué pour en faire une application standalone, c-a-d qui n'a pas besoin de Xcode pour se lancer ?
En cherchant sur le Net , je n'ai trouvé que ce lien:
http://akustik.hfbk.net/sc/SuperColliderHelp/Other%20Topics/Creating-Standalone-Applications.html
Bon j'ai trouvé: il suffit d'aller dans l'espace Navigateur puis dans le dossier Products, sélectionner le xxxx.app et chercher "Show in finder" dans le menu File.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour trouver l'application (l'exécutable), le plus simple est de déplier le dossier Products. Ensuite ctrl-clic sur sur l'appli et Show in Finder.
Par ailleurs, pour distribuer une version finale, pense à faire menu Product > Archive, ce qui permet de conserver les symboles pour déboguer une ancienne version, au cas où.
Une autre solution est de changer dans les "Build settings" la destination du produit final pour la place qui vous intéresse.
Mais ça date tout ça, et ce n'est plus du tout d'actualité, maintenant tu Archive et ça marche partout
Uh?
Les gens, la seule réponse valide pour distribuer une application Mac est : menu Product / Archive et une fois archivé, via l'organizer, vous pouvez envoyer sur le MAS ou exporter avec un certificat Gatekeeper.
Il y a également l'option d'export de l'application sans aucun certificats pour ceux qui n'aiment pas la sécu utilisateur et qui n'aiment pas donner des sous à Apple.
Je me suis mal exprimé précédemment: pour retrouver facilement le xxx.app, on peut changer sa destination dans les Build Settings. Souvent je mets comme destination un dossier ajouté dans le dossier du projet. J'ai ainsi le projet et l'application résultante groupés dans un seul dossier. Voir les "Build Locations" dans les "Build Settings".
@yoann La question était: comment faire une standalone application et ou la retrouver! L'envoyer chez Apple c'est autre chose. Par contre l'option d'export m'intéresse, je vais aller voir ça.
(n'empêche que c'est bien gentil ces histoires de certificats, mais j'y passe déjà ma vie sous iOS, alors le certif Gatekeeper, c'est à la toute fin du dév).
Et bien j'ai essayé d'avoir une signature alors que je suis "développeur gratuit". C'est impossible. Sauf si ça a changé depuis, la signature est gratuite quand on a déjà payé. J'ai renoncé car je fais du dev pour le plaisir !
Il faut payer le compte développeur pour prouver qui tu es. Des certificats distribué à tout le monde sans aucune validation n'ont aucune valeur !
Et encore une fois, dans le process décrit, vous avez également l'option d'export en app non signé (et également export en pkg si vous en mettez de partout).
C'est le seul process viable pour avoir un .app distribuable sous Mac.
Moi aussi j'aimais bien faire ça. Idem pour les fichiers temporaires, cela permet de faire du nettoyage rapidement et d'être certain que les fichiers ont été supprimés quand on veut repartir à zéro.
Mais, j'ai abandonné depuis Xcode 5, maintenant j'utilise Archive et l'Organizer.
- Du coup ça devient difficile d'exclure ce dossier de Build de TimeMachine (ou tout autre système de backup). Car tu as évidemment un disque de backup de tes données, j'espère. Et du coup si tu n'exclus rien, ça va sauvegarder tes Build Products sur ton disque de backup, alors que ces derniers prennent de la place et par définition peuvent être rebuildés. Donc gaspillage de ton espace de backup. En général on a donc juste à exclure le fichier DerivedData de la backup et on est tranquille. En déplaçant le dossier des Build Products à côté de chaque projet, ça veut dire qu'à chaque fois que tu crées un nouveau projet Xcode il faut penser à exclure de ta backup son dossier de Build que tu auras à côté...
- Si c'est pour accéder rapidement à l'application une fois Buildée, tu as le groupe "Products" dans le Project Navigator qui est là pour ça, et qui contient une référence vers le ou les produits finaux (".app") construits par ton projet. Donc il suffit de faire un clic droit -> "Show in Finder" dessus et basta
- Si c'est pour supprimer rapidement les Build Products pour repartir de zéro avant un build, il suffit de faire un "Clean Build Folder" dans le menu Product (Commande-Maj-Alt-K de mémoire). Cet élément apparait à la place du simple "Clean" dans le menu "Product" quand on maintien la touche "Alt" enfoncée.
- Si c'est pour supprimer les DerivedData associés à ton projet car tu veux pousser le ménage encore + loin (et supprimer aussi l'indexation Xcode de ton projet etc), tu peux le faire depuis l'Organizer. Si tu as besoin de le faire vraiment souvent (bien que tu ne devrais pas avoir besoin) et que tu es flemmard, il y a même un Plugin Xcode qui te rajoute un bouton "Delete DerivedData" en haut à droite de ta fenêtre Xcode pour t'éviter d'aller dans l'Organizer.
Au final, j'ai du mal à voir l'avantage de mettre les DerivedData à côté du projet plutôt que dans le dossier commun sur une machine personnelle de tous les jours.Le seul cas où j'ai choisi cette option, c'est sur notre serveur d'intégration continue, car lui fonctionne un peu différemment : il fait un "git clone" du projet dans un dossier temporaire (/tmp/jenkins/workspace), puis il Build le projet, et met donc les Intermediate Biuld Products à côté du projet donc aussi dans /tmp. Comme régulièrement il y a un ménage de /tmp, les Build Products sont ainsi supprimés en même temps que le clone du projet est supprimé.
Mais c'est valable parce que notre CI n'a pas TimeMachine, et n'a pas pour but d'avoir d'être une machine de travail où tu codes dessus et fait des Build que tu aimerais rapides, mais de faire des Build de nombreux projets avec des cycles de vie courts et faire du ménage régulièrement.
Cette habitude du dossier build dans le dossier source date de Xcode 3 et avant. À l'époque où il n'y avait pas Time Machine d'ailleurs.
Le dossier de build était avec le projet et on faisait un svn ignore dessus. Et Time Machine n'existait pas d'ailleurs.
C'était le seul moyen d'accéder simplement au dossier Release lors des build final, surtout lorsqu'on devait en faire un pkg.
Généralement, les dossier de codes sont versionné et centralisé, donc exclus des système de sauvegarde.
Mais depuis Xcode 4 et les nouveaux process de build, c'est une mauvaise idée de faire ce genre de chose.
Quand on est confronté à plusieurs environnements de développement, on "standardise" les pratiques pour éviter les erreurs de manipulation.
Chaque projet a toutes ses dépendances, ses outils spécifiques et ses fichiers générés dans un répertoire qui peut se trouver à des endroits différents sur des machines différentes ou même dupliqués à plusieurs endroits.
C'est vrai que cela pose problème sur mac avec time machine. Mais dans un environnement pro centralisé, les sources sont généralement pushé sur un serveur, les documents aussi donc on n'a pas trop l'usage d'une sauvegarde par poste de travail.
L'uniformisation des outils de fait très bien sans avoir à déplacer les répertoires de Build. Les dépendances sont gérés par CocoaPods. Les outils spécifiques sont rares car ils deviennent vite réutilisables et utiles dans d'autres cas. Quand c'est le cas en effet on peut les embarquer avec le projet. Mais les Intermediate Build Products, qui sont volatiles par définition et sont de toute façon à ignorer dans ton SCM, je ne vois pas de raison de changer le comportement de Xcode par défaut quant à eux à par pour des environnements de Build comme une CI, au risque de les éparpiller dans ton disque sur tous les projets.
Un peu comme la toolchain, tu vas pas la dupliquer sur chaque projet et avoir tout en 15 exemplaires éparpillés de tes outils sur ton disque, d'une part car c'est dommage de prendre de la place pour rien, mais surtout parce que sinon c'est une plaie à maintenir (si tu as fait un correctif dans ta toolchain, comment l'appliquer partout alors que c'est éparpillé ?)
De notre côté chaque développeur clone notre toolchain (car elle est sous GitLab evidemment) sur sa machine et on est ainsi assuré que tout le monde utilise les mêmes outils et profite des derniers correctifs, scripts, templates de projets et de fichiers, outils de livraison OTA automatisés, etc. (Les gens la clone où ils veulent du moment qu'ils configurent leur environnement pourt indiquer où elle a été clonée)
Si un projet à besoin d'une version spécifique des outils de façon justifiée, on fait une branche ou on bascule sur un tag. Le Rakefile du projet indique de toute façon le tag de nos BuildTools à utiliser si c'est un cas particulier, donc c'est géré. Le reste (spécificités du projet, choix de la version de Xcode à utiliser, etc) c'est juste des éléments de configuration dans le Rakefile projet, et toute l'intelligence pour utiliser les bons outils et paramètres de Build est gérée en interne par les BuildTools pour etre mutualisée.
Si tu dupliques tout dans chaque projet et que tu ne mutualises pas, en terme de maintenance et de dérives c'est l'horreur. Je le sais bien, c'est comme ça que c'était avant et c'est à cause du temps perdu par ce genre de système qu'on est passé à notre solution mutualisée " sans perdre la possibilité de gérer les cas spéciaux pour autant d'ailleurs.
Et ça change la vie. Quand on a un nouvel outil à intégrer dans nos BuildTools (Dernièrement par exemple : BetaByCrashlytics, mogenerator, liftoff...) on l'intègre dans notre toolchain et tout le monde en profite instantanément et sur tous les projets, sans rien avoir à faire. Si tu dupliques ta toolchain dans chaque projet, ce genre de chose est ingérable.
Après, c'est vraiment une question d'organisation, ça dépend du contexte, il n'y a pas une solution absolument meilleure que les autres.
Il faut juste savoir ce que l'on fait et faire en sorte que cela soit reproductible d'une machine à l'autre sans perdre de temps.
Par exemple pour un projet donné on était à une époque obligé d'utiliser une ancienne version de CocoaPods car les podspecs privés que faisait notre client pour ses libs dataient de mathusalem. On a juste fait un Gemfile dans le repo du projet pour dire d'utiliser une version spécifique de CP et bundler s'est occupé du reste. Pas besoin de dupliquer nous même les outils pour ça et de risquer d'éparpiller plusieurs copies de CP.