Note de transfert pour les ingénieurs build

Notre mission :
compiler iOS sans attendre une machine

OSXBuild fournit des Mac cloud dédiés : une machine physique complète, pas une machine virtuelle. Vous gardez la maîtrise de votre code, de votre chaîne d’outils et de la signature ; nous hébergeons la machine dans des emplacements disponibles à la location.

Deux configurations · six emplacements physiques · $20.1par jour dès

Le problème ne se règle pas en achetant une machine de plus

Le Mac mini du bureau
ne devrait pas être le maillon faible de vos releases

Gérer sa propre machine de build, ce n’est pas seulement réussir le premier archive : c’est pouvoir retrouver la même machine, les mêmes caches et les mêmes ressources de signature à la prochaine release.

Après une coupure, personne ne prend le relais

Une machine au bureau dépend de son environnement local. Une panne de courant ou de réseau peut interrompre une tâche à distance avant l’archivage. Si vous êtes absent, il faut d’abord demander à quelqu’un d’intervenir sur place, puis reprendre l’analyse des logs de build.

Nous hébergeons les machines de build hors du bureau. Elles fonctionnent toute l’année, 365 jours par an ; leur état et les informations de livraison sont consultables dans la console.

Sur une machine partagée, les builds font la queue

Débogage quotidien, tests sur simulateur et archivage des releases se disputent les ressources. Il faut se coordonner pour savoir qui lance quoi et qui a vidé le cache. Même après un build réussi, reste à expliquer pourquoi les dépendances ont été téléchargées à nouveau au suivant.

Sur un emplacement dédié, CPU, mémoire et disque ne sont pas partagés avec d’autres clients. Organisez vos runners selon les besoins de l’équipe, sans attendre la fin des tâches d’un autre.

Des certificats éparpillés, des transferts à l’oral

Certificats, profils de provisionnement, paramètres d’export et scripts sont dispersés sur plusieurs ordinateurs. Le processus de release finit par dépendre d’une seule personne. Au changement de machine, il faut tout reconfigurer.

Nous recommandons de versionner la configuration de build et de conserver les ressources de signature dans un trousseau contrôlé ou un processus de gestion des secrets. Ne placez pas de clés privées dans un dépôt partagé.

Voilà pourquoi nous proposons uniquement des Mac cloud dédiés : nous ne modifions pas le code de votre application et ne transformons pas la signature en service opaque. Nous fournissons une machine que vous contrôlez, prête à accueillir vos workflows Xcode, Fastlane et CI existants.

Trois principes de service

Clarifier le cadre avant de fournir la machine

Avant de commander, vous devez savoir ce que comprend la location, comment les frais sont calculés et où se trouve la machine.

Une machine physique, un seul client

Vous louez un Mac mini dédié, pas une machine virtuelle découpée dans un serveur partagé. Vous gérez l’environnement système, les caches de build et la file des tâches ; aucun build d’un autre client ne sera exécuté sur cette machine.

Dédié ne signifie pas sans limite de concurrence. Vos tâches se partagent toujours les ressources d’une même machine. Mesurez d’abord le temps d’un archivage, puis déterminez le niveau de concurrence des tests.

Voir l’isolation et le traitement des données

Des tarifs publics, des options détaillées

Les deux configurations sont disponibles à la journée, à la semaine, au mois ou au trimestre. Le tarif de la configuration de base et celui des options SSD et Thunderbolt 5 en parallèle sont indiqués séparément, avec un catalogue complet et transparent.

Tous les paiements sont en dollars américains. Avant de commander, vérifiez le modèle, l’emplacement, la durée, les options et le montant dû. Les moyens de paiement disponibles sont ceux renvoyés par la passerelle au moment de la commande.

Voir tous les tarifs

Six emplacements réellement disponibles

Les emplacements ne sont pas de simples points sur une carte. Les deux configurations sont disponibles dans les six emplacements physiques ci-dessous ; la disponibilité réelle est indiquée en temps réel dans la console.

La distance géographique ne garantit pas une latence donnée. Pour le développement interactif, tout dépend de la connexion entre vous et l’emplacement ; pour les builds automatisés, compte aussi la localisation du dépôt de code, des sources de dépendances et du destinataire des artefacts.

Choisir un emplacement et commander
Six emplacements physiques

Choisissez un emplacement adapté aux horaires de l’équipe

Commencez par les lieux de travail principaux de l’équipe, puis vérifiez la qualité réelle de la connexion. Les fuseaux horaires ci-dessous facilitent la coordination et la planification des builds ; ils ne garantissent pas la latence réseau.

Singapour

Pour les équipes d’Asie du Sud-Est. Regroupez le développement interactif en journée et les archivages automatisés la nuit dans un environnement commun, afin de limiter les écarts entre configuration locale et CI.

Fuseau horaire
UTC+8

Tokyo

Pour les équipes d’Asie de l’Est. Planifiez les builds nocturnes selon les jours ouvrés locaux et enchaînez archivage, export et téléversement des artefacts avant les tests du lendemain.

Fuseau horaire
UTC+9

Séoul

