Compiler et distribuer des apps Mac et iOS sans ouvrir Xcode

 (scottwillsey.com)
2 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Une fois la configuration initiale du compte Apple et des certificats terminée, il est possible d’automatiser la compilation, la signature et la distribution d’apps Mac et iOS uniquement avec les outils CLI internes à Xcode.app
  • Dans project.yml, XcodeGen régénère le .xcodeproj, puis xcodebuild, notarytool, stapler et devicectl prennent en charge tout le flux, de la création du projet à la notarisation Mac et à l’installation sur iPhone
  • Pour la distribution Mac, un seul scripts/release.sh exécute dans l’ordre l’archivage, la signature Developer ID, la notarisation, l’agrafage du ticket, la vérification Gatekeeper et l’installation dans /Applications, en s’arrêtant immédiatement en cas d’échec
  • Pour une compilation et des tests rapides, on peut utiliser CODE_SIGNING_ALLOWED=NO, mais ce build à signature temporaire ne passe pas Gatekeeper, et les droits iCloud KVS et App Group ne sont pas associés au véritable ID d’équipe
  • Si la clé privée de signature et le mot de passe de notarisation sont conservés dans le trousseau de session, et que les commandes et règles de distribution sont documentées dans CLAUDE.md ou AGENTS.md, un agent comme Claude Code peut réexécuter tout le workflow

Ce que l’on peut faire sans l’interface graphique de Xcode

  • Xcode lui-même doit être installé, mais il n’est pas nécessaire de le lancer ; xcodebuild, notarytool, stapler et devicectl sont tous des outils shell internes à Xcode.app qui s’exécutent indépendamment
  • Les réglages initiaux comme la connexion à l’Apple ID, la création d’un certificat Developer ID ou l’enregistrement d’un mot de passe de notarisation nécessitent l’interface graphique ou un terminal interactif
  • Une fois la configuration initiale terminée, il est possible de créer le projet, compiler, archiver, exporter une app signée, notariser, vérifier, installer et déployer sur un vrai iPhone sans utiliser la souris
  • Si vous bloquez sur la configuration ou l’écriture des scripts, vous pouvez fournir les exigences et les valeurs propres au projet à Claude Code ou à un autre outil de codage basé sur un LLM pour créer le workflow

Sélectionner toute la chaîne d’outils Xcode

  • Il faut d’abord vérifier que le résultat de xcode-select -p est /Applications/Xcode.app/Contents/Developer
  • Si les Command Line Tools autonomes sont sélectionnés, indiquez la chaîne d’outils Xcode complète avec la commande suivante
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  • Le répertoire /Library/Developer/CommandLineTools installé par xcode-select --install contient clang et git, mais pas les outils complets de développement d’apps comme le SDK iOS, notarytool ou devicectl
  • Si Xcode est déjà installé, le paquet Command Line Tools séparé n’est pas nécessaire
  • L’acceptation de la licence et l’installation des composants supplémentaires peuvent aussi se faire en CLI
sudo xcodebuild -license accept
sudo xcodebuild -runFirstLaunch

Reproduire le projet avec XcodeGen

  • XcodeGen gère la configuration du projet Xcode en YAML et régénère le .xcodeproj à chaque compilation
  • Il peut être téléchargé depuis GitHub ou installé avec Homebrew
brew install xcodegen
  • Un .xcodeproj est un dossier qui apparaît comme un fichier sous macOS, et comme Xcode modifie sans cesse ses fichiers internes et ses références, il peut provoquer des conflits ou des changements inutiles dans le dépôt Git
  • En ne commitant que project.yml dans Git et en ignorant le .xcodeproj généré, on garde la configuration du projet reproductible
xcodegen generate

