> Unfortunately, I made the decision to write nearly all of the gadgets in assembly language. This was probably a good decision with regards to performance (though I'll never know for sure), but a horrible decision with regards to readability, maintainability, and my sanity. The amount of bullshit I've had to put up with from the compiler/assembler/linker is insane. It's like there's a demon in there that makes sure my code is sufficiently deformed, and if not, makes up stupid reasons why it shouldn't compile. In order to stay sane while writing this code, I've had to ignore best practices in code structure and naming. You'll find macros and variables with such descriptive names as ss and s and a. Assembler macros nested beyond belief. And to top it off, there are almost no comments.
> So a warning: Long-term exposure to this code may cause loss of sanity, nightmares about GAS macros and linker errors, or any number of other debilitating side effects. This code is known to the State of California to cause cancer, birth defects, and reproductive harm.
I don't think that Apple usually reads an app's code as part of their review process. They might check out certain parts to see how pieces are implemented, but that's about it, as far as I understand.
cd
wget http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86/apk-tools-static-2.10.5-r1.apk
cd /
tar xvzf ~/apk-tools-static-2.10.5-r1.apk
ln -s /sbin/apk.static /sbin/apk
cd
apk
Ahhhh I installed the version from the App Store and it just kept the app data from the version installed via Xcode. Didn’t realise that the App Store version was missing apk
I am very surprised that Apple allowed this on the actual App Store (and not just TestFlight), but I'm also pleased! Hopefully it will be accessible to more people now.
There are a number of command line shells available on iOS, right up to full blown programming environments in Python, Lua, C# and others. Pythonista is pretty mature, comes with a command line interpreter and you can get a very capable user created enhanced shell environment for it.
In the context of Python, don't forget Pyto! I use it lots for scripting tricky bits in the Shortcuts app in a real programming language. It has nice Shortcuts actions for "run this Python code" and "get the results of that code you ran earlier".
Same. It's way rougher around the edges than Pythonista is, but it's moving fast and adding nice support for new iOS features. For one example, from what I can tell x-callback-url is the only way to get stuff into Pythonista (and I haven't found a way to get stuff back out of it), but Pyto natively supports Shortcuts actions. There are lots of other things like that.
Pythonista is much more pleasant today for actually writing code in, though.
The fact that uname -a reports "Linux" and not iOS or BSD implies it's not some sort of contained userland, it likely has no access to anything outside it's sandbox, and can't run GUI apps means Apple are unlikely to care too much.
uname reports what we tell it to report ;) https://github.com/ish-app/ish/blob/master/kernel/uname.c. iSH is sandboxed as any other app on the store would be, but some have had success running GUI apps and connecting to them via VNC.
a-Shell doesn't try to run a full linux environment; it just gives you access to a lot of common utilities, which presumably was an easier sell to get on the app store. The fact that iSH Shell allows you to download and run arbitrary code from alpine's repos is what made many think that it'd never leave TestFlight.
"A project to get a Linux shell running on iOS, using usermode x86 emulation and syscall translation." https://github.com/ish-app/ish/
So theoretically it could be like an isolated computer game and have no access to anything from the underlying iOS environment. (Maybe it does let you access iOS's filesystem—it's not clear to me at a first glance.) I have the jaded feeling that this has to do with how it got approved.
https://github.com/ish-app/ish/wiki/Mounting-other-file-prov... says: "Additionally, if jailbroken or using the psychic paper exploit (not available through TestFlight nor will we help you do it), you can also mount using real, absolute paths. To do so run "mount -t real <src> <dst>", where <src> is the absolute path from the root of iOS and <dst> is the location in iSH to mount the file." Which suggests that you can only touch the underlying iOS if you've done an exploit.
As mentioned on that page, you can essentially mount whatever shows up in the Files app, but you don't have full filesystem access–iSH is a normal App Store app and is sandboxed as such.
iSH also acts as a File Provider so you can go to the Files app, tap “...” > “Edit Sidebar” and turn on “iSH” to “mount” your iSH filesystem and drag stuff in and out of it.
You can, I've got git, vim, and python on my iPad now. It's by no means perfect .. python is really slow .. but it works for my basic workflow for smaller projects.
This is actually really great for me. I have functioning vim and emacs on my desktop, but I don't know anything about .vimrc and use spacemacs... but now I have a platform I can safely experiment on without blowing anything up! Sweet!
Once you do this you can also install openssh. Obviously there are many shell apps at this point on iOS but just another handy way to SSH to a personal host.
I literally just got my app going on a tethered RasPi this morning (via SSH + screen). Now I need to do this as a target? No rest for the wicked. Thanks.
Looks fantastic but it seems pretty limited. Checked it out but "pkg install openssh" results in an error ... is it being maintained, or is just today an unlikely day?
I’ve been a beta user for a while, and it’s been awesome - I’ve been hosting node.js sites on my phone! But... the version that made it into the App Store had ‘apk’ removed.... it’s going to be harder now to install stuff
oh lovely, I played around with the TestFlight, will definitely add this.
Now it's time to complain: The search string "ish" (just like that) on the App Store doesn't even turn iSH up, at all. It might have been somewhere after the first ten results, I guess.
App Store search is the absolute worst, and regularly turns up garbage ripoff apps that Apple should never have allowed on the store in the first place. It's the worst part of the ecosystem, and I despair of them ever doing something about it.
You'd think a company with a few hundred billion dollars of cash just sitting around could handle something like this...
App Store search sucks, but I should note that the app has only been live for about 12 hours and it takes a while for this to propagate through the system. Perhaps we'll see this change as iSH becomes popular and the backend updates its rankings. (FWIW, "iSH shell" returns relevant results.)
If this wasn't a case of something which routinely happens to me, I wouldn't have said anything.
I wouldn't be surprised if iSH becomes the top result for that search string. But I wouldn't be surprised if it's number 2, after some obvious ripoff, either.
So, iSH does this amazing stuff by x86 emulation.
Aren't iOS devices arm based devices ? Why should they emulate x86 ? Isn't it easier to emulate arm64 linux instead ?
(I mean that arm64 binaries can run on arm64 devices. For example, consider wine which runs windows programs on linux/macos. Only x64 windows apps can run on x64 wine and only arm64 windows apps can run on arm64 devices. To run x64 windows apps on arm64 devices,you need qemu/other virtualization software)
Executing unsigned code on iOS is generally not feasible, which means that this would limit the set of programs you could run to a small prespecified (and signed) set of programs. (These apps exist already on the App Store; here's one: https://blink.sh). iSH can run user-created programs by emulating them. (Plus, with emulation we can run programs without modifying them because we can trap syscalls and such.) It would be nice if we could JIT compile code (since the interpreter is a bit slow compared to native code) or utilize hypervisor facilities, but that doesn't appear to be an option for now.
The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation), so you’re stuck using a pure interpreter, at which point there’s no real benefit to emulating the same architecture you’re running on.
There may be with regards to maintaining memory ordering guarantees, we're looking into a couple of strange hangs that only reproduce on ARM. But yes, in general the choice of architecture does not matter much when interpreting.
Not quite true; some ISA are simpler to decode than other and/or have simpler semantics to implement (eg. not x87). I can pretty much guarantee that you could have gotten [slightly] better performance with an iSH-like approach targeting RISC-V or ARM64.
EDIT: added slightly. For all the OS calls which are 100% native, it wouldn’t matter.
It's been on our minds for a while, the major issues with this is that IPC between the app process and WebKit is like 100µs, so having the interpreter run isolated from the app process is hard. Plus loading WASM is not "free" (that is, essentially an instruction cache flush) because you need to generate a bundle that WebKit will then load, which is slow (although there has been work done in this area: https://www.youtube.com/watch?v=7JUs4c99-mo). So even if we did some sort of WASI thing where everything is going on in the browser, there are hurdles to overcome to make this viable. Plus the current interpreter almost certainly leaves performance on the table ;)
I've been using iSH for more than 2 years now, and I'm glad to see that it's made it to the app store.
Here are some good use cases I've used iSH for:
- youtube-dl videos to Files app
- SSH into remote servers
- performing network pings or scans discretely
There's even a device at /dev/location which when catted can keep the app active in the background, due to background app refresh. The only real issue I've had (especially with Python programs) is that it runs orders of magnitude slower than native.
You can disable SSL checks, though I don't think I had them. Youtube-dl is very slow though, you're better off using a Telegram bot to give you the videos. The app also can't run for long in the background, which is essential for downloading.
I want to use it, but it’s too slow and non root users face all kind of weird permission errors I can’t find a workaround for, with go get for instance.
I use git or ssh clients as an alternative.
Some commands seem to hang forever, until the app is killed ‘ reset.
My experience with termux on an old nexus 7 was much better than iSH on a 2017 iPad Pro.
I find that the slowness can be made more bearable with catting /dev/location and using tmux. Having tried termux on Android myself, I agree that the experience there is a lot better.
I tried #1 before but it's simply too slow for me. Much slower than SSH'ing (using a different app) to a remote server, invoking youtube-dl to put the file in a shared Dropbox folder, then retrieving the downloaded video in the Dropbox app. Are you at all bothered by its speed?
Why the shell app needs to use the location services? The App Store description indicates that “This app may use your location even when the app is not open”
Apple doesn't allow the user to set an app as "don't kill even if not focused for a while" ? Android user here
On Android it's not automatic or automated and the user has to do it by hand himself (for obvious reasons); but for a few specific apps it allows them to work the way they should without needing weird permissions to emulate
> UPDATE: We record significantly increased number of app killing on Samsung's Android Pie flavor. The hints show adaptive battery being much more eager than in stock Android.
> After 3 days any unused app will not be able to start from background (e.g. alarms will not work anymore). Imagine, you won't use your alarm clock for a the weekend +1 day and bang! no alarms any more and you miss work! We strongly suggest to turn off Adaptive battery and Put apps to sleep options per instructions below.
That alarm thing has happened to me several times and is why I recommend to people to not use their phone as alarm at as a dedicated device makes much more sense.
Amazing that iSH has been allowed on the App Store. Never thought that day would come.
Maybe this, or similar methods, is how Apple begins to enable development on iOS, through full app-based systems that are completely isolated from the underlying OS.
UTM no longer works on iOS 14 without a jailbreak. It used shenanigans[0] to cause the process to be entitled to JIT, and the shenanigans no longer work.
I’ve been using this to play with Janet and other LISPs for a while. Great to see it finally on the App Store, although I do wish it was running native ARM binaries for a little more speed :)
I’ve been trying to learn Janet for a couple of days. Janet is a Lisp-like language but in no way a lisp. Janet’s site now delibarely states that Janet is a Lisp-like language not a Lisp.
Janet can be parsed using a PEG parser, so I think that causes it to lose some expressivity of Lisp.
Janet is a cool language though, I like it. I wish there was a decent tutorial instead of just language reference docs. And the Core API documentation is a bit poor in my opinion. I’m trying to submit examples to Core API documentation, I’m hopeful it will get better in time.
It actually did in TestFlight, but they removed `apk` from the included filesystem as part of the app review process. It's pretty easy to go onto Alpine's website and get a different filesystem to import, though ...
Apple's restrictions resulted in a pretty severe reduction in functionality of the app. Many of their how-tos still contain apk commands which no longer function.
The original title for this post was “iSH Shell Launches on the App Store” which is significant since the project had previously spent several years on TestFlight.
Since the domain is apps.apple.com, that part is implied. (From the HN guidelines: "If the title includes the name of the site, please take it out, because the site name will be displayed after the link.")
The bit about TestFlight is certainly interesting but the best way to communicate it is not via the title but via a comment in the thread...like you just did!
Your location doesn't leave the device, if that's what you were wondering. And the GPS doesn't turn on until you access /dev/location–actually, you won't even get a prompt until then. It is very much possible to use iSH without using the location file.
iSH is distributed under a custom EULA rather than Apple's standard Licensed Application End User License Agreement:
> The iSH app ("iSH") is made available to you by the developers of the application (collectively, the "iSH developers") under the terms available at https://github.com/ish-app/ish/blob/master/LICENSE.md (the "License"). These license terms are an agreement (the "Agreement") between you and the iSH developers, not Apple, which disclaims responsibility of the licensed application and its contents thereof, and replaces the terms of the standard Licensed Application End User License Agreement available at https://www.apple.com/legal/internet-services/itunes/dev/std.... The iSH developers own the intellectual property of iSH and provide it to you under the License without warranty to the fullest extent permitted by law. Apple and Apple's subsidiaries are not legally liable for product claims, including claims for maintenance and support, but may at their discretion choose to enforce this agreement against you as third party beneficiaries of iSH. In cases where certain provisions laid out in this Agreement are in conflict with local laws and cannot go into effect, the remaining provisions will continue to apply in full force. Questions or any other requests about this Agreement may be directed at Theodore Dubois, available at tbodt@ish.app.
We're not lawyers, so we can't say this definitively. We still have not seen anything that would prevent it, so I guess that's the best I can give you?
Could this be used to e.g. run a local http server which you can then access from Safari? (Thinking web development workflows). I tried running http-server from npm but it failed with an "Unknown error 22" so I guess maybe the sandbox prevents this
Yes, local web servers should work (Python certainly does, I just checked on my iPhone). Can you file a bug at https://github.com/ish-app/ish/issues with more details?
Oh wow, it does! Super cool. This is potentially massive for doing work on the go on an iPad! I'll look more into my issue and will file on Github :) Thanks
They really have to. Android wasn't a serious competitor with the iphone but the phones running Linux are pretty rapidly improving. At this point they're actually usable and since the users themselves are able to fix core problems with the OS it won't be long before Apple will be forced by the market to actually behave.
Can anyone help me? I have a problem with -ash: permission denied whenever I attempt to type in something that requires this clearance. I even asked the dev on GitHub but to no avail
The version of iSH on the App Store has had package management functionality removed. The ability to run Linux programs, as well as import files, has not been changed.
From the Github page:
> Unfortunately, I made the decision to write nearly all of the gadgets in assembly language. This was probably a good decision with regards to performance (though I'll never know for sure), but a horrible decision with regards to readability, maintainability, and my sanity. The amount of bullshit I've had to put up with from the compiler/assembler/linker is insane. It's like there's a demon in there that makes sure my code is sufficiently deformed, and if not, makes up stupid reasons why it shouldn't compile. In order to stay sane while writing this code, I've had to ignore best practices in code structure and naming. You'll find macros and variables with such descriptive names as ss and s and a. Assembler macros nested beyond belief. And to top it off, there are almost no comments.
> So a warning: Long-term exposure to this code may cause loss of sanity, nightmares about GAS macros and linker errors, or any number of other debilitating side effects. This code is known to the State of California to cause cancer, birth defects, and reproductive harm.
M…maybe I'll hold off on that PR.
Does this mean some person at Apple had to review the app... In assembly?
I don't think that Apple usually reads an app's code as part of their review process. They might check out certain parts to see how pieces are implemented, but that's about it, as far as I understand.
For any app, you give apple effectively a binary (really it's a sort of IR), not the source code.
No, Apple don't have access to your sources, only the compiled binaries / ir, and symbols
GAS syntax is particularly annoying for actual human use, although I enjoy writing (x86) Asm otherwise.
Line https://github.com/ish-app/ish/blob/master/jit/gadgets-aarch... and the subsequent lines sum it up nicely:
For those that just want to play:
What are you trying to achieve here? What’s wrong with apk 2.10.4 that ships with iSH?
The version in the app store linked here does not ship with a binary of apk.
Ahhhh I installed the version from the App Store and it just kept the app data from the version installed via Xcode. Didn’t realise that the App Store version was missing apk
It took me longer than it should to realise that you weren't referring to an Android version.
Thank you very much. Copy n pasting that, followed by
# apk add R
And I finally have R on my iPad!
Just tried this but it seems to have failed on the `wget` command
Odd, not sure why that's failing for you. You can bypass the wget command by downloading that file in Safari, then doing
Then you can run
When you cd to the root.
Though, I suspect apk itself will fail if you can't resolve domain names.
Edit: As gorkish points out, make sure iSH has network permissions first and try again with the original command.
The first network access fails until you grant local network permissions to iSH.
I am very surprised that Apple allowed this on the actual App Store (and not just TestFlight), but I'm also pleased! Hopefully it will be accessible to more people now.
There are a number of command line shells available on iOS, right up to full blown programming environments in Python, Lua, C# and others. Pythonista is pretty mature, comes with a command line interpreter and you can get a very capable user created enhanced shell environment for it.
In the context of Python, don't forget Pyto! I use it lots for scripting tricky bits in the Shortcuts app in a real programming language. It has nice Shortcuts actions for "run this Python code" and "get the results of that code you ran earlier".
Pyto is really interesting, it's not as polished at Pythonista but I appreciate the very frequent updates. It's come a long way pretty quickly.
Same. It's way rougher around the edges than Pythonista is, but it's moving fast and adding nice support for new iOS features. For one example, from what I can tell x-callback-url is the only way to get stuff into Pythonista (and I haven't found a way to get stuff back out of it), but Pyto natively supports Shortcuts actions. There are lots of other things like that.
Pythonista is much more pleasant today for actually writing code in, though.
The fact that uname -a reports "Linux" and not iOS or BSD implies it's not some sort of contained userland, it likely has no access to anything outside it's sandbox, and can't run GUI apps means Apple are unlikely to care too much.
uname reports what we tell it to report ;) https://github.com/ish-app/ish/blob/master/kernel/uname.c. iSH is sandboxed as any other app on the store would be, but some have had success running GUI apps and connecting to them via VNC.
> strcpy(uts->release, "4.20.69-ish");
Nice:) got a chuckle out of me...
A similar app, a-Shell[1] has been up on the App Store for a almost a year now.
[1]: https://holzschu.github.io/a-Shell_iOS/
What’s the comparison between a-Shell and iSH? I’ve somehow never heard of the former, but I have repeatedly heard about the latter and used it.
a-Shell doesn't try to run a full linux environment; it just gives you access to a lot of common utilities, which presumably was an easier sell to get on the app store. The fact that iSH Shell allows you to download and run arbitrary code from alpine's repos is what made many think that it'd never leave TestFlight.
a-shell uses ios_system https://github.com/holzschu/ios_system/ and can install WASM packages (if they exist?)
iSH emulates 32-bit alpine x86 and can install things from apk
"A project to get a Linux shell running on iOS, using usermode x86 emulation and syscall translation." https://github.com/ish-app/ish/
So theoretically it could be like an isolated computer game and have no access to anything from the underlying iOS environment. (Maybe it does let you access iOS's filesystem—it's not clear to me at a first glance.) I have the jaded feeling that this has to do with how it got approved.
https://github.com/ish-app/ish/wiki/Mounting-other-file-prov... says: "Additionally, if jailbroken or using the psychic paper exploit (not available through TestFlight nor will we help you do it), you can also mount using real, absolute paths. To do so run "mount -t real <src> <dst>", where <src> is the absolute path from the root of iOS and <dst> is the location in iSH to mount the file." Which suggests that you can only touch the underlying iOS if you've done an exploit.
As mentioned on that page, you can essentially mount whatever shows up in the Files app, but you don't have full filesystem access–iSH is a normal App Store app and is sandboxed as such.
Interesting, I wonder why they used x86 emulation and didn't just run ARM binaries on it.
That, amusingly, would probably not be allowed on the App Store.
I thought running any kind of loadable code or JIT on the App Store was banned. I'm very glad to have this app.
Amen
Can any iSH aficionado provide a step-by-step on how to augment this release version of the app with an additional binary executable?
For example the nano text editor.
EDIT: Managed it like this:
1. Download this file and put it on iCloud Drive: http://dl-cdn.alpinelinux.org/alpine/v3.12/releases/x86/alpi...
2. Back in the app, tap the Cog icon above the keyboard > Filesystems > Import > select that file.
3. (The app crashed?) Start the app again and go back to the Cog > Filesystems > alpine-minirootfs-.... > Boot from This Filesystem
4. $ apk add nano
5. $ nano
EDIT2: And now git installs fine too. Gonna have some fun with this!
iSH also acts as a File Provider so you can go to the Files app, tap “...” > “Edit Sidebar” and turn on “iSH” to “mount” your iSH filesystem and drag stuff in and out of it.
Thank you for sharing this. I just dragged a download from Safari into the file system via the Files app. What a clever feature.
!!!! I need to go see if I can have Vim on my iPad now...
You can, I've got git, vim, and python on my iPad now. It's by no means perfect .. python is really slow .. but it works for my basic workflow for smaller projects.
This is actually really great for me. I have functioning vim and emacs on my desktop, but I don't know anything about .vimrc and use spacemacs... but now I have a platform I can safely experiment on without blowing anything up! Sweet!
IT LIVES!!!! Now to remap escape to something that actually exists on an ipad keyboard...
https://twitter.com/PaulGowder/status/1319409818554241025?s=...
In the iPadOS settings for external keyboards, you can remap caps lock to escape.
Once you do this you can also install openssh. Obviously there are many shell apps at this point on iOS but just another handy way to SSH to a personal host.
I literally just got my app going on a tethered RasPi this morning (via SSH + screen). Now I need to do this as a target? No rest for the wicked. Thanks.
Those who are on Android , can use https://termux.com/ .
Termux is great, i second this recommendation
Looks fantastic but it seems pretty limited. Checked it out but "pkg install openssh" results in an error ... is it being maintained, or is just today an unlikely day?
I think that the problem is from your end . I tried installing it and ended up installing without any problem.
I’ve been a beta user for a while, and it’s been awesome - I’ve been hosting node.js sites on my phone! But... the version that made it into the App Store had ‘apk’ removed.... it’s going to be harder now to install stuff
As long as you can curl | bash ..!
I guess you might be able to bootstrap homebrew, nix or something like that?
Just in case you haven't seen it, you can follow my comment to bootstrap apk.
https://news.ycombinator.com/item?id=24862764
Do you know if it’s possible to install node? I’m eager to try this out on my ipad :)
Yeah! Follow the steps above to install `apk` and then `apk add node`
oh lovely, I played around with the TestFlight, will definitely add this.
Now it's time to complain: The search string "ish" (just like that) on the App Store doesn't even turn iSH up, at all. It might have been somewhere after the first ten results, I guess.
App Store search is the absolute worst, and regularly turns up garbage ripoff apps that Apple should never have allowed on the store in the first place. It's the worst part of the ecosystem, and I despair of them ever doing something about it.
You'd think a company with a few hundred billion dollars of cash just sitting around could handle something like this...
App Store search sucks, but I should note that the app has only been live for about 12 hours and it takes a while for this to propagate through the system. Perhaps we'll see this change as iSH becomes popular and the backend updates its rankings. (FWIW, "iSH shell" returns relevant results.)
That's fair.
If this wasn't a case of something which routinely happens to me, I wouldn't have said anything.
I wouldn't be surprised if iSH becomes the top result for that search string. But I wouldn't be surprised if it's number 2, after some obvious ripoff, either.
> using a usermode x86 emulator
So, iSH does this amazing stuff by x86 emulation. Aren't iOS devices arm based devices ? Why should they emulate x86 ? Isn't it easier to emulate arm64 linux instead ?
(I mean that arm64 binaries can run on arm64 devices. For example, consider wine which runs windows programs on linux/macos. Only x64 windows apps can run on x64 wine and only arm64 windows apps can run on arm64 devices. To run x64 windows apps on arm64 devices,you need qemu/other virtualization software)
Executing unsigned code on iOS is generally not feasible, which means that this would limit the set of programs you could run to a small prespecified (and signed) set of programs. (These apps exist already on the App Store; here's one: https://blink.sh). iSH can run user-created programs by emulating them. (Plus, with emulation we can run programs without modifying them because we can trap syscalls and such.) It would be nice if we could JIT compile code (since the interpreter is a bit slow compared to native code) or utilize hypervisor facilities, but that doesn't appear to be an option for now.
The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation), so you’re stuck using a pure interpreter, at which point there’s no real benefit to emulating the same architecture you’re running on.
There may be with regards to maintaining memory ordering guarantees, we're looking into a couple of strange hangs that only reproduce on ARM. But yes, in general the choice of architecture does not matter much when interpreting.
Not quite true; some ISA are simpler to decode than other and/or have simpler semantics to implement (eg. not x87). I can pretty much guarantee that you could have gotten [slightly] better performance with an iSH-like approach targeting RISC-V or ARM64.
EDIT: added slightly. For all the OS calls which are 100% native, it wouldn’t matter.
> The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation)
Unless it’s JavaScript. I see a missed opportunity here: compile everything to ASM.js! :)
I’m only half-kidding.
It's been on our minds for a while, the major issues with this is that IPC between the app process and WebKit is like 100µs, so having the interpreter run isolated from the app process is hard. Plus loading WASM is not "free" (that is, essentially an instruction cache flush) because you need to generate a bundle that WebKit will then load, which is slow (although there has been work done in this area: https://www.youtube.com/watch?v=7JUs4c99-mo). So even if we did some sort of WASI thing where everything is going on in the browser, there are hurdles to overcome to make this viable. Plus the current interpreter almost certainly leaves performance on the table ;)
It’s so cool that you have actually considered it.
Imagine what developers could do if Apple loosened those restrictions a bit.
I've been using iSH for more than 2 years now, and I'm glad to see that it's made it to the app store.
Here are some good use cases I've used iSH for:
- youtube-dl videos to Files app
- SSH into remote servers
- performing network pings or scans discretely
There's even a device at /dev/location which when catted can keep the app active in the background, due to background app refresh. The only real issue I've had (especially with Python programs) is that it runs orders of magnitude slower than native.
How did you get YouTube-dl? That was the second thing I tried but I get SSL issues with both wget and curl.
I also tried installing some npm packages but ran into permission issues.
You can disable SSL checks, though I don't think I had them. Youtube-dl is very slow though, you're better off using a Telegram bot to give you the videos. The app also can't run for long in the background, which is essential for downloading.
Curiously at some point I also had SSL errors with youtube-dl, I installed mine via pip3, and I think updating it fixed the problem.
Re: permission errors, might be due to the fact that you are root by default and should add a new non-root user (via useradd).
I want to use it, but it’s too slow and non root users face all kind of weird permission errors I can’t find a workaround for, with go get for instance. I use git or ssh clients as an alternative.
Some commands seem to hang forever, until the app is killed ‘ reset.
My experience with termux on an old nexus 7 was much better than iSH on a 2017 iPad Pro.
I find that the slowness can be made more bearable with catting /dev/location and using tmux. Having tried termux on Android myself, I agree that the experience there is a lot better.
I tried #1 before but it's simply too slow for me. Much slower than SSH'ing (using a different app) to a remote server, invoking youtube-dl to put the file in a shared Dropbox folder, then retrieving the downloaded video in the Dropbox app. Are you at all bothered by its speed?
Yeah the speed bothers me somewhat. I haven't tried that method, might be worthwhile.
Why the shell app needs to use the location services? The App Store description indicates that “This app may use your location even when the app is not open”
It is likely the only way to stay active as much as possible in the background so the process doesn't get killed.
Apple doesn't allow the user to set an app as "don't kill even if not focused for a while" ? Android user here
On Android it's not automatic or automated and the user has to do it by hand himself (for obvious reasons); but for a few specific apps it allows them to work the way they should without needing weird permissions to emulate
Unfortunately, there is no way to do that on ios as far as I know.
Well technically there is. It may run afoul of Apple’s guidelines. An app can play a silent sound in the background.
On Android it varies a lot by manufacturer, you can find some comparisons, detailed information, and instructions to circumvent when possible here:
https://dontkillmyapp.com/
> UPDATE: We record significantly increased number of app killing on Samsung's Android Pie flavor. The hints show adaptive battery being much more eager than in stock Android.
> After 3 days any unused app will not be able to start from background (e.g. alarms will not work anymore). Imagine, you won't use your alarm clock for a the weekend +1 day and bang! no alarms any more and you miss work! We strongly suggest to turn off Adaptive battery and Put apps to sleep options per instructions below.
That alarm thing has happened to me several times and is why I recommend to people to not use their phone as alarm at as a dedicated device makes much more sense.
This is correct
https://github.com/ish-app/ish/issues/249
> You can now keep the app running in the background with the invocation cat /dev/location > /dev/null &
You can use /dev/location, which allows you to access location data from software you run within iSH.
Amazing that iSH has been allowed on the App Store. Never thought that day would come.
Maybe this, or similar methods, is how Apple begins to enable development on iOS, through full app-based systems that are completely isolated from the underlying OS.
Now they just need to allow UTM in the App Store.
UTM no longer works on iOS 14 without a jailbreak. It used shenanigans[0] to cause the process to be entitled to JIT, and the shenanigans no longer work.
0: https://github.com/utmapp/UTM/blob/1feb721a9474255bd112f9e42...
There are reports that this has started working again in some developer betas. Still, it's not something that could go on the App Store.
Interesting. I’m going to have to try this.
This GitHub issue has more info:
https://github.com/utmapp/UTM/issues/397
You may find the reporter of that issue amusing.
I’ve been using this to play with Janet and other LISPs for a while. Great to see it finally on the App Store, although I do wish it was running native ARM binaries for a little more speed :)
I’ve been trying to learn Janet for a couple of days. Janet is a Lisp-like language but in no way a lisp. Janet’s site now delibarely states that Janet is a Lisp-like language not a Lisp.
Janet can be parsed using a PEG parser, so I think that causes it to lose some expressivity of Lisp.
Janet is a cool language though, I like it. I wish there was a decent tutorial instead of just language reference docs. And the Core API documentation is a bit poor in my opinion. I’m trying to submit examples to Core API documentation, I’m hopeful it will get better in time.
Would this enable CLI rsync against iOS Files?
Yes. Kinda.
I mean, if it shows up in the Files app, you can mount it and run normal things against that folder.
The thing I want to see, though, is a folder for the photos app. That doesn't exist, since the Photos app doesn't expose it's data as a folder.
Your crontab won't run though so you'll always have to trigger it manually.
Because it's the iphone and periodic background tasks are always malware.
Good old 17+ shells? :P What's wrong with Apple and self imposed censorship?
Pretty much anything that can pull down random URLs gets that, and this comes with curl and wget.
There's logic in the madness. Barely.
Might as well have called it xxxterm.
They will shut it down as soon as someone implements apt-get like feature.
It actually did in TestFlight, but they removed `apk` from the included filesystem as part of the app review process. It's pretty easy to go onto Alpine's website and get a different filesystem to import, though ...
Apple's restrictions resulted in a pretty severe reduction in functionality of the app. Many of their how-tos still contain apk commands which no longer function.
For example: https://github.com/ish-app/ish/wiki/Running-a-Python-Web-Ser....
apk works for me, but maybe it's because I had the old ("tester removed") TestFlight version hanging around?
For people like me unfamiliar with this.
Simply go to the [0]download page, look for "mini root filesystem" and download x86, or simply click this [1]link
Upload this to your iPhone. Then in the iSH settings find the "filesystems" section and click "import".
[0]: https://alpinelinux.org/downloads/
[1]: http://dl-cdn.alpinelinux.org/alpine/v3.12/releases/x86/alpi...
The original title for this post was “iSH Shell Launches on the App Store” which is significant since the project had previously spent several years on TestFlight.
Since the domain is apps.apple.com, that part is implied. (From the HN guidelines: "If the title includes the name of the site, please take it out, because the site name will be displayed after the link.")
The bit about TestFlight is certainly interesting but the best way to communicate it is not via the title but via a comment in the thread...like you just did!
> Location This app may use your location even when it isn't open, which can decrease battery life.
I love the idea of a shell on iOS but why does it need to know my location?
https://github.com/ish-app/ish/issues/249
This seems like a workaround so that the app can continue running in the background.
That's a much better reason than I feared. Thank you.
Your location doesn't leave the device, if that's what you were wondering. And the GPS doesn't turn on until you access /dev/location–actually, you won't even get a prompt until then. It is very much possible to use iSH without using the location file.
Termius and several other SSH apps use this workaround as well.
Wait... the repository states that the source code is under the GPLv3. Doesn't the App Store disallow apps that are under the GPL, or is that a myth?
I'm curious about that as well...
iSH is distributed under a custom EULA rather than Apple's standard Licensed Application End User License Agreement:
> The iSH app ("iSH") is made available to you by the developers of the application (collectively, the "iSH developers") under the terms available at https://github.com/ish-app/ish/blob/master/LICENSE.md (the "License"). These license terms are an agreement (the "Agreement") between you and the iSH developers, not Apple, which disclaims responsibility of the licensed application and its contents thereof, and replaces the terms of the standard Licensed Application End User License Agreement available at https://www.apple.com/legal/internet-services/itunes/dev/std.... The iSH developers own the intellectual property of iSH and provide it to you under the License without warranty to the fullest extent permitted by law. Apple and Apple's subsidiaries are not legally liable for product claims, including claims for maintenance and support, but may at their discretion choose to enforce this agreement against you as third party beneficiaries of iSH. In cases where certain provisions laid out in this Agreement are in conflict with local laws and cannot go into effect, the remaining provisions will continue to apply in full force. Questions or any other requests about this Agreement may be directed at Theodore Dubois, available at tbodt@ish.app.
So is it actually possible to put GPL code on the app store then?
We're not lawyers, so we can't say this definitively. We still have not seen anything that would prevent it, so I guess that's the best I can give you?
An iOS app under 4MB, what is this witchcraft?
Could this be used to e.g. run a local http server which you can then access from Safari? (Thinking web development workflows). I tried running http-server from npm but it failed with an "Unknown error 22" so I guess maybe the sandbox prevents this
Yes, local web servers should work (Python certainly does, I just checked on my iPhone). Can you file a bug at https://github.com/ish-app/ish/issues with more details?
Oh wow, it does! Super cool. This is potentially massive for doing work on the go on an iPad! I'll look more into my issue and will file on Github :) Thanks
Really happy to see Apple has finally allowed this on the App Store!
They really have to. Android wasn't a serious competitor with the iphone but the phones running Linux are pretty rapidly improving. At this point they're actually usable and since the users themselves are able to fix core problems with the OS it won't be long before Apple will be forced by the market to actually behave.
Can anyone help me? I have a problem with -ash: permission denied whenever I attempt to type in something that requires this clearance. I even asked the dev on GitHub but to no avail
Whoa, I was wondering if this would ever come out beta. So cool.
This is awesome, but nmap doesn't seem to work, or am I doing it wrong? downloaded apk-tools-static and installed apk using that, and then nmap.
Can I use a console cable with this and my iPad Pro?!
how do i quit vi in this app? no jokes, seriously?
⇥ is tab
⌃ is control
⎋ is escape
the arrow keys thing can be dragged to move the cursor around
Knowing Ctrl-[ for escape has saved me enough times.
Cool! Installed it and played around a bit; everything worked as it should. Here's hoping it sticks around!
iSH is brilliant and with addition of custom environments it's even better!
I installed it but apk doesn't work as a command.
The version of iSH on the App Store has had package management functionality removed. The ability to run Linux programs, as well as import files, has not been changed.
Go to the Alpine Linux downloads page, get the mini root FS image, and boot from that instead of the default filesystem.
Why does it need unrestricted location access?
???