Does anyone else wish they could do real coding on an iPad, Unix style? That would be so awesome; the new iPad Pro’s especially are fantastic pieces of hardware, and it’s a shame that although you can be productive via word processing, media editing, etc on them, coding is not really viable.
I’ll have to read more about iSH to learn if it’s a “true” shell, or effectively just emulated or with strict limitations, but either way the potential inspires of how great it would be to have a true shell and/or dev tools for iPads.
I've been thinking a lot about this and decided to try. I just got set up to remote code on my laptop via mosh+nvim (connecting to my MacBook Pro when it is at home). I'm using terminus as a terminal which has a very good free offering. I'm pairing my apple magic keyboard 2 which works as well as you'd expect.
Oh and I did this on my iPhone X because I am still undecided on the new iPad. There doesn't seem to be any issue at all, despite the small fonts. The screen is actually large and hi-res enough that it's workable. I can have a NERDTree and a wide buffer with no wrapping, or 2 buffers side by side with a tiny bit of wrapping. Obviously an iPad would totally solve that.
I want this to work for a few different reasons.
1. Be able to do the occasional odd task or put out a fire on the go. On vacation probably, when I am not planning on doing work and leaving my laptop home.
2. Have a consistent development environment which I can reach from anywhere on any device, and pick up right where I left off. (So far tmux sessions have been an awesome lightweight solution for this)
3. Taking it a step further, perhaps leverage a server in the cloud which I can spin up/down as needed, and customized for low cost or stupid power.
4. Rely less on the mouse
5. Divorce myself from IntelliJ. While while awesome, is pricey and bloated, and abstracts away a lot of cool command line tricks behind the GUI.
So far my personal challenge is just getting used to vim + tmux. I've been using IntelliJ mostly for the last few years but have a bit of experience with vim and tmux to get started.
The next hurdle will probably be figuring out how to get a workflow set up that involves a browser loading the code. I expect lots of annoyances around outputting something on the remote machine which I then want to view on the iOS device, like an image or CSV. Working around the lack of a real local file system is going to be like pulling assets out of another dimension.
After coding for getting close to four decades, you can pry my IDEs (like JetBrains's IntelliJ) out of my cold, dead hands. And I wrote huge bodies of code in the original vi back in pre-Linux (and early Linux) days and still use it daily.
I've begun working on doing a setup like this as well. I am in the process of setting up a development environment on Digital Ocean (least powered is fine for me), using blink on iOS for its mosh support.
I was going to go the vim+tmux route, but I never got into tmux and I happened across Modern Vim by Drew Neil. The book describes how to use nvim's terminal emulator mode and the ability to save sessions. I am hoping this will allow me to just use nvim for coding instead of nvim+tmux.
I also intend to have a build flow that pipes it into a server for easy downloading and, if need be, uploading.
While I have the first gen iPadPro (works fine for this, of course), it did occur to me how amusing/stupid it is to think of using one of the most advanced consumer mobile devices as a dumb terminal like it was the 1970s.
I use mosh via the Blink client and the Logitech keyboard on my '17 iPad Pro and do a lot of coding on it on remote servers. The lack of an escape key sucks and I had to figure out how to do code folding in vim but it's pretty serviceable.
Of course I still prefer giant monitors to fit a lot of different panes for inspection and debugging, but it's pretty serviceable.
I agree 100% about big monitors and keyboards for chair-and-desk situations. In fact, I’ll take this opportunity to remind everyone that we now have incredible 42” IPS 4K monitors, like this one by Dell:
For portable use though, I think an iPad could very well be superior to modern laptops. The hardware of Apple’s iPad Pro is certainly well beyond that of ultraportable laptops on the market now. The only missing piece is the software.
In particular with Blink, the app will actually recognize the monitor as a second screen, and use it at full resolution (as opposed to mirroring the normal iPad screen). With tmux, this means you can arrange as many horizontal and vertical splits as you can fit onto the monitor.
> You can plug an iPad into a giant external monitor using the lightning to HDMI cable
Or, on newer iPads, directly via the USB C connector. And apps can recognize that you have chosen to plug in a secondary display and suit their content to match on the other screen.
I think what we need is a port of Qemu. If you've ever used JSLinux[0] on an iPad, you know that it's plenty powerful to emulate riscv64 or x86 fast enough (even in JavaScript), so if there would be a proper PC emulation layer on an iPad you could run anything (Linux, *BSD, GNU/Hurd, NT, even full macOS).
Actually a good enough port of TinyEMU/RISC-V allowing for network communication and persistent storage would probably make the iPad interesting for me. Would Apple allow such a thing on the App Store? It would still have to be open source of course.
Fedora/RISC-V is dangerously close to being useful; the only apps I miss are a couple of the big hurdles: Firefox, GHC, and Java.
iSH is a binary emulator that ships with an almost-Linux-compatible-ish subset "library operating system" that is good enough to make a bunch of common command line apps work. So like, this little operating system has a minimal ELF loader in it, and then runs the executable in its little emulated jail.
I don’t see anything about emulators in the App Store Review Guidelines, so I’d be interested in seeing anything that Apple has cited when they reject such software from the App Store. To my knowledge, this software follows Apple’s guidelines.
What I haven't seen mentioned yet is the fact that there is no way to run a browser/javascript debugger on ios. You can do it remotely, but not locally. This is the missing link for me in terms of using an ipad for serious dev work.
Only if Appple came out with a clamshell designed iOS device. I have a third party keyboard attached and I feel it makes my iPad so much more comfortable in a wide variety of positions to work on. Even when I'm not using the keyboard much.
Fair enough, it's close. But I still wouldn't do it. It would be like a carpenter bringing a screwdriver with a metal handle so he doesn't also have to bring a hammer.
I care about the tools I use to do the work I do and I don't want to compromise (or compromise very little). I don't think I can get serious work done on an iPad without faking it and saying, "um, sure, it's great!", and without honestly feeling claustrophobic.
Big and powerful dev setups are great, but that’s what my 42” 4K Dell monitor is for — and there’s no way that’s going to be portable.
So the reality is that there’s no such thing a no-compromise dev setup: Either you optimize for a desktop setup, or for portability, or somewhere in between. If you have the ability to have both a desktop and portable setup, such a pair I almost always going to be superior to just one medium sized laptop: Your desktop experience will be better with massive high resolution monitors, and your mobile experience will be better with a lighter, slimmer device and longer battery life etc.
I absolutely prefer to have a larger external screen, too. But if I'm traveling, and the choice is between my 13 inch Macbook Pro, or the 12.9 inch iPad Pro, I usually choose the iPad. With Blink in full screen, it's basically the same as iTerm on the Macbook, but much more portable (and I can do things on the iPad I can't do on the Laptop: Apple Pencil & Goodnotes)
This is an obvious approach that absolutely has been done before (though maybe not as efficiently), but is not App Store complaint (as you can use this to download new functionality that the app did not ship with that is then executed on the device using a virtual machine that is not JavaScriptCore) and so is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected). This really isn't that interesting (to some very real extent, "sadly": it sucks that Apple is allowed to say these kinds of apps can't exist).
> is not App Store complaint (as you can use this to download new functionality that the app did not ship with that is then executed on the device using a virtual machine that is not JavaScriptCore)
Apple has recently added an exception to this rule if you’re willing to classify your app as an “educational” app, and allow for the viewing and editing of the source code you download. Since this shell allows for grabbing a copy of the source code of the packages you install, and compiling them yourself, I think it just barely falls within the rules:
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
> is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected)
There is no exemption for TestFlight apps; they should comply with the App Store Review Guidelines as usual:
> Any app submitted for beta distribution via TestFlight should be intended for public distribution and should comply with the App Review Guidelines.
Note that any builds that go through TestFlight are subject to a review process.
But I can use this to download things that are not open source... I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China)... hell: I can use this to download other (even less efficient) emulators for other architectures. I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist.
I mean: this is a great implementation of an emulator. I have downloaded and tried iSH, and it is actually "kind of epic". This isn't exactly what I thought it would be, glancing at the source code: it sounded like it would be running the Linux kernel (so actually be Linux) in console mode, but this is a library operating system and is very similar in many ways to the project I sometimes talk about (which also provided a library operating system, but was going to distribute pre-compiled code as part of the application to avoid needing an emulator), but this is clearly better as an emulator (and is much easier to do, despite this emulator being a slightly harder emulator to build than most).
So, this is a great implementation of this--this is even a "heroic" implementation of this--but, at the end of the day, this is the thing Apple was trying to stop (as much as I hate Apple for that).
> But I can use this to download things that are not open source.
Ok, let's widen our view of open source then. Pythonista lets you download Python code and then it interprets it, and iSH lets you download compiled x86 code and then interprets that. So it's still open source, see!
> I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China)
I'm not following you. How would iSH be able to actually apply these proxies system-wide unless it's a VPN app, which as far as I'm aware it's not? All it can do is possibly download VPN profiles, but I can do that in Safari too. Perhaps I'm misunderstanding how SOCKS works, but I don't see how this could change anything except traffic you're sending in-app at the most.
> I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist.
You're going to have to provide evidence for that–Apple used to do this by citing 2.5.2 in their App Store Review Guidelines, which explicitly forbid this kind of thing, but as I mentioned there is now an exception poked in it for "educational use". Has any "educational" (i.e. non-piracy) emulator recently been rejected by Apple, and if so, under what grounds?
> at the end of the day, this is the thing Apple was trying to stop
Again, I disagree that Apple would try to stop this, at least under the current set of rules that they have. The fact that it made it through TestFlight review is pretty telling, I think.
You do not have to sign your development tools on your desktop machine to get them to install. To have a semi-usable situation, i.e. one where you’re not forced to reinstall your tools every week, you need to pay a non-negligible amount to Apple regularly so that you can sign and run this software. Porting Homebrew would never work, at least in it’s current state, not the least because it seems to be designed around everything going in /usr/local and breaking violently if you don’t stick everything in there and forcefully chmod/chown it to yourself ;P
Homebrew themselves recommend against installing software anywhere else: https://docs.brew.sh/Installation. It just isn’t built for installing to anywhere else, regardless of the security and usability issues this causes.
No. There have been multiple efforts to do something like this before; I seem to recall one app on the App Store that attempted to simulate commands being run by parsing arguments and performing the correct actions as they were entered. Personally, I have an experimental shell that abuses cross-compiled Mach-O ARM64 shell binaries, but there are some limitations to this approach that I need to resolve regarding codesigning, App Store guidelines, and advanced shell features such as piping which are difficult to emulate in the single process that iOS gives you. I might get around to posting it online if I get the time.
I booted full Linux (Also Windows 95, albeit very very very slowly) on Bochs using the first gen iPad six or seven years ago, so definitely been done. This just seems more polished and user friendly. With the performance of the latest iPad Pro, I’ve been meaning to dust off that code and see what’s possible now.
I AM RUNNING VIM ON MY IPAD BECAUSE OF THIS. THIS IS THE HAPPIEST DAY.
Are there any plans to build some kind of connection between the filesystem here and the native ios filesystem-thingy? It would be delightful to be able to edit something in real vim and then save it to icloud...
I tried out iVim for a few hours. It has vimrc support and integration with the files app. It also integrates with The blink shell app so that you can edit files on remote through vim and ssh
This is so, so close to allow me to run a full local vim (with the necessary external tools, like python and git). The only thing I found that was a dealbreaker was the lack of unicode support (https://github.com/tbodt/ish/issues/28), and not being able to map caps-lock to escape.
For now, Nicolas Holzschuch's fork of iVim (https://github.com/holzschu/iVim) is still by far the best solution, but iSH definitely has the potential to take over.
python3 is breaking my heart. I upgraded my code from py2 to py3, and since then, seems like every 6 months my code will break due to a new python update (I'm on Fedora, fyi). Just last week a bunch of my python3 code stopped working for my IRC bot. I honestly regret switching to python 3 at this point.
I feel like I'm a bit out of the loop here, getting a local shell on an iOS device was one of the immediate benefits from Jailbreaking. It was even a native iOS binary, usually bash or Korn Sell, along with sshd. No need for such an elaborate Linux ABI transposing layer, as the iOS kernel supported enough Unix to run this stuff fine. But even if the iOS SDK/libc has since dropped certain functions or POSIX headers, the kernel undoubtedly still supports it.
If this software could be developed and installed, cross-compiling a native Unix toolchain, either from the open source code distributed by Apple, or the BSDs, or even GNU, should be just as easy to pull off.
The tricky part with an unjailbroken device (for third-party developers) is that apps can’t fork/exec, or any of the equivalents— aside from a couple exceptions around app extensions, the binary that gets run when the user taps the app on the home screen is the only one that ever can be run.
That’s fine for most GUI-driven applications, but it’s kind of problematic for a traditional *nix-style shell. If you were Apple, or you had a jailbroken device and could circumvent the sandbox, you wouldn’t have any problems running a normal shell and command line utilities.
> aside from a couple exceptions around app extensions
Which Apple has cleverly made sure are not under the control of your process. There really is no way to reliably spawn another process and get it to communicate back to your application.
> If you were Apple, or you had a jailbroken device and could circumvent the sandbox, you wouldn’t have any problems running a normal shell and command line utilities.
Apple does in fact have the ability to spawn a shell on internal devices.
Terrible example as most dishwashers don’t run a Unix-like operating system. Spin that example to something running an embedded Linux OS (like my Samsung TV) and the answer is yes (but not in a factory supported way).
But yes-- I certainly do expect to be able to run a shell on any computer that I own. It's nice to hear that iOS devices are just another appliance for the affluent majority.
> But even if the iOS SDK/libc has since dropped certain functions or POSIX headers, the kernel undoubtedly still supports it.
Fun fact: the kernel has continuously been dropping features that are seen as “unnecessary” on iOS. For example, I recently heard that iOS no longer supports setuid at all; the entire feature has been ripped out of the kernel because it’s not used.
Why not use Screens/NoMachine to remote access desktops on iPad Pro? It’s blazing fast on local network, and reasonable via the internet. You could have an on-demand bootable Ubuntu or Windows via Azure quite cheaply.
Port qemu-arm to iOS and run it in syscall emulation mode. You’d then need to implement translations for all the Linux system calls. This would make it quite similar to Windows Subsystem for Linux.
No way Apple will let you put that on the App Store though!
You can JIT compile in the sandbox with certain entitlements that Apple is happy to grant you, as long as you don’t try to put your binary on the App Store.
Sure. If you have an Xcode and an iOS device on hand, make a new project and cast “\x00\x00\x80\x52\xc0\x03\x5f\xd6” (or your own assembly) to an int (*)(), and check to see if the return value is 42 in the debugger.
It is, the entitlement is called “get-task-allow” and is usually used for saying that it’s ok to be attached to in the debugger, but serves a useful double life in making it possible to JIT. Xcode injects this entitlement for you when you create a debug build.
You’re going to have to be more specific; what exactly do you mean by “run Linux on ARM”? Sure, I can compile Linux for ARM and put it in an app, and provided I am careful, I can bootstrap the kernel and get Linux up and running. But what do I do from here? I have Linux “running”, but it no container app around it anymore to allow interaction with iOS. (This is, of course, considering that you have gotten codesigning to work correctly and have full control over when the kernel JITs).
I mean they should have just emulated Linux on an arm processor, seeing as the hardware (Apple A-series) is already arm-based I assume that wouldn't cause as many performance issues as emulating a completely different architecture, x86.
I assume, based on the first comment in this chain - I'm not experienced with emulation of different processor architectures.
Like I said, “emulat[ing] Linux on an arm processor” is not as simple as you make it seem. To do something similar on x86, that is, run Linux on your Intel processor, you need virtualization software that acts as a hypervisor. iOS devices do not provide the capabilities to write software like this, so doing any sort of emulation in this way would not really work.
I believe what the OP is trying to say is, what if this weren't an x86 emulator, but rather just a shim which allows ARM native assembly code to be being run in the context of iOS, only with traps that allow access to a kind of HAL within the context of the App .. meaning that instead of loading up an x86 image containing the Linux kernel and user space, it'd load an ARM-based Linux kernel and does the trapping required to give a native runtime experience .. underneath the iOS layers.
That would be quite feasible and not at all impossible. And given that the original author of this amazing project has the balls required to pull off a JIT-type scheme to do x86-ARM translations, quite probably within their reach.
I don't think it's possible to do something like on iOS, because you can't write to executable pages (IIRC making a page executable requires the "dynamic_codesign" entitlement, which some Apple apps have).
dynamic-codesigning gates MAP_JIT, which is what MobileSafari uses for achieving just in time execution for JavaScript. However, you can still have a “poor man’s” JIT by marking a page as RW, sticking code in there, then marking it as RX, which does not require dynamic-codesigning and can be done by apps not made by Apple.
I think you still need dynamic codesign for this, if I try to do it my app gets killed with "Exception Type: EXC_BAD_ACCESS (SIGKILL - CODESIGNING)", unless it's attached to the debugger. I remember having this issue since at least iOS 6 or 7.
The way iSH works around this limitation with gadgets is very interesting.
Bingo. You need the get-task-allow entitlement (which Xcode will automatically inject in your debug builds, but will not allow you to submit to the App Store with), and have had ptrace called on you–either through the debugger, or if you ptrace yourself with PTRACE_TRACEME.
I have an enterprise account, so could I build my own "emulator" that actually just passes through ARM instructions using this work around ^ and then the only thing I have to emulate is syscalls and io?
There would need to be some sort of emulation later in place at some point, because traps into the kernel would need to be intercepted by the application and this just isn’t possible (at least, to my knowledge) in any application that just straight up runs unmodified native binaries. So it really doesn’t matter whether the author emulates x86 or ARM because there’ll be a performance hit either way.
It works surprisingly well on my old iPad Pro! Thank you for building this. Sure, many tools that require additional privileges (and some syscalls?) do not work, but i’d love to see more progress here. Having a local linux shell on my iPad would be a game changer for me.
I was just thinking about a busybox-like terminal emulator for iOS earlier this weekend that would be App Store compliant. Maybe this will scratch that itch.
And Mach was a modified 4.2BSD kernel adding microkernel aspects. It was literally written as a drop in replacement for BSD.
The kernel also includes code from BSD, source is available, including from FreeBSD/NetBSD and OpenBSD. For example, the network stack is BSD code. It also includes OpenBSD's pf(4).
For example, there was a recent ICMP vulnerability in XNU, that later affected FreeBSD. So please reconsider posting misinformation in the future.
If you look at the comments below, I'm well aware of the repo containing XNU and BSD.
Mach was not a modified BSD kernel, it was a research kernel developed at CMU developed from the Accent and Aleph kernel(s) as a replacement for the BSD kernel, nothing to do with BSD excepting that BSD took some ideas from it... later.
You will find RCS tags for OpenBSD/NetBSD/FreeBSD littered throughout the kernel source tree, some files even retaining original SCCS ids from 1980's CSRG days.
oh dear... you're using line counts as an argument? seriously?
its a "micro" kernel... its small!
I'm talking architecturally... look at the real history, the Aleph->Accent->Mach set of kernels was from a different tree.
The research program was to see if they could replace the BSD kernel with a Mach-type kernel and get the benefits of new kernel + POSIX/BSD userland... the research was a success.
Just tell me what mode that the BSD code was being run in? superviser or user mode? back in the Mach days, BSD code was user-mode code, explicitly not supervisor mode, that was the point. That has likely now changed, but we're debating the origin here, not the current state.
This does not mean that Mach was "derived from" BSD.
If you look at the contents of that repo, you will see that the majority of the code there is headers to allow compilation of very specific parts (e.g the net and inet directories), not the whole codebase.
Certainly, there is no kernel there and most calls redirect back into xnu. Most functionality is Mach-based, this is just for a user-facing API.
I’ll have to read more about iSH to learn if it’s a “true” shell, or effectively just emulated or with strict limitations, but either way the potential inspires of how great it would be to have a true shell and/or dev tools for iPads.