Configurer le compte développeur Apple et les certificats

  • Il faut ajouter un Apple ID dans Settings → Accounts de Xcode
  • La distribution et la notarisation d’apps nécessitent un compte Apple Developer payant
  • Créez un certificat de distribution dans Settings → Accounts → Apple ID → Manage Certificates… → + → Developer ID Application
  • Apple Development et Developer ID Application ont des usages différents
    • Apple Development sert à exécuter l’app sur ses propres appareils ou à la transférer sur un iPhone pour le débogage local
    • Developer ID Application est nécessaire pour distribuer une .app notarisée qui passe Gatekeeper sur le Mac d’autres personnes
  • Lors de la création d’un certificat Developer ID Application, le certificat et la clé privée correspondante sont installés dans le trousseau de session
  • La signature réelle utilise la clé privée, qui ne peut pas être retéléchargée ; il ne faut donc pas la supprimer et il faut sauvegarder le trousseau

Enregistrer les identifiants de notarisation dans le trousseau

  • La notarisation d’une app Mac consiste à envoyer l’app signée à Apple pour une analyse anti-malware
  • notarytool s’authentifie avec un profil enregistré dans le trousseau, et lors de la première création du profil, il faut saisir de manière interactive un mot de passe spécifique à l’app
xcrun notarytool store-credentials App-Name \
  --apple-id "you@example.com" \
  --team-id YOUR-TEAM-ID
  • Le profil de notarisation ne doit pas être emprunté à une autre app : il faut le créer avec le nom de l’app pour éviter des échecs silencieux dans d’autres environnements
  • Le mot de passe spécifique à l’app est différent du mot de passe de l’Apple ID et se crée sur le site Apple ID, dans Sign-In & Security → App-Specific Passwords
  • Si vous changez le mot de passe de l’Apple ID, les mots de passe spécifiques aux apps peuvent expirer sans avertissement séparé
    • Si une erreur 401 invalid credentials survient pendant la notarisation, vérifiez d’abord l’expiration du mot de passe spécifique à l’app avant de suspecter toute la configuration
  • Vérifiez que le profil est bien enregistré avec la commande suivante
xcrun notarytool history --keychain-profile App-Name
  • Si vous stockez le mot de passe spécifique à l’app dans un coffre 1Password accessible à Claude Code, vous pouvez aussi confier à l’agent la création du profil de notarisation d’une nouvelle app
  • Il est possible d’automatiser jusqu’à la saisie du mot de passe avec --password, mais comme le mot de passe peut rester dans l’historique du shell, il vaut mieux le saisir une fois manuellement puis le conserver dans le trousseau ou 1Password

Séparer la configuration locale de signature et les secrets

  • L’ID d’équipe et le préfixe de bundle nécessaires à la vraie signature sont stockés dans Local.xcconfig
cp Local.xcconfig.example Local.xcconfig

BUNDLE_PREFIX     = your.real.prefix
DEVELOPMENT_TEAM  = YOUR-TEAM-ID
  • Ajoutez Local.xcconfig à .gitignore pour éviter que les réglages locaux propres au projet n’entrent dans le dépôt
  • La clé privée de signature reste dans le trousseau de session, et le mot de passe spécifique à l’app pour la notarisation reste dans le profil de trousseau de notarytool, donc aucun secret n’est écrit dans Git

Automatiser la distribution Mac avec release.sh

  • Le fichier scripts/release.sh du dépôt exécute toute la pipeline de distribution de l’app Mac en une seule commande