Pour les équipes d’Asie du Nord-Est. Idéal pour collaborer sur les problèmes liés à Xcode, aux simulateurs et à la signature pendant les mêmes heures de travail.

Fuseau horaire
UTC+9

Hong Kong

Pour les équipes du sud de la Chine et d’Asie du Sud-Est. Pour un usage quotidien en bureau à distance, vérifiez la qualité d’image, la résolution et votre connexion locale avant de choisir un emplacement pour le long terme.

Fuseau horaire
UTC+8

États-Unis, côte Est

Pour les équipes de la côte Est nord-américaine et d’Europe occidentale. Lors des transferts entre régions, indiquez clairement le fuseau horaire des déclenchements de build pour éviter les décalages liés au changement d’heure.

Fuseau horaire de coordination
UTC−5 / −4

États-Unis, côte Ouest

Pour les équipes de la côte Ouest nord-américaine. Faites coïncider le développement à distance et l’astreinte release avec les horaires locaux ; les équipes réparties entre continents doivent convenir à l’avance de l’emplacement des logs et des artefacts à transférer.

Fuseau horaire de coordination
UTC−8 / −7

Les fuseaux horaires des États-Unis varient selon l’heure standard et l’heure d’été. Pour les tâches automatisées, indiquez explicitement le fuseau horaire. Le nom d’hôte, le port et les identifiants de connexion sont communiqués dans la console. Le choix d’un emplacement ne remplace pas un test réel de votre connexion.

Du point de vue des utilisateurs

Un bureau de moins, un emplacement facile à transmettre

Ce qui compte pour l’équipe, ce n’est pas l’endroit où se trouve la machine, mais la possibilité de retrouver un environnement familier au prochain build.

« Depuis notre passage à OSXBuild, nous n’avons plus à trouver un bureau pour la machine de build. »

Responsable ingénierie

« L’emplacement de Hong Kong est proche de chez nous ; Xcode est très fluide en bureau à distance. »

Développeur iOS indépendant

L’expérience en bureau à distance dépend de votre réseau local, de la distance jusqu’à l’emplacement et des réglages de qualité d’image. Avant de migrer, testez votre connexion, le téléchargement des dépendances et un archivage complet avec votre propre projet, puis choisissez la durée de location.

Pour qui, et dans quelles limites

Confiez les tâches reproductibles à une machine dédiée

Nous fournissons un environnement de calcul, pas la configuration de votre projet. Votre équipe reste responsable de la gestion du code source, des versions de dépendances, des droits de signature et des sauvegardes des artefacts.

Développeurs iOS / macOS

Vous avez besoin d’une interface graphique macOS et de la ligne de commande pour utiliser Xcode à distance, lancer des simulateurs, archiver et exporter des applications. Pour des builds légers, commencez par tester M4 / 16GB / 256GB.

Pour votre première migration, alignez les versions de Xcode et les fichiers de verrouillage des dépendances, puis effectuez un build propre avant de rétablir progressivement les caches. Ne prenez pas un chemin qui fonctionne par hasard sur votre machine pour une configuration d’équipe.

Voir les étapes de connexion et de migration

Équipes CI/CD

Vous avez besoin d’un runner dédié, de caches de dépendances persistants et d’un processus de signature maîtrisé. Intégrez votre GitHub Actions, GitLab Runner ou Jenkins existant et transmettez les artefacts archivés selon vos règles.

Établissez d’abord une référence pour une tâche unique : durée d’archivage, espace disque et ressources de test. Augmentez ensuite la concurrence. Un build réussi ne signifie pas que la distribution est terminée : l’export, le téléversement et la vérification par le groupe de test doivent aussi faire partie du pipeline.

Choisir une configuration selon le volume de builds

Utilisateurs d’IA sur Apple Silicon

Vous avez besoin d’un environnement Apple Silicon réel pour utiliser MLX ou llama.cpp et vérifier le chargement des modèles, l’inférence et la compatibilité des outils. M4 Pro / 64GB / 2TB constitue un point de départ pour les besoins en mémoire plus importants.

L’exécution d’un modèle dépend de la taille de ses poids, de la quantification, de la longueur du contexte et de la surcharge du runtime. Testez d’abord vos modèles et vos données, puis décidez s’il faut augmenter le nombre de machines.

Parlez-nous de vos besoins de test

Transférez vos artefacts avant la fin de la location

Sauvegardez votre code source, vos scripts, vos IPA, vos logs et tous les fichiers à conserver dans un emplacement que vous gérez. À la fin de la location, la procédure de remise en service comprend l’effacement sécurisé du disque et la réinstallation du système. Ne gardez pas le disque de la machine comme seule copie. Consultez vos renouvellements, commandes et factures dans la console. En cas de problème, connectez-vous pour ouvrir un ticket ou écrivez à support@osxbuild.com.

Votre prochain build, dans le cloud

Choisissez un modèle, une durée et un emplacement, puis vérifiez qu’un archivage complet fonctionne avec votre projet. Pour une migration ou des builds en volume, indiquez-nous votre charge et les versions de votre chaîne d’outils.