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.
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.
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 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.
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.
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 ;)
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.
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?
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.
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
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.
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!
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
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.
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?
> 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.
131 comments
[ 4.7 ms ] story [ 184 ms ] threadPythonista is much more pleasant today for actually writing code in, though.
Nice:) got a chuckle out of me...
[1]: https://holzschu.github.io/a-Shell_iOS/
iSH emulates 32-bit alpine x86 and can install things from apk
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.
I love the idea of a shell on iOS but why does it need to know my location?
This seems like a workaround so that the app can continue running in the background.
For example: https://github.com/ish-app/ish/wiki/Running-a-Python-Web-Ser....
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...
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)
EDIT: added slightly. For all the OS calls which are 100% native, it wouldn’t matter.
Unless it’s JavaScript. I see a missed opportunity here: compile everything to ASM.js! :)
I’m only half-kidding.
Imagine what developers could do if Apple loosened those restrictions a bit.
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...
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.
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
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.
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 &
⌃ is control
⎋ is escape
the arrow keys thing can be dragged to move the cursor around
I guess you might be able to bootstrap homebrew, nix or something like that?
https://news.ycombinator.com/item?id=24862764
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!
https://twitter.com/PaulGowder/status/1319409818554241025?s=...
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!
# apk add R
And I finally have R on my iPad!
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.
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.
Because it's the iphone and periodic background tasks are always malware.
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.
0: https://github.com/utmapp/UTM/blob/1feb721a9474255bd112f9e42...
This GitHub issue has more info:
https://github.com/utmapp/UTM/issues/397
> 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.
> 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.
There's logic in the madness. Barely.