./scripts/release.sh

  • Le script fonctionne dans l’ordre suivant

    1. Vérification préalable de l’existence de xcodegen et du profil de notarisation
    2. Régénération du projet avec xcodegen generate
    3. Création d’une archive Release avec xcodebuild archive
    4. Export de l’app signée Developer ID avec ExportOptions.plist et xcodebuild -exportArchive
    5. Compression de l’app en ZIP et soumission à Apple avec notarytool submit --wait
    6. Agrafage du ticket de notarisation avec stapler staple
    7. Vérification de l’autorisation Gatekeeper avec spctl
    8. Arrêt du processus existant et copie de l’app dans /Applications
    9. Enregistrement de l’app installée avec lsregister
    10. Nouvelle vérification du ticket et de l’état Gatekeeper du bundle installé

  • Même si le modèle connaît la procédure de distribution générale, les informations propres au projet, comme le nom du schéma, l’ID d’équipe, le nom du profil de notarisation et l’emplacement d’installation, doivent être fournies par l’utilisateur

  • Si le premier script échoue, il faut un processus itératif de correction à partir des résultats d’exécution, mais une fois le workflow stabilisé, il suffit d’exécuter la commande de distribution sans modification supplémentaire

  • Éviter les échecs et les distributions incomplètes

    • set -euo pipefail arrête immédiatement le script dès qu’une commande échoue, afin de ne pas traiter un état incomplet comme un succès
    • cd "$(dirname "$0")/.." déplace l’exécution à la racine du dépôt, quel que soit le répertoire depuis lequel le script est appelé
    • Le bloc de vérifications préalables contrôle xcodegen et le profil de notarisation avant l’archivage, qui prend du temps
    • Le script vérifie non seulement l’app exportée, mais aussi celle copiée dans /Applications, afin de détecter une corruption du bundle pendant la copie
    • Si un autre profil de notarisation est nécessaire, on peut le remplacer via une variable d’environnement
    TZED_NOTARY_PROFILE=<name> ./scripts/release.sh

Transmettre les règles de distribution à l’agent

  • Si release.sh effectue la distribution en une seule commande, CLAUDE.md ou AGENTS.md permet à l’agent d’utiliser cette commande à chaque session sans instruction supplémentaire
  • Le document doit consigner la régénération du projet, les tests unitaires, le build macOS rapide et la vraie commande de distribution
xcodegen generate
swift test

xcodebuild -project YOUR-APP-NAME.xcodeproj \
  -scheme YOUR-APP-NAME-macOS \
  -destination 'platform=macOS' \
  CODE_SIGNING_ALLOWED=NO build

./scripts/release.sh
  • Il faut aussi documenter la différence entre les deux chemins de build
    • Le build avec CODE_SIGNING_ALLOWED=NO convient à la CI et aux vérifications locales rapides
    • Pour distribuer réellement l’app de barre de menus, passer les attributs de quarantaine et synchroniser iCloud, il faut release.sh, qui effectue la signature Developer ID et la notarisation
  • Si vous indiquez que la méthode créée pour une app doit servir de référence dans un autre dépôt, Claude Code peut répliquer la même configuration pour les apps suivantes

Build rapide non signé et tests

  • Les tests unitaires basés sur Swift Package Manager s’exécutent sans build Xcode
swift test
  • La vérification de compilation rapide de l’app macOS se fait avec la signature désactivée
xcodebuild -project TZed.xcodeproj \
  -scheme TZed-macOS \
  -destination 'platform=macOS' \
  CODE_SIGNING_ALLOWED=NO build
  • Les builds simulateur de l’app iOS et de l’extension widget peuvent aussi être lancés de la même manière
xcodebuild -project TZed.xcodeproj \
  -scheme TZed-iOS \
  -destination 'generic/platform=iOS Simulator' \
  CODE_SIGNING_ALLOWED=NO build
  • Un build à signature temporaire créé avec CODE_SIGNING_ALLOWED=NO peut servir à la compilation et à l’exécution dans le simulateur
  • Ce build est rejeté par Gatekeeper et, faute de préfixe d’équipe, les droits comme iCloud KVS et App Group ne sont pas associés ; il ne peut donc pas servir à la distribution

Déployer sans interface sur un vrai iPhone

  • Le déploiement sur appareil iOS n’a pas d’étape de notarisation comme une app Mac ; il utilise xcodebuild et devicectl
  • L’app destinée à un vrai appareil est compilée et signée avec un certificat Apple Development et un profil de provisionnement de développement
