Avant la location comme après le démarrage,
voici les questions que vous vous posez.

Le paiement est effectué à l’avance : choisissez d’abord une machine, puis une durée. Les tarifs à la journée, à la semaine, au mois et au trimestre sont indépendants ; le tarif journalier ne se multiplie pas simplement par le nombre de jours. Choisissez la durée qui correspond à votre usage.

Les SSD supplémentaires et le couplage Thunderbolt 5 sont facturés à part. Avant de payer, vérifiez le modèle, l’emplacement, la durée, les options et le montant dû sur la page de commande. Les dates effectives de début et de fin sont celles indiquées dans le portail.

Ouvrez d’abord un ticket depuis le portail en indiquant le numéro de commande, la configuration souhaitée, l’espace disque utilisé et le créneau où vous pouvez interrompre les builds. Chaque configuration repose sur une machine physique distincte : un changement ne correspond pas à une mise à niveau à chaud de machine virtuelle.

Attendez que l’assistance confirme la procédure de migration, les frais éventuels et le calendrier de transfert. Avant la migration, exportez votre configuration et sauvegardez vos projets, éléments de signature et artefacts. Ne partez pas du principe qu’un changement de mémoire préservera l’état de la machine. En cas de passage à une configuration inférieure, vérifiez surtout que le SSD cible peut accueillir toutes vos données.

Voici les tarifs des options. Le couplage Thunderbolt 5 est facturé par machine ; il ne s’agit pas d’un supplément de stockage ou de mémoire inclus dans la configuration de base. Lors de la commande, fiez-vous aux options disponibles et aux conditions affichées par le configurateur.

La possibilité d’ajouter ou de retirer une option en cours de location et la procédure de migration de ses données dépendent de votre commande. Ne débranchez pas un disque supplémentaire sans sauvegarde et ne supposez pas qu’une option peut être utilisée séparément de la machine ou remboursée indépendamment.

Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Tous les produits et toutes les commandes sont facturés en dollars américains (USD). Les moyens de paiement disponibles sont ceux indiqués par la passerelle de paiement au moment de la transaction.

Pour payer en USDT-TRC20, suivez le réseau, l’adresse et le montant indiqués sur la page de paiement, puis conservez le hash de transaction. Pour une carte bancaire, effectuez la vérification demandée par la passerelle. Une capture d’écran du paiement ne confirme pas la livraison de la machine : vérifiez le statut de la commande dans le portail.

Vérifiez d’abord la commande et la facture dans le portail pour vous assurer qu’il s’agit bien de la même commande. Ne payez pas une seconde fois avant d’avoir vérifié le statut. Pour un virement on-chain, contrôlez aussi le réseau, l’adresse du destinataire, le montant et le hash de transaction.

Ouvrez ensuite un ticket en indiquant le numéro de commande, le moyen de paiement, l’heure du paiement et sa référence. Pour un paiement par carte, ne communiquez ni le numéro complet ni le code de vérification. Pour USDT-TRC20, le hash de transaction suffit. Pour obtenir de l’aide par e-mail, écrivez à support@osxhost.com.

Avant de renouveler, vérifiez dans le portail la date d’expiration du service, la durée souhaitée et le montant à régler. Après le paiement, vérifiez à nouveau la nouvelle date d’expiration. Le fait qu’une tâche tourne encore sur votre machine ne prouve pas que la commande a été renouvelée.

La résiliation anticipée, la modification des options et les remboursements sont traités selon la commande et les conditions de service. Aucun remboursement automatique au prorata des heures restantes n’est garanti. Pour faire une demande, indiquez le numéro de commande, le motif et la date à laquelle vous souhaitez interrompre le service. Conservez la facture et la preuve de paiement jusqu’à la confirmation du traitement.

Consulter les conditions de commande et de facturation

