> 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.
"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.
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.
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.
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.
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.
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!
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.
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 ;)
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.
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.
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?
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.
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.
> 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.