xcodebuild -project TZed.xcodeproj \
  -scheme TZed-iOS \
  -destination 'generic/platform=iOS' \
  -allowProvisioningUpdates \
  -derivedDataPath build/ios \
  archive -archivePath build/TZed-iOS.xcarchive
  • La .app générée s’installe en indiquant l’UDID de l’appareil connecté
xcrun devicectl device install app \
  --device <DEVICE-UDID> build/ios/…/TZed.app
  • devicectl list devices affiche les appareils connectés et jumelés, ainsi que leurs UDID
  • L’option -allowProvisioningUpdates récupère les profils de provisionnement de développement nécessaires

Fonctionnement de la signature de code sans interface graphique

  • Lors de la création d’un certificat Developer ID Application, Apple émet le certificat et le Mac génère la clé privée correspondante, puis les deux sont stockés dans le trousseau de session

  • codesign, appelé par xcodebuild, signe les binaires avec la clé privée et inclut dans l’app les certificats menant au certificat racine Apple afin de permettre la vérification du signataire

  • Avec signingStyle: automatic, xcodebuild choisit un certificat correspondant à l’ID d’équipe et récupère chez Apple les profils de provisionnement nécessaires

  • Il n’est donc pas nécessaire de commiter des profils de provisionnement dans le dépôt

  • Droits, notarisation et agrafage

    • Le fichier .entitlements de chaque cible contient des droits comme la sandbox, le client réseau, iCloud KVS ou App Group
    • Les droits sont associés lors de la signature avec le véritable ID d’équipe ; iCloud et App Group ne fonctionnent donc pas correctement dans les builds à signature temporaire
    • La signature et la notarisation sont deux étapes différentes
    • La signature prouve qui a créé l’app
    • La notarisation est la procédure par laquelle Apple analyse l’app signée à la recherche de code malveillant, puis émet un ticket
    • L’agrafage attache ce ticket à l’app pour que Gatekeeper lui fasse confiance même hors ligne
    • Pour une app LSUIElement, c’est-à-dire une app de barre de menus avec interface cachée, la notarisation est nécessaire afin d’éviter les détections de XProtect

  • Commandes de vérification manuelle

    codesign -dv --verbose=4 /Applications/TZed.app
spctl -a -vvv -t exec /Applications/TZed.app
stapler validate /Applications/TZed.app
    • codesign vérifie le signataire et les certificats
    • spctl vérifie si Gatekeeper autorisera l’exécution
    • stapler validate vérifie que le ticket de notarisation est attaché

Outils standard exécutés par l’agent

  • Aucun serveur MCP de build séparé ni plugin dédié n’est nécessaire ; Claude Code exécute les CLI standard dans un shell non interactif
  • Les outils utilisés sont xcodebuild, xcrun notarytool, xcrun stapler, spctl, codesign, devicectl, xcodegen et swift
  • CLAUDE.md transmet à l’agent les règles de nommage du profil de notarisation, la différence entre build rapide et distribution réelle, ainsi que l’obligation d’utiliser release.sh pour distribuer
  • Seul le premier notarytool store-credentials reste une étape interactive ; tout le reste peut être automatisé

