Redonnez à votre équipe la maîtrise de son environnement de build

Notre mission est simple :
en finir avec les files d’attente de build

Nous fournissons des Mac mini physiques dédiés pour que les équipes iOS et macOS choisissent elles-mêmes leur chaîne d’outils, leur environnement de signature et l’ordre des tâches. Pas de machine virtuelle, ni de builds mélangés dans la file d’attente d’autres clients.

Louer un Mac cloud dédié Comparer les modèles et les prix

Facturation à la journée, à la semaine, au mois ou au trimestre. La disponibilité des nœuds est indiquée en temps réel dans la console.

Allocation des ressources
Un nœud entier par client
Configurations
3 configurations Apple Silicon
Emplacements
6 régions au choix
D’abord supprimer l’attente, ensuite automatiser

Une seule fusion ne devrait pas attendre la fin des builds des autres

Ce service est né de deux problèmes récurrents des environnements CI partagés : les équipes ne maîtrisent pas les ressources d’exécution et l’environnement de signature est difficile à isoler.

Distinguer l’attente du build

Après un push, le pipeline peut attendre un runner avant même de commencer la compilation. Ajuster les scripts peut réduire les étapes de build, mais ne réserve pas une file partagée à votre projet. Il devient alors difficile de savoir si le projet ralentit ou si le job n’a simplement pas encore obtenu de ressources.

Nous attribuons un nœud physique complet à un seul client. Votre runner peut n’accepter que les projets indiqués ; vous définissez les labels, les conditions de déclenchement et l’ordre d’exécution. Les autres clients n’ont pas accès à la file de build de cette machine.

Un nœud dédié élimine la concurrence entre clients, mais les projets exécutés sur ce même nœud doivent tout de même gérer leurs tâches parallèles.

Associer l’environnement de signature à votre équipe

Les certificats, profils de provisioning, trousseau, chemins Xcode et caches de dépendances composent l’environnement de build. Dans un environnement partagé, un nettoyage ou un changement de version peut transformer un Archive reproductible en échec nécessitant une enquête manuelle.

Un nœud dédié permet à votre équipe de définir ses propres répertoires, autorisations et conventions d’outillage. Fixez la version de Xcode, séparez les tâches de test et de publication, consignez la configuration de signature, puis intégrez ces règles au pipeline. L’environnement n’est pas une boîte noire éphémère : c’est un actif technique que vous pouvez inspecter et reconstruire.

Un nœud dédié ne remplace pas les sauvegardes. Votre équipe doit conserver des copies du code source, des éléments de signature et des artefacts de publication.

« En finir avec les files d’attente » signifie que vous n’avez pas à attendre que d’autres clients utilisent votre nœud, et non que nous garantissons l’exécution simultanée d’un nombre illimité de tâches. La vitesse de compilation dépend toujours de la taille du projet, du téléchargement des dépendances, de la pression sur la mémoire et du niveau de parallélisme. Testez d’abord votre propre projet avant de choisir la configuration et la durée de location.

Des principes de service vérifiables

Mieux vaut préciser les limites que multiplier les promesses

Nous décrivons le service à l’aide de l’allocation des ressources, des tarifs et des caractéristiques matérielles. Les trois principes ci-dessous s’appliquent aussi bien aux tests de courte durée qu’aux nœuds de build utilisés sur le long terme.

Dédié, sans surallocation

Chaque nœud physique est attribué à un seul client. Le CPU, la mémoire unifiée et le stockage local ne sont pas partagés avec d’autres clients ni répartis à nouveau après division en machines virtuelles.

Vous pouvez exécuter plusieurs projets, mais c’est à vous de maîtriser le parallélisme des tâches. Commencez par établir une référence avec une seule tâche, puis augmentez le nombre de jobs du runner en surveillant la stabilité de la mémoire, du disque et des artefacts générés.

À vérifier : confirmez d’abord que la machine entière vous est dédiée, puis évaluez la charge liée à votre parallélisme.

Des prix affichés pour chaque configuration

Les tarifs à la journée, à la semaine, au mois et au trimestre sont indiqués pour les trois configurations. La formule d’entrée est XR Build 16, à $21.7/jour. Pour une location plus longue, consultez le tarif correspondant plutôt que de cumuler le prix des locations courtes.

Les extensions de stockage et les connexions Thunderbolt 5 sont tarifées séparément. Pour comparer les offres, distinguez la location du nœud des options dont vous avez besoin, puis vérifiez le détail de la configuration avant de payer.

