Hacker News Reader

Comment by mikenew | Hacker News Reader

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.

*https://www.theregister.co.uk/2017/06/07/apple_relaxes_devel...

View on HN

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.

You can get a lot past the TestFlight review, which seems to be automated now. Probably just checks for API abuse and whatnot.

Getting to App Store is a human review.

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?

They are asking if the A series Apple chips have virtualisation features like Intel VT-x

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.

I like that argument. I wonder if Apple will.

Well, it's on TestFlight already, so it's already passed one round of Apple's screening.

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.

I haven’t heard the term headcanon before.

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.

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.

That's a pretty arbitrary exception especially when Apple wants us to believe that iPads have made "computers" obsolete.

Not only can you run python on your iPhone, natively, with Pythonista, but you can call python scripts in Pythonista via Siri Shortcuts.

“Siri deploy heroku”?

Siri Shortcuts can natively run SSH commands now, so that is actually a real possibility.

Sure, if you set it up that way!

> iOS doesn't allow you to execute code of any kind locally

Yes, it does. And as of recently you can even put apps like this on the App Store!

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.

This isn't true either. https://github.com/jcs/endless

The Github page says it's a wrapper around UIWebView, so it's still a form of WebKit provided by iOS.

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.

>Usable and capable compared to what?

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.

> Compared to pretty much anything - honestly

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.

In what way? I’d love to know, I can do a ton from Python but if the dev story on Android is significantly better I’m definitely interested.

I personally can't believe why Apple is still so popular in a place called "Hacker News".

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.

    Startup Security Utility -> Secure Boot -> No Security

https://support.apple.com/en-us/HT208198

Booting != installing

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 find this project to be pretty interesting, don't you? I think this makes it meet the bar for the guidelines.

Comment is about Apple, not about the project.

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.

> mozilla and google still wont invest in a browser engine port

Gecko runs just fine on iOS.

Wait, this is news to me. I was under the (probably erroneous) assumption that Firefox on iOS was running under webkit. Am I wrong?

Firefox for iOS is built on WebKit.

Gecko runs just fine on iOS; it just isn't deployed.

Took a few Google search iterations but I found this: https://hg.mozilla.org/users/tmielczarek_mozilla.com/gecko-i...

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?

Looks like it was abandoned. One of the last commits was “Disable the JIT on iOS because it’s busted”.

Uh. There’s definitely a local python interpreter on the App Store. Pythonista3 is one, and Blink has one as well iirc.

Yes, and python isn't JIT'ed, so it really doesn't matter. It all boils down to write XOR exec memory.

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.

You would also need a paid developer account if you didn't want to constantly resign the app.

Opening Xcode once per week and pressing CMD+R is likely not a big problem for the target audience either.

> I think this kind of shell environment is still against the app store guidelines

How so? I see no guidelines this app is violating.

Apple Developer Program License Agreement:

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.

Reply on news.ycombinator.com