Remplacer les actions de l’interface Xcode par la CLI

  • La création du .xcodeproj gérée par Xcode est remplacée par project.yml et xcodegen generate
  • ⌘B ou le bouton Run correspond à xcodebuild … build
  • Product → Archive est traité avec xcodebuild … archive
  • La distribution de l’app dans Organizer peut être remplacée par xcodebuild -exportArchive
  • L’envoi depuis Organizer se fait avec xcrun notarytool submit --wait
  • Pour l’attachement automatique du ticket, utilisez xcrun stapler staple
  • L’installation par glisser-déposer dans /Applications est gérée avec cp -R et lsregister
  • L’action Run sur un vrai iPhone est remplacée par xcodebuild archive et devicectl device install
  • Une fois Xcode et XcodeGen installés, les premiers identifiants configurés, et release.sh ainsi que CLAUDE.md rédigés, les déploiements de nouveaux builds peuvent ensuite s’exécuter avec une phrase ou une commande

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Réactions sur Hacker News

  • Comme il y a beaucoup de choses qu’on ne peut pas résoudre dans un sandbox, j’exécute les agents IA directement sur mon Mac, mais l’incident où xAI a téléversé le répertoire personnel, y compris les clés SSH, me pousse à sérieusement reconsidérer ce choix
    Je ne m’inquiète pas particulièrement du fait que la machine elle-même soit cassée. Dans la plupart des cas, tout est sauvegardé ou commité dans Git, donc je peux restaurer en quelques heures. En revanche, je ne veux absolument pas que le répertoire .ssh soit envoyé à un agent IA, et il ne faut pas essayer de l’empêcher par prompt : il faut le bloquer au niveau du système. J’envisage de créer un utilisateur séparé et d’appliquer des permissions 700 au répertoire personnel. On a l’impression que la sécurité est revenue aux années 1990, mais en contrepartie on peut finir le travail à une vitesse sans précédent. Je n’essaie pas de blâmer les autres : moi aussi j’utilise cette méthode risquée

    • Il n’est pas indispensable de l’exécuter sur le Mac hôte. Les Mac récents prennent en charge la virtualisation avec une perte de performances quasi nulle, donc on peut facilement utiliser des machines virtuelles macOS ou Linux de la même architecture pour le développement
      Comme solution packagée, on peut utiliser les projets open source Tart https://tart.run/ ou VirtualBuddy https://github.com/insidegui/VirtualBuddy, ou même coder soi-même un outil qui encapsule l’API de l’OS https://developer.apple.com/documentation/virtualization. Récemment, il y a aussi eu Apple container https://github.com/apple/container
    • Je suis en train de créer un outil wrapper qui exécute Claude avec un utilisateur séparé appelé agent. Il y a un an, j’avais échoué à cause d’OAuth et du trousseau, mais récemment j’ai réussi grâce à l’indication de Claude qu’on pouvait utiliser CLAUDE_CODE_OAUTH_TOKEN
      Il faut un outil auxiliaire pour configurer les permissions via ACL, mais cela fonctionne actuellement sur macOS. Le niveau de risque se situe quelque part entre le sandbox par défaut de Claude et une isolation complète par conteneur ou machine. À mesure que le sandbox natif de Claude s’améliorait, je doutais du rapport coût/bénéfice de ce projet de défense en profondeur, mais vu le risque de fuite du répertoire personnel, il y a largement de quoi continuer. Je ne l’ai pas encore publié en open source, mais je suis prêt à en discuter avec les personnes intéressées
    • Je fais tourner l’IA dans un conteneur Docker headless et je ne lui donne accès qu’à Git, afin qu’elle ne contribue qu’au code. Si des secrets sont nécessaires, je fournis un conteneur Docker stocké dans le dépôt, et s’il faut de l’infrastructure, le workflow consiste à lui faire créer un ticket Jira
    • Je me demande comment est gérée l’inscription d’un identifiant de bundle sans ouvrir Xcode

  • Pour le plaisir, je build et teste des apps iOS uniquement sous Linux, et c’est étonnamment simple ; https://github.com/xtool-org/xtool fonctionne très bien
    Sans avoir besoin de passer par TestFlight ou l’App Store, on peut aussi les installer directement sur un iPhone via USB depuis Linux. Si vous n’êtes pas sûr, vous pouvez demander à votre agent de code de créer et déployer une app iOS Hello World pour démarrer facilement

    • Je fais la même chose, sauf que j’exécute Linux dans le WSL de Windows. Je transfère l’IPA vers le téléphone avec Sideloadly, et ça marche bien
    • Après avoir transféré l’app via USB, faut-il laisser l’iPhone connecté en permanence ?
    • Les agents de code connaissent-ils déjà xtool ?

  • Mon projet open source Axiom aide les outils d’exécution de code à effectuer efficacement des tâches de développement pour les systèmes d’exploitation Apple
    Il inclut non seulement diverses technologies et divers agents, mais aussi des outils pour LLM comme xclog, xcprof, xcsym et xcui. Ils exposent les fonctionnalités nécessaires de manière efficace en tokens et peuvent aussi être utiles à des technologies ou agents extérieurs à Axiom. Axiom : https://charleswiltgen.github.io/Axiom/, outils CLI : https://charleswiltgen.github.io/Axiom/tools/

    • Est-ce que cela fonctionne correctement aussi avec une codebase Kotlin Multiplatform ? Il y a bien du code natif Swift, mais je me demande ce que ça donne en performances ou en comportement quand une partie de la logique est partagée
    • Je pense que la prochaine frontière pour les outils iOS, c’est un serveur de build Linux auto-hébergeable ; je serais curieux d’avoir ton avis là-dessus
    • Est-ce que cela fonctionne aussi avec Flutter ?

  • La phrase « J’ai fait écrire à Claude Code un script qui archive sans ouvrir Xcode, effectue la signature Developer ID, la notarisation, le stapling, l’installation dans /Applications, et s’arrête clairement à n’importe quelle étape en cas d’échec » produit un effet étrange. On a l’impression que le texte qu’on lit en ce moment même est aussi en train d’être raconté par Claude
    Il est aussi curieux de voir, à presque chaque étape du texte, revenir des indications du genre « montrez cet article à Claude Code ou à l’outil de code LLM de votre choix et laissez-le se débrouiller », « si vous ne savez pas, demandez à un LLM de vous aider à configurer », « le but d’utiliser un LLM est d’éviter le travail manuel non souhaité », « demandez-lui de créer un workflow » : on a l’impression qu’on nous dit sans cesse de redemander au LLM

    • Cet article n’a pas été écrit par Claude : c’est moi qui l’ai écrit
    • On dirait une structure circulaire où l’on montre à Claude un site web écrit par Claude, puis on lui fait créer l’environnement de build avec Claude
    • Je pensais que ce n’était pas écrit par une IA à cause des erreurs dans l’article, mais maintenant je me dis que l’IA les fait peut-être exprès

  • Après plus d’un an à développer des apps Mac et iOS avec des agents, je trouve que cet article donne de mauvais conseils. En particulier, l’excellent Xcode MCP exige que Xcode soit lancé
    Avec les outils MCP, on peut accéder à de nombreuses fonctions bien plus vite et de manière plus concise qu’avec xcodebuild, et il est aussi possible de générer et de rendre des #Preview, ce qui devient impossible si Xcode est fermé. Le MCP de Xcode 27 et l’agent intégré contrôlent aussi très bien les simulateurs via DeviceHub. DeviceHub remplace Simulator.app et semble permettre à l’agent de comprendre et manipuler l’API d’accessibilité sans recourir à des bricolages comme axe
    Xcode MCP n’est pas parfait. Le problème des fenêtres d’autorisation qui s’affichent à chaque lancement d’un agent, je l’ai contourné en automatisant l’approbation avec Keyboard Maestro. Malgré cela, Xcode 27 a nettement amélioré l’utilisabilité du vibe coding dans Xcode. Désormais, au lieu de gérer MCP séparément, je lance Codex directement depuis l’interface agent de Xcode, et cet environnement d’exécution guide mieux le modèle pour qu’il exploite les outils disponibles. Au final, on obtient surtout un feedback plus rapide et une validation plus robuste

    • Il existe Xcode-mcp-proxy, qui sert de proxy pour Xcode MCP, clique sur les boîtes de dialogue et rétablit aussi les connexions. Je me demande si vous utilisez Peekaboo pour les tests d’apps macOS, ou bien une automatisation classique par captures d’écran
    • Le Xcode MCP de Sentry vaut aussi le coup d’être essayé. Il est bien plus complet et ne nécessite pas non plus de laisser Xcode ouvert

  • Si vous voulez éviter au maximum de toucher aux IDE iOS et Android, React Native et Expo sont aussi un bon choix
    Xcode et Android Studio ne servent qu’à installer les simulateurs d’appareil, et pour le reste jusqu’au déploiement sur les stores, c’est la toolchain Expo qui s’en charge. Même sous Windows, où il est impossible d’installer Xcode, on peut exécuter directement une app iOS sur un iPhone avec les apps gérées d’Expo. Comme point de départ basé sur RN et Expo, Ignite est excellent et bien maintenu : https://github.com/infinitered/ignite

  • À strictement parler, on utilise toujours Xcode. Xcode est globalement une GUI très buggée qui encapsule plusieurs utilitaires et apps UNIX de bas niveau plutôt stables
    La publication d’apps en CLI est une pratique ancienne, et c’était déjà possible au moins depuis 2012, quand j’ai publié ma première app Xcode

    • Je le sais. Mais l’important, c’est que ce n’est pas moi qui utilise Xcode, c’est Claude
    • À cause de la barrière d’entrée après avoir ouvert Xcode, je n’avais même jamais envisagé de créer des programmes pour macOS

  • Au moins pour une partie du débogage, tout le monde doit finir par utiliser Xcode
    Pour la compilation, les agents peuvent déjà faire la plupart des choses en ligne de commande, et avec des instructions explicites selon le contexte, ils peuvent compiler plus vite. Si vous utilisez les groupes de synchronisation du système de fichiers de Xcode, XcodeGen peut aussi n’être qu’un travail supplémentaire inutile
    Sur iOS, ce que je recommanderais surtout, c’est d’ajouter à l’agent des fonctions App Store Connect : https://github.com/rorkai/App-Store-Connect-CLI. Non seulement cela évite de devoir laisser Xcode ouvert en permanence, mais aussi d’avoir à rester près de son MacBook. On peut modifier depuis l’iPhone avec Codex, demander à asc de lancer un build et l’envoi sur TestFlight, télécharger et exécuter la nouvelle version, puis recommencer

    • J’ai pratiquement terminé une app iOS complète avec un agent, et l’agent s’est même occupé de la publication sur l’App Store et de la promotion sur les réseaux sociaux. Je n’ai utilisé Xcode que pour prévisualiser le build sur l’appareil et orienter le prompt suivant

  • Le fait que les développeurs qui n’ont pas le budget pour acheter un Mac soient pratiquement exclus du développement iOS me dérange toujours. À chaque hausse des prix des produits Apple, il y a davantage de personnes qui ne peuvent plus participer au développement

    • C’est regrettable que certains n’aient pas accès à la technologie, mais aujourd’hui Apple propose aussi des appareils abordables comparés à des produits concurrents de spécifications similaires, voire inférieures. Le MacBook Air Apple Silicon avec une quantité de mémoire correcte en est un exemple

  • Si l’on fait du vibe coding pour des apps, Expo aurait été un meilleur choix à long terme. Comme c’est basé sur React, les données d’entraînement des LLM contiennent bien plus de code React que de Swift, et la qualité du code produit est aussi meilleure
    Tout peut se faire en ligne de commande, et comme c’est une webview, le débogage est facile. Une fois compilée en app iOS native, l’app donne une impression comparable à celle des autres apps natives. En combinant Expo et Fastlane, on peut automatiser entièrement la soumission et la distribution sur iOS, au point d’envoyer une nouvelle version sur l’App Store avec une seule commande

    • N’y a-t-il pas quand même des étapes impossibles à automatiser, comme l’enregistrement initial de l’app quand on en crée une nouvelle ?
    • L’Expo dont vous parlez, c’est bien https://expo.dev/ ? En ce moment, quand on y accède, un message indique qu’« une erreur nécessitant vérification s’est produite et que le code est cassé »