Il s’agit d’une machine physique dédiée, pas d’une machine virtuelle. Chaque Mac mini Apple Silicon est attribué à un seul utilisateur pendant toute la durée de la location. Son processeur, sa mémoire unifiée et son stockage ne sont pas partagés avec d’autres clients. L’interface graphique de macOS et la ligne de commande sont disponibles.

Un matériel dédié n’empêche pas les tâches de se disputer les ressources. Sur une même machine, les opérations d’archive, les simulateurs, les conteneurs et l’inférence de modèles utilisent les mêmes ressources. Commencez par exécuter les tâches en série, puis augmentez progressivement la concurrence en surveillant la pression mémoire et l’espace disque.

Trois configurations sont disponibles : Host M4 Lite (M4 / 16GB / 256GB), Host M4 Plus (M4 / 24GB / 512GB) et Host M4 Pro (M4 Pro / 64GB / 2TB). Le stockage de base et les SSD supplémentaires sont des options distinctes.

Pour le build courant d’une seule app, commencez par Lite. Pour plusieurs targets, Flutter et des simulateurs en parallèle, regardez Plus. Pour les gros projets, les archives simultanées, les exports Unity ou l’inférence MLX, envisagez Pro. Avant de choisir, estimez l’espace maximal requis par DerivedData, les caches de dépendances, les runtimes de simulateur et les artefacts d’archive ; la taille du dépôt seule ne suffit pas.

Comparer les caractéristiques et les 3 configurations

Vérifiez d’abord la compatibilité entre la version de Xcode dont vous avez besoin et celle de macOS, puis confirmez avant la commande quelle version peut être livrée. Si vous avez besoin d’une version précise, contactez l’assistance pour confirmation avant de payer. Ne supposez pas que toutes les anciennes versions peuvent être installées.

Après livraison, notez la version du système, le chemin de Xcode et la liste des SDK. Une mise à jour du système peut affecter les outils de signature, les dépendances Ruby et les runners. Prévoyez une sauvegarde que vous pourrez restaurer, puis vérifiez les changements dans une tâche séparée avant de modifier votre pipeline de production.

Vous pouvez prévoir plusieurs versions de Xcode en fonction de la compatibilité du système et de l’espace disque disponible. Utilisez d’abord les versions bêta pour vos tests de compatibilité ; ne remplacez pas directement la version utilisée par votre pipeline stable. Le téléchargement et l’utilisation des logiciels doivent respecter leurs licences respectives.

Dans la CI, définissez explicitement DEVELOPER_DIR pour chaque tâche afin qu’un changement global n’affecte pas les autres builds. Après avoir changé de version, exécutez xcodebuild -version et xcodebuild -showsdks, vérifiez dans les logs quelle chaîne d’outils est réellement utilisée, puis lancez les tests et l’archivage.

Les cinq emplacements proposés sont Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong et l’ouest des États-Unis. Les trois configurations sont disponibles dans ces cinq emplacements. La disponibilité en temps réel est indiquée dans le portail.

Pour choisir, tenez compte de l’emplacement de votre équipe, de votre dépôt de code et du stockage des artefacts. Le nom d’un emplacement ne garantit pas la latence entre régions : les opérateurs, réseaux d’entreprise et modes de connexion à distance peuvent aussi influencer l’expérience.

La bande passante, l’attribution des adresses et les ports de connexion dépendent des informations de l’offre, du portail et des détails de livraison. Une vitesse unique, une IP publique dédiée ou l’ouverture de n’importe quel port ne sont pas garanties pour toutes les commandes.

Si votre tâche nécessite une adresse IP de sortie fixe, des rappels entrants, une liste d’autorisation IP ou l’envoi de nombreux artefacts, indiquez avant la commande les protocoles, le sens du trafic, les services concernés et le volume prévu afin que l’assistance confirme la faisabilité. Après livraison, vérifiez SSH et les ports nécessaires à votre activité avant de connecter la CI. N’ouvrez que les accès indispensables.

