Une machine physique dédiée, pas une machine virtuelle, six sites,$20.1/jour
Un Mac dédié pour votre équipe iOS : clonez le code, créez l’archive, signez-la et envoyez-la sur TestFlight.
SG
Tokyo JP
Séoul KR
Hong Kong HK
États-Unis (Est) US-E
États-Unis (Ouest) US-W
| Scheme | Version | Site | Durée | Signature |
|---|---|---|---|---|
| Ledger-iOScompilé à 09:42 | 2.8.1 (412) | Singapore | 6m12s | Signé |
| Ledger-Widgetcompilé à 09:38 | 2.8.1 (412) | Singapore | 2m47s | Signé |
| Ledger-Watchcompilé à 09:21 | 2.8.1 (412) | Tokyo | 3m05s | Signé |
| Ledger-Betacompilé à 08:57 | 2.8.1 (411) | Hong Kong | 6m30s | Signé |
| Ledger-macOScompilé à 23:10 | 2.8.0 (409) | US West | 7m02s | Signé |
** EXPORT SUCCEEDED **
Ledger-iOS.ipa · 48.2 MB
Envoyé sur TestFlight
Disponible pour le groupe de test interne « QA-Nightly »
TestFlight · Confirmation d’installation
2.8.1 (412)Contenu du test : correction du cache hors ligne de la page de commande et ajout du mode sombre au widget.
Aucun runner partagé avec d’autres clients. Votre code, vos dépendances et votre cache de build restent sur votre propre machine physique.
Le Mac mini entier est attribué à un seul client. Processeur, mémoire et disque ne sont pas partagés : plus besoin d’attendre la fin des tâches d’un autre pour créer vos archives.
Conservez les téléchargements SPM, les dépendances CocoaPods et DerivedData par projet. L’utilisation du cache dépend de la branche, des versions des dépendances et des paramètres de build : inutile de recréer l’environnement à chaque compilation.
Pour une semaine de rush avant une version, choisissez simplement une semaine : configuration M4 à $54.2/semaine. Pour les builds nightly en continu, comparez les tarifs mensuel et trimestriel, sans acheter d’abord une machine de build pour le bureau.
Les tarifs des quatre durées sont publics. Choisissez d’abord selon la durée de vos tâches, puis vérifiez le site, le stockage et la date d’expiration. Une fois la machine livrée, gérez la file de builds avec vos propres scripts.
Singapour, Tokyo, Séoul, Hong Kong, États-Unis (Est) et États-Unis (Ouest). Les deux configurations sont disponibles sur ces six sites. Choisissez selon l’emplacement de votre équipe et de vos services dépendants.
Pour le développement à distance, tenez compte de la latence interactive. Pour les builds automatisés, vérifiez aussi le chemin vers le dépôt de code et le transfert des artefacts. Les sites fonctionnent 365 jours par an, pour confier vos builds planifiés à une machine dédiée.
Dès $20.1/jour. Pour archiver une seule app, optez pour le M4 ; pour plusieurs Target, des tests en parallèle ou de l’inférence, choisissez le M4 Pro.
Une configuration de départ pour une app et 1 à 3 archives par jour. Installez votre code source, Xcode et vos dépendances courantes, puis voyez si un SSD supplémentaire est nécessaire.
Une configuration confortable pour plusieurs Target, les tests UI et les expérimentations MLX. Le nombre de tâches exécutables en parallèle dépend du pic de mémoire du projet et de la charge de test : faites un premier essai avant d’augmenter la concurrence.
Tous les prix sont en dollars américains. La disponibilité réelle des sites est indiquée en temps réel dans la console. Avant de payer, vérifiez la durée, les options supplémentaires et le montant total de la commande.
Du push à TestFlight, gardez les outils que vous connaissez. Voici les cinq étapes du transfert avec Ledger-iOS ; les durées sont données à titre d’exemple.
Après votre commit local, poussez la branche. Le CI que vous avez configuré déclenche la tâche de build.
git push origin release/2.8.1
Figez le commit pour éviter les écarts entre l’archive et l’historique de publication si la branche évolue.
git fetch origin release/2.8.1 && git checkout --detach FETCH_HEAD
Précisez le Scheme, la configuration Release et le chemin de l’archive ; les journaux sont conservés avec les artefacts.
xcodebuild -scheme Ledger-iOS -configuration Release -destination 'generic/platform=iOS' -archivePath build/Ledger.xcarchive archive
Préparez le certificat et le profil de provisioning, puis définissez la signature et le mode de distribution dans la configuration d’export.
xcodebuild -exportArchive -archivePath build/Ledger.xcarchive -exportOptionsPlist Export.plist -exportPath build/export
Configurez les autorisations de distribution, envoyez l’IPA, puis récupérez le build disponible dans votre groupe de test.
fastlane pilot upload --ipa build/export/Ledger-iOS.ipa --api_key_path asc-key.json
Cette procédure doit être configurée par votre équipe : la location ne prend pas automatiquement en charge votre dépôt. Pour commencer, alignez les versions de Xcode, les fichiers de verrouillage des dépendances et la configuration de signature, puis enregistrez un runner self-hosted GitHub Actions, un GitLab Runner ou un agent Jenkins. La taille du projet, le cache et le réseau influent sur la durée réelle.
Commencez par filtrer selon le fuseau horaire de votre équipe, puis examinez le chemin de connexion jusqu’au site. Les latences ci-dessous sont des estimations régionales, pas des mesures ville par ville.
Asie du Sud-Est
Idéal pour les équipes d’Asie du Sud-Est qui développent le jour et exécutent leurs archives et tâches de distribution la nuit.
Choisir le site de SingapourAsie de l’Est
Idéal pour les équipes qui planifient développement, tests et transfert des builds nightly sur les heures de travail en Asie de l’Est.
Choisir le site de TokyoAsie du Nord-Est
Idéal pour la collaboration en Asie du Nord-Est : développement à distance et diagnostic des builds dans les mêmes horaires de travail.
Choisir le site de SéoulSud de la Chine et Asie du Sud-Est
Adapté aux équipes en UTC+8. La qualité de connexion dépend aussi de votre opérateur local et du routage.
Choisir le site de Hong KongEst de l’Amérique du Nord et Europe de l’Ouest
Idéal pour collaborer entre l’est de l’Amérique du Nord et l’Europe de l’Ouest. Planifiez les archives avant le passage de relais pour que l’équipe suivante récupère les journaux et les builds de test.
Choisir le site des États-Unis (Est)Côte ouest de l’Amérique du Nord
Adapté aux horaires de travail de la côte ouest de l’Amérique du Nord. Évaluez ensemble le clonage du dépôt, le téléchargement des dépendances et l’envoi des artefacts, sans vous limiter à la réactivité du bureau à distance.
Choisir le site des États-Unis (Ouest)Les fuseaux horaires sont donnés à titre indicatif ; certaines régions changent selon la saison. La latence réelle dépend de votre emplacement, de votre opérateur et du chemin réseau. La disponibilité réelle est indiquée en temps réel dans la console.
Décrivez précisément votre usage pour savoir si la location est adaptée. Voici trois exemples de scénarios.
Nous avons déplacé nos builds nightly du MacBook d’un collègue vers le site de Tokyo. Le matin, l’IPA est déjà sur TestFlight quand nous arrivons au bureau.
Avec le M4 Pro 64GB, Fastlane et les tests UI passent du premier coup, sans attendre qu’un runner partagé se libère.
Je fais tourner localement un modèle 7B pour mes tests d’inférence, puis j’arrête après une semaine de location : la facture est limpide.
Choisissez d’abord la machine et la durée, puis vérifiez la passerelle proposée sur la page de paiement. Gérez les factures et les machines depuis la console.
Tous les paiements sont en dollars américains (USD). Les moyens de paiement disponibles sont confirmés par le système au moment de la transaction. Stripe traite les numéros de carte ; nous ne les stockons pas. Après paiement, consultez vos commandes, l’état de livraison, les factures et les options de renouvellement dans la console. Vous pouvez également y ouvrir un ticket pour toute question technique.
DerivedData, le cache SPM et les images de simulateur occupent progressivement de l’espace disque. Distinguez les caches recréables des archives à conserver avant de choisir la capacité supplémentaire.
Un SSD externe convient aux caches de build et aux ressources volumineuses. Avant la fin de la location, synchronisez le code source, les archives et les journaux à conserver vers votre propre stockage ; ne faites pas du disque supplémentaire votre seule sauvegarde.
Voir le tarif complet des optionsDerivedData et cache SPM
Images de plusieurs versions du simulateur, conservation des archives
Pour faire collaborer plusieurs M4 Pro, vérifiez d’abord la topologie et la répartition des tâches
Des procédures concrètes pour la distribution, l’environnement distant et la signature. Faites d’abord un essai complet, puis automatisez les étapes répétitives.
Définissez un contrat d’import XML avec un script Swift et vérifiez ses limites à l’aide de fichiers de test reproductibles.
DevOps et CI/CDUn comparateur SemVer sans conversion en entier, des cas limites reproductibles et une séparation nette entre ordre des versions et politique de mise à jour.
DevOps et CI/CDExtraire la logique de géorepérage pour tester les distances, rejeter les positions imprécises et stabiliser les transitions avec deux seuils.
De nouveaux articles arrivent. Consultez d’abordla liste du blog.
Clarifiez la machine, la chaîne d’outils et les modalités de transfert des données.
Vous disposez d’un Mac mini physique complet, réservé à votre usage, et non d’une machine virtuelle. Le processeur, la mémoire, le disque et le cache de build ne sont pas partagés. L’interface graphique macOS et la ligne de commande sont disponibles ; votre équipe doit toujours configurer les dépendances du projet, les certificats de signature et les tâches CI.
Location à la journée, configuration M4 à $20.1/jour ; configuration M4 Pro à $60.3/jour. Trois autres durées sont proposées : semaine, mois et trimestre. Pour tester temporairement une chaîne d’outils, commencez par une journée ; pour un sprint de version, comparez le tarif à la semaine ; pour des builds nightly continus, comparez les tarifs au mois et au trimestre. Vérifiez la durée, le montant et la date d’expiration avant de payer.
Vous pouvez installer un runner self-hosted ou GitLab Runner sur la machine, ou connecter un agent Jenkins. Commencez par fixer la version de Xcode et les dépendances, puis configurez votre lane Fastlane. Attribuez les tags du runner uniquement aux tâches de build prévues pour éviter que plusieurs archives se disputent le même répertoire. Pour la connexion et la migration, consultezConnexion à la machine.
Vous devez d’abord configurer le projet et la signature. Préparez le Scheme, le certificat, le profil de provisioning et Export.plist ; vous pouvez utiliser une clé API App Store Connect pour l’envoi en distribution. Ne publiez pas de fichier .p12, de clé privée ni de clé API dans un dépôt public. Faites d’abord manuellement un cycle complet d’archive et d’export, puis configurez le déclenchement automatique pour faciliter le diagnostic.
Après la récupération de la machine, le disque est effacé de manière sécurisée et le système est réinstallé avant sa remise au prochain client. Avant l’échéance, exportez les archives, artefacts et journaux à conserver, supprimez les certificats et identifiants d’accès CI, puis révoquez les autorisations inutilisées. Pour continuer, vérifiez le renouvellement et l’état de la commande dans la console. Ne faites pas du nœud de build votre seul espace de stockage.
Ouvrez un ticket depuis la console en indiquant le numéro de commande, le site, la version de Xcode, la commande permettant de reproduire le problème et les 50 dernières lignes du journal. Précisez s’il s’agit d’un échec de connexion SSH, de téléchargement des dépendances, de compilation ou de signature, ainsi que la dernière modification effectuée. Supprimez les jetons, clés privées et mots de passe des journaux. Vous pouvez aussi écrire à support@osxbuild.com.
Choisissez une configuration et un site. Une fois la machine livrée, testez la connexion SSH puis lancez votre première archive. Laissez le processus gérer les publications : fini d’attendre qu’un Mac se libère.