iSH installe une véritable ligne de commande Linux sur iPhone ou iPad, sans jailbreak. C’est gratuit, c’est sur l’App Store, et ce n’est pas une session distante : le shell, le système de fichiers et les paquets résident sur l’appareil.
Comment cela fonctionne vraiment
iSH n’est ni une machine virtuelle ni un portage natif. Il exécute un environnement Alpine Linux grâce à une émulation x86 en mode utilisateur couplée à une traduction des appels système : de vrais binaires Linux x86 sont interprétés instruction par instruction, et les appels système qu’ils émettent sont traduits en quelque chose qu’iOS accepte.
Cette conception explique à la fois pourquoi iSH est si compatible et pourquoi il est lent. L’interpréteur du projet utilise du threaded code — un tableau de pointeurs de fonctions plutôt qu’un simple switch — ce qui lui apporte environ 3 à 5 fois plus de vitesse que l’approche naïve, mais vous payez toujours un péage d’émulation à chaque instruction. Voyez-le comme un endroit où lancer des scripts et de petits outils, pas où compiler un gros projet.
Une conséquence surprend souvent : l’émulateur étant x86, les binaires ARM que vous auriez copiés depuis un Raspberry Pi ou un Mac Apple Silicon ne fonctionneront pas. Tout doit venir des dépôts x86 d’Alpine.
Installation et les cinq premières minutes
Installez iSH Shell depuis l’App Store. Le téléchargement est léger — environ 6 Mo — car le système de fichiers racine d’Alpine est récupéré et décompressé au premier lancement. Un canal bêta TestFlight existe aussi pour qui veut des versions avant leur publication sur la boutique.
La première chose utile est de rafraîchir l’index des paquets :
apk update
Une idée reçue tenace veut qu’iSH « prenne en charge Bash, Zsh et Fish ». Ce qui est livré, c’est BusyBox ash, le shell par défaut d’Alpine. Bash, Zsh et Fish sont tous disponibles, mais c’est à vous de les installer :
apk add bash git python3 nano openssh
Gestion des paquets : apk, pas apt
Si vos habitudes Linux viennent de Debian ou d’Ubuntu, la mémoire musculaire va vous jouer des tours. Ici, pas d’apt-get. Alpine utilise apk :
apk add <paquet> pour installer, apk del <paquet> pour supprimer, apk search <terme> pour chercher et apk upgrade pour tout mettre à jour.
Alpine est bâti sur musl libc plutôt que sur glibc. La plupart des logiciels en ligne de commande s’en moquent, mais tel binaire ou telle roue Python qui présuppose glibc refusera de fonctionner. C’est une limite d’Alpine, pas d’iSH.
Le git clone qui se bloque — et le correctif
Le problème le plus signalé, de loin : git clone se fige sur resolving deltas 0% et n’avance plus. Ce n’est pas une panne réseau mais un souci de threads sous émulation. Forcez git à travailler sur un seul thread :
git config --global pack.threads "1"
Le clonage ira alors jusqu’au bout, lentement sur un gros dépôt. À noter : cela règle le clonage, pas tout ce qui vient ensuite. Les chaînes d’outils qui lancent de nombreux threads ou attendent une glibc complète — les compilations Go en sont l’exemple classique — peuvent encore échouer une fois le checkout réussi.
Les limites à connaître avant d’en dépendre
iOS suspend les applications en arrière-plan. Quittez iSH pendant une tâche longue et le système finira par la geler ou récupérer sa mémoire. Le wiki du projet documente un contournement qui maintient l’application en vie via le mode de localisation en arrière-plan, en lisant /dev/location vers /dev/null. Cela marche, mais cela consomme de la batterie et reste un bricolage, pas une fonctionnalité prise en charge.
Il n’y a pas de JIT. Apple n’accorde pas aux applications de l’App Store l’autorisation qui permettrait à iSH de compiler du code à l’exécution, ce qui plafonne la vitesse que l’émulateur pourra jamais atteindre.
Vous êtes dans le bac à sable de l’application. iSH ne peut pas toucher au reste d’iOS. Il s’intègre à l’app Fichiers, vous pouvez donc faire entrer et sortir des données ; mais « accès au niveau système sur iOS », non — cette formule traîne dans beaucoup d’articles et elle est fausse.
iSH ou a-Shell ?
Ce sont les deux choix réalistes, et ils sont opposés.
a-Shell livre des binaires natifs compilés pour iOS. C’est rapide et économe en batterie, mais ce n’est pas une distribution Linux : pas d’apk, pas d’apt, aucun gestionnaire de paquets, et aucune intention d’en ajouter un. Vous avez ce que le mainteneur a empaqueté.
iSH est un véritable système Alpine, avec des milliers de paquets installables, et il le paie en surcoût d’émulation.
Prenez a-Shell si la vitesse compte plus que le choix des paquets. Prenez iSH s’il vous faut réellement une distribution Linux et que vous acceptez la lenteur. Et pour clore une question récurrente : Termux n’a jamais été porté sur iOS. Tout ce qui se présente sur l’App Store comme « Termux pour iPhone » n’est pas le projet Android.
Où en est le projet en 2026
Soyons lucides. La version de l’App Store est la 1.3.2, publiée en mai 2023 : plus de trois ans sans nouvelle publication sur la boutique. La fiche conserve 4,7 sur 5 pour environ 1 200 évaluations, et l’application tourne à partir d’iOS 11.
Le dépôt raconte une histoire plus vivante : plus de 20 000 étoiles, plus de 4 000 commits et environ 660 tickets ouverts. Le développement ne s’est pas arrêté, mais le flux de versions finalisées vers l’App Store, si — et le nombre de tickets ouverts est un signal honnête des aspérités que vous rencontrerez.
Alors, faut-il l’installer ?
Oui, à condition d’ajuster ses attentes. Comme environnement Unix de poche — écrire et lancer des scripts shell, éditer des fichiers avec vim ou nano, un peu de Python rapide, du SSH vers un vrai serveur, des opérations git, retoucher un fichier texte à deux heures du matin faute d’ordinateur — il fait le travail, et rien d’autre sur iOS ne le fait aussi complètement.
Comme machine de développement, il vous agacera. La compilation est lente, les tâches longues meurent dès que l’application passe en arrière-plan, et certains paquets refusent simplement de coopérer. Notre verdict précédent sur cette page disait qu’iSH « avait besoin de beaucoup plus de travail » ; trois ans après, cela reste vrai — à la différence près que nous pouvons désormais dire précisément où se situe la friction, au lieu d’en rester à une impression.