Pour une utilisation graphique à distance, privilégiez un emplacement proche de vous avec un routage stable. Pour les builds automatisés, tenez davantage compte du téléchargement des dépendances, du clonage du dépôt et de l’envoi des artefacts. La distance géographique ne suffit pas à déterminer quel pipeline sera le plus rapide.

Comparez depuis votre réseau la stabilité de la connexion, le temps de clonage du dépôt et les logs d’un build complet. Pour confirmer les conditions de connexion, indiquez votre fuseau horaire, votre environnement réseau et les principaux outils utilisés. Nous ne fournissons pas de mesures de latence en temps réel pour chaque ville.

Consulter les instructions SSH et partage d’écran

Oui, elle peut servir de runner de build auto-hébergé. Enregistrez un runner GitHub Actions self-hosted, un GitLab Runner ou un agent Jenkins. Commencez par exécuter manuellement le build dans le terminal, puis transmettez au runner le même répertoire de travail, les chemins des outils et les variables d’environnement.

Utilisez un compte de build distinct et limitez les tags du runner ainsi que les dépôts autorisés. Ne laissez pas des contributions externes non fiables accéder aux identifiants de signature. Commencez avec peu de tâches simultanées, puis surveillez la pression mémoire, le nombre de simulateurs et les artefacts d’archive. Évitez que plusieurs tâches écrivent dans le même répertoire.

Séparez les éléments de signature du code source. Vous pouvez gérer les éléments chiffrés avec fastlane match et transmettre la phrase secrète de déchiffrement via une variable CI protégée. Ne stockez pas de clé privée, de mot de passe ni d’identifiants complets dans un dépôt ou un ticket.

Utilisez un trousseau dédié aux tâches de build et limitez ses autorisations d’accès. Évitez d’exposer des valeurs sensibles dans les logs. Conservez une sauvegarde chiffrée hors de la machine et révoquez les autorisations devenues inutiles lorsque les personnes ou les tâches changent. Avant la fin de la location, supprimez les identifiants locaux et les variables CI : effacer le répertoire du projet ne suffit pas.

Le débogage d’un appareil avec Xcode et les tests sur simulateur sont deux choses différentes. La machine dans le cloud permet d’exécuter les workflows adaptés des outils de développement, mais l’accès à distance ne connecte pas automatiquement à un centre de données les appareils USB branchés à votre ordinateur.

Si vous avez besoin d’un appareil physique ou d’un périphérique USB, indiquez son modèle, le mode de connexion, les étapes d’autorisation et le scénario de test prévu dans un ticket. L’assistance confirmera les possibilités de connexion sur place avant la commande. Sans confirmation, ne considérez pas la connexion directe d’un appareil local comme une fonctionnalité incluse. Pour les tests sur simulateur uniquement, vous pouvez suivre le workflow Xcode habituel.

Les builds iOS avec Flutter et React Native peuvent réutiliser Xcode, CocoaPods et la configuration de signature. Fixez les versions des dépendances, isolez les caches par projet et exécutez pod install puis un build complet avant de décider quels caches partager entre les tâches.

Docker et OrbStack conviennent aux services auxiliaires de build, mais les conteneurs Linux ne remplacent pas l’archivage Xcode sous macOS. Sur Apple Silicon, vérifiez la compatibilité de l’architecture des images. Les conteneurs, simulateurs et builds partagent les ressources de la machine : intégrez-les tous à votre budget de tâches simultanées.

La disponibilité garantie est calculée sur une base mensuelle à 99,9 %. Sur la base d’un mois de 30 jours, cela correspond à environ 43 minutes d’indisponibilité autorisée. Il s’agit d’une conversion du seuil garanti, pas d’une interruption prévue chaque mois.

Tous les emplacements fonctionnent normalement 365 jours par an. Consultez les conditions de service pour savoir quels incidents sont considérés comme des indisponibilités, le périmètre couvert et la méthode de calcul. Une erreur de tâche ou une action de l’utilisateur ne signifie pas que le nœud physique est indisponible.