Voir tous les tarifs

Des caractéristiques précises, sans exagération

Le catalogue propose uniquement trois configurations : M4 / 16GB / 256GB, M4 / 24GB / 512GB et M4 Pro / 64GB / 2TB. Le nom du modèle ne remplace pas les caractéristiques de la puce, de la mémoire et du stockage.

Nous ne présentons pas des durées de tâches indicatives comme des garanties de performance pour votre projet. Lors de vos tests, mesurez les builds à froid, incrémentaux et les Archives, en gardant constants la version du code, celle de Xcode et les conditions de cache.

À vérifier : comparez les résultats sur le même projet et dans les mêmes conditions.

Choisir une configuration à partir d’une journée de travail

Quatre workflows, une même garantie de nœud dédié

Les workflows ci-dessous illustrent des profils d’utilisateurs types ; il ne s’agit ni de témoignages clients ni de benchmarks. Chacun précise les tâches à exécuter et les configurations à tester.

Développeur indépendant : coder, puis générer un build

La journée, développez en SwiftUI et peaufinez les interactions en local. Après avoir envoyé votre code, laissez le nœud cloud récupérer la branche choisie, résoudre les dépendances, lancer les tests et xcodebuild archive, puis exporter l’artefact signé et le téléverser sur TestFlight selon le processus de votre équipe.

Commencez par une seule app et peu de tâches simultanées, avec XR Build 16. Conservez le script de publication et les journaux d’erreur pour pouvoir diagnostiquer les problèmes le lendemain sans devoir reconstituer l’environnement de mémoire.

XR Build 16 · M4 / 16GB / 256GB

Louer XR Build 16

Équipe CI : relier les merge requests à un runner

Le matin, consultez les journaux du dernier échec. L’après-midi, après la fusion du code, déclenchez automatiquement un runner self-hosted GitHub ou GitLab. Utilisez des labels pour distinguer les tests unitaires des tâches de publication et Fastlane gym pour gérer les étapes de build, avec une configuration de signature cohérente pour l’app, le widget et l’extension.

Avec plusieurs targets, des tests et des caches, commencez par tester XR Build 24. Augmentez progressivement le parallélisme pour éviter que plusieurs Archives écrivent dans le même répertoire de sortie ou se disputent l’environnement de signature.

XR Build 24 · M4 / 24GB / 512GB

Louer XR Build 24

Expérimentation IA : séparer les tâches de modèle et de build

Le matin, testez l’inférence d’un petit modèle avec MLX en notant le modèle, la méthode de quantification et la mémoire utilisée. L’après-midi, essayez un fine-tuning et enregistrez les checkpoints, puis vérifiez l’export Core ML selon les besoins du projet. Si vous prévoyez des builds la nuit, arrêtez d’abord les processus d’expérimentation ou limitez le parallélisme.

Pour ce type de tâches, vous pouvez commencer par tester XR Build Pro 64. Les 64GB de mémoire unifiée sont une caractéristique précise, pas la garantie que n’importe quel modèle fonctionnera. Estimez d’abord la consommation totale du modèle, du runtime et des autres tâches.

XR Build Pro 64 · M4 Pro / 64GB / 2TB

Louer XR Build Pro 64

Workflow audio et vidéo : confier les tâches à la file, pas votre unique copie

La journée, vérifiez le projet et les chemins des ressources dans l’interface graphique de macOS, ainsi que les licences des logiciels, plugins et polices nécessaires à Logic ou Final Cut. La nuit, lancez le rendu ou les conversions en lot. Une fois terminé, exportez les fichiers, vérifiez leur intégrité, puis supprimez les caches temporaires.

Pour les projets volumineux, vous pouvez tester XR Build Pro 64, mais conservez des copies externes des fichiers source et des livrables. L’expérience à distance dépend de votre réseau local et de la distance au nœud : testez vos fichiers et votre connexion avant toute migration en production.

XR Build Pro 64 · M4 Pro / 64GB / 2TB

Louer XR Build Pro 64
Un catalogue, six emplacements

Choisissez une région, puis vérifiez l’outillage et les modalités de livraison

Tous les emplacements proposent des Mac mini Apple Silicon, dans trois configurations. Choisissez d’abord une région en fonction des horaires de travail et du réseau de votre équipe, puis testez l’accès à distance dans des conditions réelles. Un fuseau horaire proche ne garantit pas une latence réseau plus faible.

Singapour

