Is there any documentation on what shell syntax this supports? I assume it's not running a standard shell like Bash or zsh.
Edit: https://github.com/holzschu/ios_system/blob/master/README.md confirms its not running sh, bash, or zsh, and has some additional details on the available commands. I still think it would be nice for this to be more explicit, but the information is out there.
You can sign it with a free developer account, but I believe that you have to re-sign every 7 days as opposed to every year with a paid developer account.
You could check out Pythonista, Codea, Javascript Anywhere, TechBASIC, DraftCode (for PHP) and Continuous (C# and F#). Those are all coding apps so you can program directly on the device. Several of them also enable packaging the programs you create for distribution on the App Store. Several of them also have built-in GUI authoring tools although I generally prefer to build my GUIs in code.
Working Copy is an excellent GIT client and works well with many of the above and there are plenty of coding editors. There are also a plethora of non-programming creativity apps, many of which are useful for coding projects.
This was fun to try as a little preview of what it’ll feel like to have an ARM-based MacBook.
Bummer there’s no git¹.
I was curious to try to install Go just to see how far I’d get before being blocked. Was able to download the source tarball and extract it (using curl and tar as 2 separate commands; piping curl into tar didn’t work). But then can’t execute make.bash because there’s no bash.
You can try ish.app [1], which has support for a wide variety of tools (including git). I use it on iPad to work on a small C app that I use a lot. [2]
If you really want an ARM64 based development platform, why not get a Pinebook? Or something like the NVIDIA Jetson Nano? The philosophy of Apple is to link against their officially provided frameworks/SDKs. It's not meant to be a platform for open development.
Issues: In iOS, you cannot write in the ~ directory, only in ~/Documents/, ~/Library/ and ~/tmp. Most Unix programs assume the configuration files are in $HOME. So either you redefine $HOME to ~/Documents/ or you set configuration variables (using setenv) to some other place. This is done in the initializeEnvironment() function.
To my knowledge, the reason no “real” terminal exists for iOS is because it violates the App Store rules. It is prohibited to download and execute arbitrary code, with a few exceptions.
One exception is JavaScript, which must be run inside of JavaScript Core [1]. What if someone simulated x86 and Linux _in JavaScript_ and then built a terminal and file system on top of it? Would that be in accordance with the App Store rules (since it would be sandboxed in Apple’s JS core)? Would it even be technically feasible? Or too slow for any serious usage?
[1] from the App Store rules:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; (4) does not provide access to real money gaming, lotteries, or charitable donations; (5) adheres to the terms of these App Review Guidelines (e.g. does not include objectionable content); and (6) does not offer digital goods or services for sale. Upon request, you must provide an index of software and metadata available in your app. It must include Apple Developer Program Team IDs for the providers of the software along with a URL which App Review can use to confirm that the software complies with the requirements above.
It is not necessary to resort to JavaScript for the emulation, emulation and interpretation are allowed. App Store effectively forbids the usage of JIT (so VMs do not run as fast as one could expect) and running any code that’s not included in the package at the time you submit the app for review (with an exception for educational apps).
I’m not doubting you, but I don’t see where in the App Store rules it forbids JIT, other than the prohibition of running third-party code. Emulation and interpretation are allowed — if the code is first- or second- party.
Educational apps are an interesting exception, but as I quoted in my patent comment, JavaScript is the other major one.
So I wonder if JIT compilation and execution is possible under the rules in JavaScript? (Again, is that even feasible?)
Generally, JIT requires the ability to execute data (writeable memory pages that contain code). iOS apps need a special system permission (in Apple's terminology — entitlement) to construct such pages. To my knowledge, no apps except for the first-party ones (like Safari) have this permission.
Apps can call into one system API that has this JIT capacity (WKWebView). It runs in a separate process and uses IPC to communicate with the app. It has an API that allows the application to execute arbitrary JS code at full speed. Some time ago it lacked support for WebAssembly, but it may have been resolved by now.
So, these are the technical limitations of the platform. Apple chose to implement a number of arbitrary rules on top of that. Well, it's not a democracy, and they are free to do so. There is always a slight chance of having some form of less restricted execution environment in future versions of iOS, mainly due to how much their iPad Pro hardware is overpowered relative to the OS capabilities.
This was also discussed here a few months ago by the author of utmapp (Qemu on iOS). In order to get their code to work, they need to effectively run their own code in debugging mode. And yes, this requires the same entitlement as the JS JIT.
I was considering using lib-tex (the library implementing texlive 2019 for this shell) last week for an iOS app I’m working on that needs to generate basic LaTeX images. It’s really impressive, these programs running in A-Shell are modified by renaming their `main()` function and making sure global/static variables are cleaned up so they can run as a separate thread in-process instead of spawning a separate process. I decided to use the more limited KaTeX instead because it sounds like a maintenance nightmare, making sure nothing leaks and updating everything every time a new version comes out...
I wonder if that process can be automated to a point where you could “lib-ize” any C/C++ project (sed replacing malloc/free with something that cleans up when the process “exits”, replacing exit/fork/etc, replacing static). I think that would really open up the number of interpreters available on iOS.
Is there any way I could use a USB C to DB9 console cable on an iPad Pro with this? I’m thinking this could be a great setup for working in the cramped data center.
Lua is rather tiny. JavaScript and the executor for C/C++ (as the compiler compiles to WASM) are mostly Apple frameworks (JavaScript Core). Now Python and Clang are fairly big, but not usually 650mb big, I’d say 200mb is more likely. Now if TeX was included, totally agree, but as sibling comment indicated, it’s not.
> clang/clang++ compiles your C/C++ files to webAssembly with wasi included. Executee the resulting files using 'wasm command'. You can also compile to webAssembly elsewhere and bring the files to your iPad.
I jailbreak several iOS devices just to have terminal many years ago, and it was quite an interesting experience. I always hope Apple could let user access terminal in iOS, at least in developer mode. After all, it's still BSD based just like MacOS, and iPad Pro is so powerful but nowhere to go for a programmer.
Sadly, it seems Apple doesn't really care about this.
No, Codea is a full featured Lua IDE for iOS, and there are lots of other programming environments too. What they prohibit is compilation to native code. If you have an interpreter (like lli, in this case), that’s fine.
Wow, that was a few years back - I'm glad to learn about this change. Quoting (and reformatting for better understanding) below..
---
On June 5th of this year [2017], the Apple Developer Program License Agreement (which applies to both the iOS and Mac App Stores) was revised to:
3.3.2 ..Interpreted code may be downloaded to an Application but only so long as such code:
(a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store,
(b) does not create a store or storefront for other code or applications, and
(c) does not bypass signing, sandbox, or other security features of the OS.
---
An Application that is a programming environment intended for use in learning how to program may download and run executable code so long as the following requirements are met:
(i) no more than 80 percent of the Application’s viewing area or screen may be taken over with executable code, except as otherwise permitted in the Documentation,
(ii) the Application must present a reasonably conspicuous indicator to the user within the Application to indicate that the user is in a programming environment,
(iii) the Application must not create a store or storefront for other code or applications, and
(iv) the source code provided by the Application must be completely viewable and editable by the user (e.g., no pre-compiled libraries or frameworks may be included with the code downloaded).
Just this morning I realized I had a need for a decent SSH client for iOS, although I don't need something that includes vim, clang, and Lua, Python, and C, though.
That's extreme overkill for my needs -- I'd just like the ability to log in to a few hosts (preferably using public key authentication!) and run various commands just like I normally do in a terminal.
If anyone has any "favorites" they recommend, I'd be interested in hearing about them. I'd prefer something open-source (out of principle) but I'm certainly not opposed to paying a reasonable amount.
It's definitely steep, but if you are doing serious work in the shell on iOS, it's worth it IMHO. I was traveling by motorcycle for 6 months and did all my dev work on an iPad using emacs over mosh on Blink, and it was a great experience.
I'm glad it isn't, that would effectively price me out. The current price point is quite steep just for being able to check on my private server on the go (I don't earn a penny from it, it's just for fun and toying around), a subscription would be a dealbreaker. A dozen apps for the price of a coffee a month ends up being real money over the long run, and not everyone who buys this sort of thing has company money to spend.
I built it from source to see if it was what I needed and it so scratched my itch that I paid the $20 as a contribution.
I don't do any professional development on my iPad, I just like having the ability to mosh/ssh back into my machines at home to run a script or push a quick edit to my personal github.
Isn't this more like a sandbox that lets you play in the sandbox with a CLI? I don’t think it actually gives you shell access to your iOS device, just a shell interface to its own program (and the other commands it supports).
Prompt, by Panic Software, the authors of Transmit and Coda. They even managed to get rid of disconnections while in the background, admittedly in a hacky way using location services.
This is a completely undiscoverable feature. It isn’t mentioned anywhere I saw and isn’t part of the normal config screen. I’m happy it’s there, but now I’m curious what else I was missing...
accurate and performant rendering (we use reacts), external display support (mirror and standalone shell), KeyCast (display pressed keys, useful for screencasts and live streaming), bundled beautiful fonts (Pragmata, Iosevka, Fira Code), full width row of additional keys on software kb (cmd is there too for cmd-c/v/w/t etc), smooth scrolling (in tmux/vim/emacs too), trackpad support (within tmux panels/vim/emacs too), links detection in selection, selection manipulation via kb (vim, emacs and arrows mode), accessibility (voice over), dictation input and IME support, port forwarding and proxy command support, images view and persistent mosh connections (you can reboot device and get connection back)
Another vote for Blink. I’ve used it for over a year with very few issues. They consistently push out bug fixes and add well thought out features. It’s a joy.
This is very cool, over the years I've been using different apps - iSSH back in 2010/2011 and Terminus lately - to connect to servers over ssh/mosh but having a local working terminal would be great. Is there any way this can update Apple Notes?
And
> "A text-based user interface for a screen-based platform"
Is that a play on "Limitless paper in paperless world" from a Dunder-Mifflin ad?[0]
Seems like there's pent up demand for more hacker stuff on mobile! :) I wonder what this could mean for the direction of the mobile paradigm (move towards fewer walled gardens like app stores please?)
I haven't used either this or the one in the original submission. What differences stand out the most to you? I'll be trying both out later tonight, but I'm curious to know your thoughts.
I just downloaded a-shell so still playing with it.
What I love about Blink is that it supports mosh and it includes tunnels, ssh-agent etc. out of the box (no need to install anything). It seems very well polished for the purpose of remote work. I have a mosh session open with our deep learning server in the lab 24h (works with network outage etc.).
I assume you can setup the same on A-Shell. Will play with it and update here.
If you only need it on occasion or for emergencies, there's a lot of cheaper options. If you're using it on a daily basis for development work, $20 is a steal! I'd gladly pay $100 for Blink! It's one of the most polished and functional apps on my iPad.
Registering for an account is free. you can get a signing key for testing (i.e. to build and run on your own device) for free also. You only need to pay if you want to publish to the App Store.
I can see that this tool in turn leverages ios_system, but neither A-shell nor the ios_system github repository appear to present an exhaustive list of the available commands. This seems like an obvious first step in improving documentation.
What iOS really needs to make this useful though is a way to project to a proper screen and keyboard/mouse configuration. Like Samsung DeX. Kinda hoping this will happen as they are making the iPad Pros more like a computer.
It doesn't. It _interprets_ x86. There's a similar project to do this for RISC-V, but it's not on TestFlight. I assume this pick the LLVM IR? It's an interesting question what the optimal IR for this would be, but it would probably be higher level than this, maybe more like WASM or the Zinc (O'Caml IR).
I can't parse this, but the facts remain that the only JIT Apple allow is their own. Any other app cannot generate and run native code at runtime. Thus, apps are interpreting the immediate form (for iSH that 32-bit x86 and for A-Shell it's LLVM IR).
iSH is threading, that is, the x86 code is translated into an IR consisting of pointers to the code that executes its interpretation. This is a technique older than FORTH and which may be the best you can do on iOS currently. A-Shell may do the same, I don't know.
Is there any documentation on what shell syntax this supports? I assume it's not running a standard shell like Bash or zsh.
Edit: https://github.com/holzschu/ios_system/blob/master/README.md confirms its not running sh, bash, or zsh, and has some additional details on the available commands. I still think it would be nice for this to be more explicit, but the information is out there.