La durée au-delà du seuil est compensée par une prolongation du service calculée selon la durée d’impact. La compensation concerne la commande affectée ; la garantie affichée ne signifie pas qu’un remboursement en espèces ou une machine supplémentaire indépendante sera automatiquement accordé.

Pendant l’incident, conservez les erreurs de connexion, les logs des tâches et les heures de début et de fin observées, avec leur fuseau horaire. Après vérification de l’incident et de la commande, l’assistance confirmera la durée prise en compte et la prolongation éventuelle. Vous pourrez ensuite vérifier la date d’expiration du service dans le portail.

Dans les 7 jours suivant la fin de l’incident, ouvrez un ticket dans le portail avec le numéro de commande, l’emplacement, les heures de début et de fin de l’impact ainsi que le fuseau horaire. Ajoutez des erreurs ou des extraits de logs vérifiables. Si plusieurs commandes sont concernées, indiquez-les séparément au lieu de signaler simplement une « indisponibilité toute la nuit ».

N’envoyez pas de mot de passe, de clé privée SSH ni de certificat de signature. Les tickets servent à relier la demande aux informations du service. Pour une question générale, vous pouvez envoyer un e-mail ; pour une demande liée à une commande, privilégiez le portail après connexion.

Après la fin de la location, les données sont effacées de manière sécurisée, puis le disque est nettoyé et le système réinstallé avant la remise à disposition. La plateforme n’accède pas aux projets ni aux certificats présents sur votre machine. Ne conservez pas vos données de travail sur la machine comme unique copie à long terme.

Avant de terminer, exportez les projets, logs de build et artefacts à conserver, révoquez les runners, clés de déploiement et autres jetons de service, puis vérifiez que vos sauvegardes externes sont lisibles. Ne comptez pas sur la récupération de données après effacement comme une fonctionnalité du service.

Les règles d’expiration, de conservation et de libération affichées dans le portail font foi. Aucune durée de conservation supplémentaire uniforme n’est garantie, et le téléchargement des fichiers après expiration du service n’est pas assuré. Si vous avez une échéance de transfert précise, confirmez-la avant l’expiration en ouvrant un ticket.

Avant l’expiration, arrêtez les nouvelles tâches et transférez les artefacts d’archive et les configurations nécessaires hors de la machine. Vérifiez que vous pouvez les restaurer avant de mettre fin au service. Si vous souhaitez continuer, renouvelez à l’avance ; une connexion SSH encore active ne confirme pas le renouvellement.

Connectez-vous d’abord au portail pour consulter les informations de livraison de l’instance. Les identifiants de connexion et ceux du compte sont distincts. Ne publiez pas votre mot de passe dans les logs, les artefacts de build ou le corps d’un e-mail.

Si vous soupçonnez une fuite, arrêtez les tâches non fiables, révoquez les clés et jetons concernés, vérifiez les autorisations des runners et ouvrez un ticket en précisant le numéro de commande et l’heure de la découverte. Si vous ne pouvez pas vous connecter au portail, écrivez à support@osxhost.com depuis l’adresse e-mail associée à votre compte et suivez la procédure de vérification d’identité demandée par l’assistance.

Pour une question sur une commande, privilégiez le ticket dans le portail. Pour choisir une formule avant l’achat, organiser un achat d’équipe ou résoudre un problème de connexion au compte, écrivez à support@osxhost.com. Ce sont les deux seuls canaux de contact ; inutile de soumettre la même demande ailleurs.

Indiquez clairement le numéro de commande, l’emplacement, l’heure et le fuseau horaire, le résultat attendu, l’erreur constatée et les étapes déjà essayées. Pour un problème de build, ajoutez la version de Xcode, la commande exécutée et des logs expurgés de toute donnée sensible. Des étapes de reproduction complètes sont plus utiles qu’une simple capture d’écran d’échec.

Préparer votre demande selon le type de problème