Faut-il toujours tuer les daemons Gradle en co-hébergement ?

Pas toujours; mais ./gradlew --stop ou eviction idle en fin de pipeline sur baux courts.

Quand séparer sur deux machines ?

Séparer si les rétros échouent ou la compliance impose la séparation des signatures.

2026 Flutter / React Native sur Mac distants dédiés (six régions) : cohabitation iOS+Android, plafonds de parallélisme et FinOps jour→mois

Si Flutter ou React Native sur des Mac distants dédiés en Singapour, Japon, Corée, Hong Kong, US Est/Ouest n’est instable que lorsque les deux plateformes tournent, la cause est souvent mémoire unifiée, amplification SSD et politique de daemons Gradle, pas le nombre de cœurs. Liste de douleurs, matrice, runbook, métriques et liens vers articles publics.

Six conflits de ressources quand Flutter / React Native cohabitent sur un Mac distant dédié (six régions)

Mémoire unifiée saturée avant le CPU : Xcode et Gradle ouvrent de larges arbres de processus ; sur Apple Silicon la pression mémoire apparaît d’abord via Signal 9 ou des arrêts Gradle en phase de transform.
Simulateurs iOS et émulateurs Android : images résiduelles ; exécuter les deux augmente la profondeur de file I/O.
Daemons Gradle et indexation Xcode : sans plafonds RAM et eviction idle, collision avec DerivedData et caches SwiftPM.
NDK/CMake et dépendances iOS : si Git et miroirs Maven ne sont pas colocalisés avec la région du nœud, le mur du temps part sur la résolution.
Fenêtres de location vs files : nightly Android + archive iOS dans un bail journalier force un sprint de nettoyage le dernier jour.
HOME partagé : .gradle, .pub-cache, node_modules mélangés cassent audit et reproductibilité.

Lire avec capacité Simulator, runners self-hosted et CI hybride ; cet article cible la collision des chaînes Android et Apple.

Trois budgets : pression mémoire/swap, marge SSD, egress transrégional. Dans un bail court, sérialiser avant d’acheter des GHz.

Scénario	M4 16Go	M4 Pro	Rouge
CLI seulement	Gradle workers 2, Xcode sérialisé	workers 3–4	swap qui monte, <10Go libre
Flutter integration + Simulator	Android unit puis iOS UI, pas de daemons saturés	`flutter drive` plafonné	Metal+Java fige SSH
RN release + archive	fenêtres temporelles, `./gradlew --stop` avant archive	`GRADLE_USER_HOME` séparé	codesign+zipalign I/O

info

Principe : la cohabitation lie souvent mémoire unifiée et SSD, pas les cœurs.

Runbook en six étapes

Matrice d’outillage versionnée + hash en entrée CI.
GRADLE_USER_HOME/PUB_CACHE sur volume de données ; aligner DerivedData reproductible.
Sérialisation inter-plateforme par défaut.
Ordre d’arrêt : daemon → android/.cxx → rotation DerivedData → git.
Aligner Git/Maven avec la région ; matrice de proximité.
Revue hebdo : RSS max, Go libre min, egress.

bash

./gradlew --stop || true
export GRADLE_USER_HOME="$WORK_ROOT/.gradle-isolation"
export ANDROID_SDK_ROOT="$WORK_ROOT/android-sdk"
defaults write com.apple.dt.Xcode IDECustomDerivedDataLocation -string "$WORK_ROOT/DerivedData"
export FLUTTER_ANALYZER_CONCURRENCY=2
export ORG_GRADLE_PROJECT_org.gradle.workers.max=2

Trois métriques indicatives

RSS >~78% mémoire unifiée → sérialiser ; >~88% avec swap → pas de tests UI parallèles.
Trois builds d’affilée <12Go libres sur 256Go → tiering ou montée de bail.
Misses cache Gradle config + resolve CocoaPods +30% semaine → corruption HOME partagé.

Linux dédié Android vs double build local

Linux découple la RAM mais duplique files et secrets. Le local réintroduit la dérive.

Pour des nœuds Singapour, Japon, Corée, Hong Kong, US Est/Ouest avec chemins chauds alignés, MACCOME (M4/M4 Pro, baux flexibles) aide à budgétiser mémoire/disque avant de pousser la parallélisation de compilation.

Trois livrables

Table outillage, matrice co-hébergement/split, carte nettoyage ↔ bail ; frontière avec FinOps monorepo.

Quand ne pas lire

Si Android n’utilise jamais le Mac, retour runners. Avec egress, journaliser NDK/Engine dans le même registre.