Linux apps running on iOS via userspace x86 emulation and syscall translation
ish.app
ish.app
It's part of the reason why I recently moved away from iOS. Things like this are not supposed to exist, and you have to bend over backwards to make it work.
EDIT: Okay apparently this changed as of last year-ish? Looks like they have an exception in place for "a programming environment intended for use in learning how to program"* Regardless I think this kind of shell environment is still against the app store guidelines.
*https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...
I'm not sure how this app would be allowed though.
The main restriction in the past was on apps that downloaded code to run. For Pythonista and Codea and such this meant you had to either type in or cut-and-past in your code. However Pythonista has had the ability for you to write or paste in a dropbox sync script or FTP server script, etc, for may years, they just couldn't include it as standard. Since then this has been eased up so Pythonista now has a built-in feature to sync scripts to iCloud.
Getting to App Store is a human review.
Does that processor have hardware support for it already but Apple just doesn't do software support? So they can only use it themselves?
I doubt it was, but my headcanon is that some poor App Store reviewer saw something that looked like code and grabbed a supervisor to do a deeper review.
https://www.urbandictionary.com/define.php?term=Headcanon
An idea, belief, or aspect of a story that is not mentioned in the media itself, but is accepted by either the media consumer themselves or the fandom in general. If it is confirmed by the creator of the story, it becomes canon.
Yes, it does. And as of recently you can even put apps like this on the App Store!
pythonista3 is a very controlled experiment as it is now. and it exploits a "tiny blessing" apple gave on the policy of running "user inputed source code" only!
The reason they won't do this is because they would't be able to JIT execute in their App Store app, which would make their browser seem unbearably slow.
Codea (a Lua programming environemnt) has been on the App Store since 2011 and has had games written in it on the App Store since soon after as well*. Pythonista has been around for 6 years, has a built-in GUI designer, you can get Dropbox and Github syncing scripts for it and now it has a built-in feature so you can even sync your scripts between devices using iCloud. It also has apps written with it on the App Store.
Usable and capable compared to what?
There is some stuff but it is always way inferior to anything on comparable platforms. That isn't obvious for MacOS, but certainly for iOS. Not that I am a huge fan of Android. It has a lot of similar problems.
But I cannot understand enthusiasm for Apple while it restricts access to almost any part of their software environment.
Compared to pretty much anything - honestly. Pythonista is the gold standard. It has a fully feature integrated syntax highlighting editor, a built-in GUI form designer, graphics and media libraries for games, an integrated debugger, custom keyboard, a selection of Python third party modules such as scipy and Matplotlib, all the standard Python docs and tutorials and included module docs, full integration with share sheets, notifications, widgets, it's a universal app for iPhone and iPad, it integrates with the Github client apps such as Working Copy and it has built-in iCloud syncing for script folders. You can get Dropbox and Github Gist sync scripts pretty easily, I used to use an FTP server script a lot before iCloud integration came along. It's hard to imagine what else it could really need.
But let's compare it to the other major phone and tablet OS for a start. You even say so yourself. The dev apps for iOS are streets ahead of anything on Android. You seem to be arguing that in theory Apple's policies _should_ be holding iOS dev apps back compared to Android, but in reality that just isn't happening, even slightly.
I can certainly sympathise. About 6 or 7 years ago I was seriously considering getting an Android tablet because I expected the on-device dev story there to pull well ahead of iOS in the near future and wanted to be able to take advantage of that. What actually happened was I started using Codea, and when Pythonista came along I switched to that, and nothing comparable on Android ever materialised.
War story - I had to do a programming exercise for a job interview. I did most of it on my iPad on the train, including a custom compression exercise that involved writing my own bit-twiddling routines and a server remote control script using Paramiko, which of course Pythonista includes. I was remote controlling some Linux VMs running on my Mac in Virtualbox, using ssh from Python scripts directly from my iPhone!
It's a terrible shame and I don't understand why Android is so far behind on this. I suspect it's because the Open Source and Free Software communities have never really embraced Android and spent the time and effort to tool it up. Meanwhile Apple has been paying very close attention to this area and judiciously relaxing their rules in consultation with dev app authors. Whatever the reasons though, if you want to write scripts locally on a phone or tablet, iOS is clearly the way to go right now and that doesn't look like it's going to change any time soon.
I don't even have to try hard. I use a linux shell on a blackberry android phone (over 6in screen, so i call it a tablet), with a real keyboard, and it is years ahead of anything you describe.
As for my computer, I use a Mac mini that dual boots macOS and Linux. I have an older Mac mini that runs OpenBSD exclusively. I also have a media server I cobbled together from scavenged x86 parts.
I'm not a programmer, but it's my understanding from this community and others I frequent that Macs make for a comfortable and useful platform for their work and leisure computing life.
So, despite your attempt at gatekeeping, Apple products do have a place in a random hacker's workflow if that hacker decides he wants it; it's not up to you to decide what someone else uses and enjoys.
I've sysadmin'd all OSs for many years, but I'm with GP: I see Apple as another Microsoft these days (especially given MSs dubious push into non Foss oss) Hell even their efi implementation is non standard, and I really think people should pay more attention to Richard Stallman...(paraphrasing)
"Apple puts the user in a prison. It is a beautiful prison though".
Now, that's not to be defending others that do the same but in a different way (android is crap due to unrootable devices)...
Once again, the four freedoms as explained by RMS are the crux of the matter. The man was and is right, and it gets tiring seeing so many people bandwagon onto attacks against his person without addressing his position, for which I will always consider him a man who saw the future far before anyone else, and is getting more and more relevant every day.
This is a mischaracterizsation. You can boot Linux, it is up to Linux to have driver support for the T2 SSD controller so that it can detect it as storage.
That can be turned down to either accept any OS that was ever signed by Apple, or to boot whatever you want it to.
The third option should let you attempt to boot Linux, but like you said, whether the driver support exists is another matter entirely.
Startup Security Utility -> Secure Boot -> No Security
But there is a danger in this type of "democracy", namely that we're heading for a future where true general purpose computing starts to disappear, and universities and computing enthousiasts have to pay thousands of dollars for a universally programmable computer. With Apple aggressively vertically integrating their supply-chain, and others copying Apple's business tactics, the writing is on the wall ...
I think just the opposite happened. All we had were general purpose computers, then we added "easy to use" computers in the form of smartphones and tablets. It just allowed a lot more people to take advantage of computers, it did not remove access to general purpose computers for the rest of us. Personally, I love the idea of a bifurcated world where the less technically savvy use devices that are far more restricted and secure. I really like that my parents can get a device, like an iPad, that does everything they need from a computer (email, facebook, light web browsing) without having to worry about malware.
I can already run Linux on my desktop computer, and I intend to buy a Librem phone when it comes out, so I can run Linux without performance penalties on my phone
... and without possible retraction by Apple looming over my head.
Gecko runs just fine on iOS.
Gecko runs just fine on iOS; it just isn't deployed.
That's neat. Looks like the last commit was in 2015.
Is there any backstory to this project? Was it just research? Is it abandoned?
How so? I see no guidelines this app is violating.
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded.
3.3.3 Without Apple’s prior written approval or as permitted under Section 3.3.23 (In-App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store or VPP/B2B Program Site.
App Store Review Guideline
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.
As for the A/B testing that some companies do via sketchy runtime hooking, that has been a boundary case for a while that sometimes does cause you problems with Apple, but was vaguely OK if and only if the downloaded functionality was run through JavaScriptCore: the old version of this restriction essentially used to say "only if run in WebKit" (and I got manual clarification once that they were OK with JavaScriptCore, though I think they also made that explicit in the rules at some point).
I'm making a distinction between the code that's downloaded and interpreted and the actual app's code, which is important because I can download a FRACTRAN (or your favorite Turing-complete language) interpreter written in Python and run it in Pythonista and run afoul of this rule unless you take the interpretation of "scripts, code, and interpreters" being the ARM code that is running natively on the device that implements the emulation system. So if you look at the "arbitrary binaries" (which just so happen to less readable, non ASCII "source code" for iSH) being equivalent to Python scripts, there really is no issue here. No native code is being downloaded, generated, or executed in either case.
Pythonista, which is "borderline", might actually be possible to claim is an educational app: the person who wrote it seems to discuss it like that, and that is often how it is used. Apple seems to want to allow apps that are able to be used for teaching people to program. That is not the stated purpose of iSH nor is it how most people seem to want to use iSH.
You just really really seem to want to believe that this is OK based on this clause, but you are past the point of "stretching" and are now just seemingly purposefully refusing to understand Apple's restriction and also seem to not understand that this isn't some black and white "letter of the law" sort of thing but a massive grey area of "what is Apple's intention here" (which includes wanting to avoid creating a little app ecosystem inside of another app, which the binary package manager here clearly does).
They can't be, because all of these are lumped together in the category of "must be bundled with the app".
> Apple seems to want to allow apps that are able to be used for teaching people to program. That is not the stated purpose of iSH nor is it how most people seem to want to use iSH.
I mean, you could repackage this as "learn the Almquist shell".
> You just really really seem to want to believe that this is OK based on this clause
Because that lets it be on the App Store!
> you are past the point of "stretching" and are now just seemingly purposefully refusing to understand Apple's restriction and also seem to not understand that this isn't some black and white "letter of the law" sort of thing but a massive grey area of "what is Apple's intention here" (which includes wanting to avoid creating a little app ecosystem inside of another app, which the binary package manager here clearly does).
I think we both understand Apple's restriction on alternative App Store environments, and I agree with you that the software as it currently stands will likely never pass actual App Store review with apk bundled with it. But I still think it's possible for it to be approved provided it shipped without it, even if getting a package manager onto it would be possible because it it exposes the filesystem through iTunes file sharing, as well as allows for downloading one. As you've mentioned, this is really about perception: if Apple thinks you're trying to make an "App Store" inside your app, they'll quickly shut it down, but if you make it annoying but possible to do something like this in-app they might buy the argument that it wasn't your primary intention.
...that's the point: they are explicitly saying that both the interpreter and the code being interpreted must be shipped with the app, as that clause is directly saying you can only have an interpreter if there is no scripts or code being downloaded to later run on said interpreter.
> I mean, you could repackage this as "learn the Almquist shell".
...but they didn't. This same argument is the argument "in some theoretical alternative reality my BitTorrent client is mostly used to download files that can be legally redistributed, so the fact that even I am not using it in this way should not be counted against it"... but it isn't.
> > You just really really seem to want to believe that this is OK based on this clause...
> Because that lets it be on the App Store!
Whether this is to be allowed in the App Store has very little to do with what Saagar has chosen to believe, particularly if that choice has been made out of convenience.
Isn't this just a matter of writing it to some page and then setting the RX bit?
Yes, but this is not easy to do on iOS: you need certain entitlements to perform this operation.
Obviously it's not as simple as in Android where you're already inside a Linux shell under the covers, but there's no technical requirement I've read here that should mandate emulation.
Aside from the above, the syscall layer alone would be much more useful than bundling emulation into the picture that we know is going to perform poorly.
An aarch64 Linux rootfs on the A12x would have me throwing my money at one right now.
I mean, what's wrong with the requirements that I mentioned? It's fundamentally impossible to run these binaries unaltered and still hook syscalls, which means that emulation is required.
I'm not really experienced with iOS' underlying architecture, so I'll happily take your word for it - it's just that the linked thread mentions that virtualization is possible but not but sort of.
You are coming to mostly correct conclusions here, but frankly all of your explanations for this are confusing and most of them are incorrect :(.
> if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator
I had considered a very sketchy solution for this for a personal project (from the App Store's perspective) of what would be the equivalent of hacking the package manager to only install my packages which I sign beforehand with my certificate, which kinda allows installing arbitrary things to the extent of "what I have decided to compile and sign".
> The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed.
There are two "signing" issues here which really are the same but I've separated out because I felt it to be appropriate, though in reality the second shouldn't occur: one is loading unsigned, arbitrary code from say a package you just downloaded, and one is modifying the execution of the program to emulate syscalls. If you somehow got iOS to load and execute your unmodified unsigned ELF executable, then you'd have to emulate system calls in some way, which I suggested you could do by performing the modifications you'd normally perform before even signing the binary at runtime by manually patching syscalls in executable memory (which requires JIT).
Or jailbroken iOS for that matter (at least when I last did a jailbreak which was quite some years ago, I honestly don't know about the current situation)
I might do that again sometime. It's not urgent though, and I wouldn't switch to Android just for that. But I keep an eye on the jailbreak community.
I also really like the idea of having a portable keyboard and screen to turn my phone into a little development machine. I think the CPU is actually more powerful than my old 2012 MacBook, although it doesn't have as much RAM.
There’s a number of apps on the App Store already that allow exactly this. Two of my personal favorites are Blink and Termius (use them both, but for different reasons).
It runs a Linux kernel on top of the Windows one, without processor emulation, so you could say it translates Linux calls and semantics to Windows' control of resources.
However, it didn't gain any significant use, and is apparently abandoned.
It would be more accurate if they called it the Windows Subsystem for Linux Apps.
If you give a Linux program a complete syscall interface, it will run (provided it has its' libraries and a libc to work with).
I just want to run neovim and use its terminal emulator and a few cli tools.
> I just want to run neovim and use its terminal emulator and a few cli tools.
This is doable with the project as it is currently.
I'd still happily pay the yearly Apple developer tax to side load until Apple ends up shipping one when it transitions from x86 to ARM. ;)
AFAIC rolling your own hypervisor is technically feasible just would not be very performant.
There’s also this interesting project:
Noah is a Darwin subsystem for Linux, or "Bash on Ubuntu on Mac OS X". Noah is implemented as a hypervisor that traps linux system calls and translates them into Darwin's system calls. Noah also has an interpreter of ELF files so that binary executables of Linux run directly and flawlessly without any modifications.
https://github.com/linux-noah/noah
https://events.static.linuxfound.org/sites/events/files/slid...
All I’m saying is that it would be nice if iSH customized the keyboard the same way.
I think it's a much more practical approach, especially given that Apple seems to be okay with it on their App Store. However, it does leave some things to be desired that'd be totally catered to by the iSH approach, assuming it develops into something much more complete (I tried the TestFlight and while a basic environment was present a lot of things that'd make for a useful environment didn't seem to be implemented).
Not that I disagree, but would you be willing to provide some insight into what you personally felt was missing?
I haven't made any case to Apple…this is not my software.
Now, in this day of so much fake news, I wouldn't be surprised that all the happy comments I read are by Microsoft and, now, iOS shills but it's an observation I've made.
Meanwhile the non-phone computer market is shrinking each year, and what remains is mostly a market for devices that are good at running browsers.