SG · UTC+8

Un choix adapté aux équipes d’Asie du Sud-Est pour collaborer en journée et planifier des tâches la nuit. Avant la migration, vérifiez l’accès réel au dépôt de code et aux sources de dépendances.

Disponible

Japon · Tokyo

JP · UTC+9

Un choix adapté aux équipes qui travaillent principalement aux horaires japonais. Indiquez le fuseau horaire des tâches de publication dans la configuration CI pour éviter qu’elles utilisent le fuseau par défaut de la machine.

Disponible

Corée du Sud · Séoul

KR · UTC+9

Un choix adapté aux équipes coréennes et d’Asie du Nord-Est qui vérifient les journaux de build et les artefacts. Lors des tests de bureau à distance, vérifiez aussi la saisie de texte et le transfert de fichiers.

Disponible

Hong Kong

HK · UTC+8

Un choix adapté aux équipes travaillant aux horaires de la Chine méridionale et de l’Asie du Sud-Est. Pour accéder aux dépôts depuis une autre région, vérifiez séparément la stabilité de la connexion et le téléchargement des dépendances.

Disponible

États-Unis · Est

US-E · UTC−5 / UTC−4

Un choix adapté aux équipes de la côte Est de l’Amérique du Nord, avec des horaires qui peuvent recouper ceux de l’Europe de l’Ouest. Le décalage local change avec l’heure d’été ; précisez le fuseau horaire des tâches planifiées.

Disponible

États-Unis · Ouest

US-W · UTC−8 / UTC−7

Un choix adapté aux équipes de la côte Ouest de l’Amérique du Nord pour coordonner le dépannage et les publications. Pour faciliter le travail entre fuseaux horaires, conservez le décalage horaire dans les journaux afin d’éviter toute confusion sur l’ordre des tâches.

Disponible

Les disponibilités indiquées correspondent au catalogue actuel ; la console affiche la disponibilité réelle au moment de la commande. Les nœuds fonctionnent toute l’année, 365 jours sur 365. Les incidents matériels sont pris en charge selon la procédure prévue.

Une exploitation axée sur la livraison, les contrôles et la résolution des incidents

Les problèmes matériels ne doivent pas se perdre dans les journaux de build. À la livraison, vérifiez l’environnement ; en cours d’utilisation, distinguez les problèmes de l’application de ceux du nœud. Si une intervention matérielle est nécessaire, clarifiez d’abord les limites concernant les données et leur restauration.

  1. Préparation et vérification à la livraison

    Vérifiez la puce, la mémoire, le stockage et la région, puis préparez macOS et Xcode. Après l’attribution, récupérez les informations de connexion SSH et au bureau à distance dans la console. Votre équipe doit ensuite vérifier les droits administrateur, le chemin de Xcode et les dépendances du projet, puis faire tourner une tâche de validation légère avant de migrer le pipeline de production.

  2. Contrôles et diagnostic

    Nous vérifions la connectivité et l’état du matériel côté nœud. Côté projet, votre équipe surveille l’espace disque disponible, la croissance des caches et les journaux d’échec des tâches. En cas d’anomalie, ouvrez un ticket depuis la console en indiquant la région, le modèle, l’heure de l’incident et le message d’erreur. Commencez par distinguer les problèmes réseau, d’outillage, de signature et de matériel ; ne les attribuez pas tous aux performances de compilation.

  3. Intervention matérielle et validation de la restauration

    Une fois le problème matériel confirmé, nous coordonnons l’intervention ou le remplacement du nœud par ticket et précisons si les informations de connexion changeront et quels éléments devront être redéployés. Votre équipe restaure le code source, les dépendances et l’environnement de signature à partir des sauvegardes, puis vérifie les versions de l’outillage et effectue un build de validation. Le remplacement matériel ne constitue pas une sauvegarde ; un artefact non vérifié ne suffit pas à confirmer la réussite de la restauration.

Connectez-vous à la console pour ouvrir un ticket

Choisissez la configuration qui vous convient

Vérifiez d’abord la puce, la mémoire, le stockage et la durée de facturation, puis testez votre propre projet. Un Archive reproductible peut être le point de départ pour migrer votre file de builds.

Paiement accepté : USDT-TRC20 et Visa / Mastercard / Amex via Stripe. Facturation en dollars américains ; les moyens de paiement disponibles sont ceux indiqués par l’interface de paiement au moment du règlement.

Voir les trois offres de location Louer un Mac cloud