XR Build 16
$21.7 / jour
Commencez par migrer une file de build. Idéal pour une app, les archives courantes et les tests ponctuels. Lancez un Archive complet avant d’ajouter des tâches de test.
- Jour
- $21.7
- Semaine
- $58.5
- Mois
- $108.3
- Trimestre
- $294.6
Pour les développeurs et les équipes de build de Asie de l'Est, exécutez vos compilations Xcode, signatures et files d’automatisation sur un Mac dédié dans le cloud. Le nœud physique entier est réservé à un seul client : ce n’est pas une machine virtuelle.
À partir de $21.7/jour. La configuration finale, la disponibilité réelle et l’avancement de la mise à disposition sont indiqués en temps réel dans le portail.
Vérifiez d’abord la configuration et le réseau, puis migrez votre projet. La latence est un indicateur de connexion, pas une promesse de durée de compilation ou de débit.
Choisissez votre Mac selon la mémoire et le stockage, puis sélectionnez la durée souhaitée. Les trois configurations sont des Mac mini physiques dédiés, avec macOS en interface graphique et en ligne de commande. Après la commande, vérifiez le nœud, la période et le montant dans le portail.
Ce sélecteur sert à comparer les prix. Confirmez la période de facturation dans le configurateur de commande.
$21.7 / jour
Commencez par migrer une file de build. Idéal pour une app, les archives courantes et les tests ponctuels. Lancez un Archive complet avant d’ajouter des tâches de test.
$40.8 / jour
Plus de marge pour les projets avec plusieurs targets. Adapté aux projets avec widgets, extensions et tests UI, ou aux pipelines quotidiens qui conservent davantage de dépendances et de caches de build.
$59.5 / jour
Pour les charges de travail plus importantes : matrices de simulateurs en parallèle, expériences MLX et caches volumineux. Définissez le niveau de concurrence à partir de la mémoire et des entrées-sorties disque mesurées sur votre projet.
Tous les prix sont en dollars américains (USD). Paiement uniquement par USDT-TRC20 ou Visa / Mastercard / Amex via Stripe. Les moyens de paiement disponibles dépendent de la réponse de l’interface. Pour ajouter un SSD de +1TB ou +2TB, ou mettre plusieurs unités en parallèle avec Thunderbolt 5, vérifiez les options et le prix total dans le configurateur.
La latence moyenne indicative depuis Asie de l'Est est de 30~60 ms. Cette plage aide à évaluer la distance réseau ; elle ne correspond pas à une mesure en temps réel de votre connexion et ne constitue pas une valeur fixe pour tous les opérateurs ou à toute heure.
VNC est plus sensible à la latence aller-retour et à la gigue : la réactivité des commandes, le déplacement des fenêtres et le rafraîchissement de l’écran dépendent tous de votre réseau local. Avec SSH, la compilation s’effectue sur le nœud physique ; le réseau influe surtout sur le retour des commandes, le téléchargement des dépendances et le transfert des artefacts.
Commencez par identifier le goulot d’étranglement. Une image saccadée ne signifie pas que la compilation CPU est lente, et le transfert lent d’un artefact ne révèle pas nécessairement un problème de configuration Xcode. Mesurez séparément la réactivité, la durée des builds et la vitesse de transfert pour repérer ce qu’il faut ajuster.
Le routage international, le Wi-Fi local, le proxy d’entreprise et la congestion de l’opérateur peuvent modifier la qualité de la connexion. Lors de la première connexion, testez votre réseau habituel et un réseau de secours, puis recommencez pendant les heures de travail de l’équipe.
Après la mise à disposition, utilisez l’adresse du serveur indiquée dans le portail pour vérifier la latence aller-retour, puis transférez un artefact représentatif. Ne choisissez pas un nœud uniquement d’après son nom de région et ne déduisez pas le débit soutenu d’un grand projet à partir du transfert d’un petit fichier.
Le nœud fonctionne toute l’année, 365 jours par an. Pour diagnostiquer un problème de connexion, ouvrez un ticket dans le portail et joignez ces informations. Ne publiez pas vos identifiants de connexion ni vos clés privées.
Les durées ci-dessous sont des marges de temps conseillées pour les opérations manuelles, pas une promesse de délai d’attribution du nœud ou de confirmation du paiement. La vérification du compte, le traitement par le prestataire de paiement, le téléchargement des dépendances et la taille du projet influent sur la durée totale. Le statut de la commande dans le portail fait foi.
Sélectionnez le Mac, le nœud et la période à la journée, à la semaine, au mois ou au trimestre, puis vérifiez si vous avez besoin de stockage supplémentaire. Pour votre premier test, migrez un seul Scheme sans modifier en même temps les outils ni la stratégie de concurrence.
Prévoir
2–5 min
Confirmez le montant de la commande en dollars, puis choisissez le moyen de paiement proposé. Avec USDT-TRC20, vérifiez le réseau et les informations de paiement. Pour une carte, suivez les instructions du prestataire. Consultez le statut de la commande après le paiement.
Vérification manuelle
2–5 min
Confirmation du paiement en sus
Attendez que le portail confirme l’attribution, puis vérifiez le modèle, macOS, Xcode et les identifiants SSH / VNC. Testez les outils avec SSH et effectuez les réglages nécessaires via l’interface graphique.
Vérification des informations
5–10 min
Attribution du nœud en sus
Synchronisez le code source, résolvez les dépendances, importez les certificats et profils de provisioning requis, puis lancez un Archive. Vérifiez les journaux, les artefacts et leur chemin de retour avant d’intégrer un runner self-hosted.
Vérification de l’environnement
10–20 min
Téléchargement et build en sus
Conservez au moins une compilation réussie, avec sa version, sa commande et ses journaux. Vérifiez qu’un même commit génère à nouveau le même artefact, puis testez le répertoire de travail du runner, le chemin du cache et le déverrouillage du trousseau. Pouvoir se connecter au bureau ne signifie pas que la migration du pipeline d’automatisation est terminée.
Déterminez d’abord où vous vous connectez, où les tâches s’exécutent et où les données sont traitées avant d’y déplacer votre file de build principale.
Cette plage indicative ne garantit pas les performances de chaque connexion. La qualité réelle de l’accès au nœud de Tokyo dépend de votre opérateur, de votre sortie réseau, du routage et des conditions du moment. Après la location, effectuez plusieurs tests depuis votre réseau professionnel habituel. Si vous avez seulement besoin de builds sans surveillance, vérifiez en priorité la stabilité de SSH, le téléchargement des dépendances et le transfert des artefacts, plutôt que la réactivité du bureau à distance.
Oui. La région est un repère pour choisir le réseau et le fuseau horaire de travail, pas une restriction liée à l’emplacement de l’équipe. Les tâches s’exécutent sur le nœud et les équipes réparties sur plusieurs fuseaux peuvent utiliser la même file. Les personnes qui utilisent souvent le bureau à distance doivent toutefois tester la réactivité depuis leur propre réseau. Utilisez des labels de runner et des verrous de tâches cohérents pour éviter que plusieurs builds ne modifient le même répertoire de travail.
Le choix du nœud détermine l’emplacement de la machine physique qui exécute vos tâches. Il ne permet pas de conclure que les données de compte, de facturation, de support ou de paiement sont toutes traitées dans la même région. Les transferts vers des services externes de code source, de caches et d’artefacts dépendent également de votre dépôt et de votre pipeline. Si votre projet impose des exigences précises sur le lieu de traitement, écrivez à support@xcoderent.com avant la location en indiquant les types de données concernés et les limites à respecter. Attendez confirmation avant d’envoyer votre projet.
Choisissez une configuration, réussissez un Archive, puis migrez l’automatisation. Vérifiez les outils, le réseau et les artefacts avant d’augmenter la concurrence.