Looks like you have to compile it yourself (meaning you need a mac with Xcode) or install it through testflight. Although I'm surprised that it's even allowed on testflight. iOS doesn't allow you to execute code of any kind locally, which is why if you download a "learn python" app or something it has to send your code off to a server, execute it, and then send you back the result.
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.
Since last year Apple have allowed executing user-input code providing the application is designed for teaching programming, https://twitter.com/palmin/status/871980560943636480 has a summary. I can't link to the actual doc since that's behind a login.
I'm not sure how this app would be allowed though.
Pythonista has been on the App Store for 6 years. The first programming environment on the iPad I ever used was Codea which is based on Lua which was released in 2011, but there are many more. Genuine programming environments directly hosted on iOS have been around for a long time.
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.
I make the argument that this application downloads and emulates code that is user-editable in the form of x86 binaries, which is the same as Pythonista or similar downloading and running Python code.
I would think Apple themselves are looking into this (probably on the processor level as they control that now) for iOS; in order to make it more free for devs / users while having software run securely sandboxed, they need a way of running 'anything' securely. So I don't think they mind users testing out different ways of making it work and learn from it.
Does that processor have hardware support for it already but Apple just doesn't do software support? So they can only use it themselves?
Sorry, I don't quite understand your question. Are you asking whether Apple has put support in their processors for running arbitrary code inside a sandbox?
I think they do, at least recent ones should. I don't think Apple has explicitly documented this anywhere, but I recall reading something like this recently.
TestFlight builds to my knowledge only have to pass the automated scan. As such, as long as the dev isn’t using private APIs or doing other forbidden things that can be statically scanned for, it’ll get past that point.
I don't think that was a very deep look at the app, especially since you have to know how to use a Linux prompt to understand that this app is an emulator.
> I don't think that was a very deep look at the app
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.
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.
It's a quite popular term, but only within media fandoms. So if you don't fancy searching for clues in each single frame of a new episode of $TV_SHOW and arguing with strangers on the internet about how to interpret the exact wording in that dialogue, you probably haven't come across it yet.
it took a decade to "be allowed" and is still extremely rudimentary, not to mention its a very fine line to the point that mozilla and google still wont invest in a browser engine port because apple already told in the past that simply running JS in the browser is enough to breach their policy. so please stop shouting like its common place.
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!
> mozilla and google still wont invest in a browser engine port
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.
While you're right that JIT isn't allowed on App Store, the issue with browser is you can only use built-in Safari webview for rendering websites. So all browsers on the App Store is a shell for Safari webview
My argument stands even if the "you must use WebKit" guideline is dropped. There's no point in writing a browser without WebKit because you just can't get good performance out of it.
Please don't spread misinformation, there have been very usable and capable dev environments available on the iPad since soon after it came out and their capabilities and access to features has been expanding steadily.
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.
> there have been very usable and capable dev environments available on the iPad
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.
Hardware hacker here, I can give you a few reasons. iPhones are designed to "just work" which is what I want in my main communications device. Sure, I could take one of the half-dozen SBCs on my work bench and turn it into a working cellphone with some parts and some sketchy code and a prayer or two, but I wouldn't want to rely on it daily.
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.
Did everyone just forget about the recent security chip deployment by Apple that literally makes it so you can't boot Linux from the internal ssd?
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.
> Did everyone just forget about the recent security chip deployment by Apple that literally makes it so you can't boot Linux from the internal ssd?
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.
The default setting is to only allow booting from your current macOS installation or from another macOS installation that is signed by apple and currently trusted (requires an internet connection to verify).
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.
Certainly, anyone may choose the hardware they like.
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 ...
>a future where true general purpose computing starts to disappear
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.
Not at all. If anything, the more companies like Microsoft and Apple push for locked down systems, the more open source SBCs and hobbyist computers we'll see. There will always be a market for open computers, and the past few years have seen an explosion in that market.
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.
I'd imagine that the majority of people who want to run a terminal on iOS would have access to a Mac and Xcode, so even if this can't be released on the App Store, it could still be a useful project for many.
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.
All the scripts, code, and interpreters are packaged in the app bundle, since it's emulating x86 binaries. The "additional functionality" guideline is a bit loose because companies download patches (for A/B testing, bug fixes) all the time, which doesn't go through App Store review.
"All the scripts, code, and interpreters" are not, in fact, packaged with the app as you are able to download arbitrary binaries using curl/wget or apk. That clause is very clear in both wording and intention, and this application does not follow it.
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).
> "All the scripts, code, and interpreters" are not, in fact, packaged with the app as you are able to download arbitrary binaries using curl/wget or apk.
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.
You are making a distinction that this clause went far out of its way to keep you from making :/. When Apple says "scripts" and "code" they are absolutely and clearly talking about the code that is being interpeted, not the interpreter itself (which they call "interpreters").
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).
> When Apple says "scripts" and "code" they are absolutely and clearly talking about the code that is being interpeted, not the interpreter itself (which they call "interpreters").
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.
> They can't be, because all of these are lumped together in the category of "must be bundled with the app".
...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.
Why run x86 Linux binaries? Wouldn’t it be easier and more efficient to run ARM binaries? Then you’d only need syscall translation, no? I guess you would also need a thuniking layer to handle binary format/ABI differences. But that would still be better in terms of time and space than emulation I would think.
I'm still not convinced. Even something like early VMware that scanned for the gnarly pieces that break Popek&Goldberg but just passes through most instructions should be better. In this case probably just syscall, some crazy system register reads that might return different things (but there aren't many of those in AArch64 EL0), and enough thunks that code can pretend it's executing at it's original location. Hell, equally sized RISC instructions should mean you can more quickly scan code than VMWare had to put up with doing crazy CISC decode just find out if they need to translate an instruction or not.
You can't do the thing you are suggesting because that would require being able to take those instructions that are being "passed through" and run them, which would require marking them executable. What you would effectively end up having to do is write an emulator for ARM, at which point you haven't gained anything. Choosing x86 was a really sane choice given how many existing tools and packages are available for x86 (though ARM is, of course, becoming more popular and accessible).
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.
> there's no technical requirement I've read here that should mandate emulation
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.
You're confidence about this makes me not doubt that you're correct, but the linked thread doesn't really discuss this in enough detail that it's clear that running a native sandbox is not possible.
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.
The fundamental argument is that you will need emulation at some point because every syscall needs to be hooked, so you need to be able to stop before a system call is executed and respond appropriately. If you are running native code, you'd need to change the binary at runtime to do something else instead of the syscall, which means you're essentially writing to executable memory.
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. If you were going to limit this app to the code that was shipped with the app you could also just replace the syscall instructions as part of the same pass that signed the binaries. Even 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.
You are coming to mostly correct conclusions here, but frankly all of your explanations for this are confusing and most of them are incorrect :(.
I maintain that I mostly understand what is going on here, but I'll concede the point that my explanations are confusing and/or not directly to-the-point. You're much better at explaining things than I am ;)
> 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).
So it's mainly an iOS limitation? I don't understand why it shouldn't be possible to take the same route software like WINE or WSL have taken before on a less constrained OS like macOS.
Yes, this is mostly an iOS limitation rather than a hardware one. There are many ways to make something like this work if iOS allowed things like forking processes or JIT (for App Store apps)–actually if this was possible, the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.
> the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.
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 kind of miss being able to SSH into my iPhone and run scripts, or just poke around the filesystem. It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. That was about 8 years ago.
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.
> It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server.
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).
Oh yeah, thanks, I was looking at Blink earlier. Haha actually I don't really need it, so I didn't install it. It was more about the feeling of "hacking" my device and doing something that it wasn't supposed to do. And having a real shell with access to the iOS file system, where I could script the phone to do all kinds of things, and write little programs that could run on a cron schedule. Stuff like that. For example, I wrote a little script that would change my iOS wallpaper once every hour, and it would take the images from a Dropbox folder.
I wonder to what extend it's possible to include every executable from the standard apt-get ARM repository (but not any other resources) in the app. Since the code is included at compile time and bundled with the App, Apple should allow it. Then one could add some sort of apt-get shim that fetches the non-code resources and installs them; and something to catch system calls (which could maybe be overridden at compile time as well).
FWIW, without nitpicking your language (as it is clear what you are saying, and the question is a totally legitimate one), the answer is "yes: that would absolutely be possible".
Not if the resulting executable is on the order of tens of gigabytes in size, or if the executables use features that aren't available/allowed in iOS (like runtime code generation and execution).
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.
WSL isn't Linux, it's an re-implementation of the Linux kernel syscall table, that translates them to the Windows equivalent. It allows userspace Linux programs to run on Windows.
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).
iOS doesn't have Hypervisor.framework like macOS does, unfortunately, which makes a project like this significantly more difficult. Hence the need for an emulation layer. However,
> 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've described why this doesn't work when this thread came up earlier today: https://news.ycombinator.com/item?id=18425906. In essence, you will need an emulation layer anyways, so it doesn't really matter whether you're running x86 or ARM.
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.
It would be awesome if they let you type commonly used symbols with the swipe down feature like in Swift Playgrounds—then you would not have to go through multiple screens full of characters to get the angle bracket or curly braces.
Swift Playgrounds changes the symbols that you can type with the keyboard in that mode. Normally, you can’t type curly braces or angle brackets on the first level of the iOS keyboard, but you can in Swift Playgrounds (and when entering LaTeX into Pages).
All I’m saying is that it would be nice if iSH customized the keyboard the same way.
Can't you run ARM binaries straight? No need to emulate the CPU. Same as Wine runs Windows programs without emulating it (as long as it's used on x86 arch).
You can, but not in the way you'd expect. Codesigning is a big issue, but one that can be circumvented if everything is signed in advance, though you probably wouldn't be able to publish to the App Store. But specifically for an app like this, you'd need an emulation layer: https://news.ycombinator.com/item?id=18425906
I doubt it. Alpine Linux would need to support Steam (which I don't think it does?) and then this project would need to implement all the syscalls to make this work, which hasn't quite been done yet. Plus it will be really slow.
By "Alpine Linux", I meant "the stuff that Alpine Linux usually ships with", which I doubt is rich enough to support everything that Steam needs, plus you're not going to get a nice package to install as you might on another distribution: https://developer.valvesoftware.com/wiki/Steam_under_Linux. So I'm pretty sure the answer to the original question is still "no, not yet", though I don't think it is "no, not ever".
You still don't seem to get it: this project happens to ship with an Alpine Linux userland, but you can just build it with Ubuntu Core instead, it will just be insanely large. Alternatively, you can just download Ubuntu Core and either replace the Alpine parts or put it in a chroot. Steam isn't going to run because it doesn't have a graphics layer, but it isn't because this is somehow--and I mean right now as it is installed on your phone without even having to reinstall it--in any way tied to Alpine Linux.
I do realize that this is using Alpine because it's small and easy to package, and that it's not in any way tied to Alpine. I wouldn't be surprised if you could do this on device right now by nuking the folder (which is helpfully exposed through Files) and unpacking a Debian filesystem into there. And I doubt any games will run at all, even if you do this, because emacs doesn't work currently due to missing system calls. My response was basically saying that along with "Alpine Linux likely doesn't support Steam, so if you download the app you won't be able to install it easily."
This reminds me of Blink Shell, an iOS "shell" that primarily features ssh and mosh. It also implements a bunch of shell commands (a selection of coreutils and netutils), running natively, but with a shim for `system()'. The idea is that you get a shell environment with the same tools (or almost the same tools) as you would on a traditional *nix system.
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 GP, but most of the apps I tried to install and execute I got “Bad System Call” notices from (some going so far as to crash init too). I reported one of those apps to the developer and they indicated it’s fixed on master, but I’ve not had a chance to compile yet (and developer said the same about an updated TestFlight build). Vim was one of the few things that worked decently well, but without a Bluetooth keyboard for Esc it was a little painful. I really like this project so I intend to get builds up and going soon and will be filing much more detailed bug reports (and ideally PRs) soon.
It seems like no one wants to run Linux or its applications lately and they seem happier when Microsoft develops Windows applications and operating system things to handle Linux things. Now Linux apps run on iOS and it's starting to sound like Linux people are happy to see their stuff built by others and running on everything but Linux.
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.
I think much of this is Microsoft and Apple attempting to retain marketshare. Niether has well maintained, vast software archives like Debian, or instant rollback after a package install or update like SUSE (thanks to btrfs and zypper).
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.
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...