Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And this also illustrates why Apple forbids any kind of iOS app that lets a user write and execute code.


Maybe I don't see your point, but an iOS app could execute code locally. The only risk is the device owner could compromise the device. There is no [additional] risk of another user doing so.


The browser's Javascript console also only runs code locally, but getting people to copy code into it is a serious attack vector.

Not saying that's Apple's reason, but being limited to local execution doesn't mean it's safe.


Because javascript run locally can connect to the internet, and if it put into the console within the page on a domain that is storing secrets in local storage/cookies, it can scoop up all your credentials or other private information and send them to some other server. Unrestricted local execution can give up full access to local user's accounts, so is not good. Server execution can do that and also maybe impact other users.


Apple forbids that because it wants to be able to control and validate applications on their store. If they allowed self-modifying code apps could auto-update and change their features post-install. This is not really related.


Except that hasn't been true for years in certain circumstances, particularly where the value of an app running user-created code is educational in nature. See Pythonista, Codea, Swift Playgrounds, or hell, Shortcuts.


Shortcuts, and Swift Playgrounds even more so, have been granted private entitlements by Apple to function.


What about Codea and Pythonista?


They don’t run native code.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: