| ▲ | peddling-brink 15 hours ago |
| As I understand it, these apps allowed running custom code from the app, and that has always been disallowed. |
|
| ▲ | vmg12 14 hours ago | parent | next [-] |
| Other than exceptions like Roblox |
|
| ▲ | echoangle 14 hours ago | parent | prev | next [-] |
| Maybe disallowed but definitely not enforced. There’s an app called Pythonista that has allowed you to run arbitrary python code for years. |
| |
| ▲ | trillic 13 hours ago | parent | next [-] | | I haven't been in the App Store ecosystem in a while, but the restriction is generally on running new Machine Code, all machine code needs to be signed on iOS. Interpreters get around this limitation, only the interpreter code that is compiled AoT and signed is actually running. This tracks as the reasoning behind a lack of other browser engines, nobody can get comparable performance without a JIT, which would be compiling net new machine code that wasn't shipped with the binary. The best way to handle this I would imagine within the current bounds of Apple's restrictions would be WASM. | | |
| ▲ | wat10000 13 hours ago | parent [-] | | Apps don't get removed for breaking that rule, though, because they can't break it in the first place. The system won't allow you to mark a freshly written page as executable. |
| |
| ▲ | _moof 13 hours ago | parent | prev [-] | | Years ago I watched a bunch of people stop an apartment building from being built. They did this by employing a legal concern that they didn't actually care about, but that they knew would stop the development in its tracks. It worked. That was the day I realized that for a lot of people, rules aren't actually rules. They're tools that they can use to stop something they don't like, no matter what the rule is really about. I think this is a disgusting attitude, but it's unfortunately the way a lot of people operate. So it might be that Apple has this "no external code" rule to stop things they don't like, and the category of "things Apple doesn't like" doesn't actually include every app that runs external code. It includes a lot of them, but for whatever reason Apple chose not to codify the details. Crummy if true, but I wouldn't be surprised. Every regulator I've ever dealt with leaves themselves an "I know it when I see it" escape hatch that lets them ban whatever they want. | | |
| ▲ | awakeasleep 12 hours ago | parent [-] | | If you read the actual rule the exceptions are relatively well defined. Stuff like pythonista falls into their educational/coding app exception as they define it | | |
| ▲ | NotPractical 11 hours ago | parent [-] | | The entire rule is as follows: 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 app completely viewable and editable by the user. There are not "exceptions"; there is one exception, and that's educational apps. But it's unclear why Pythonista is educational while the apps mentioned in the article are not. In fact, Pythonista is even listed in the "Productivity" section in the App Store. |
|
|
|
|
| ▲ | TSUTiger 14 hours ago | parent | prev | next [-] |
| there are terminal type apps in the app store though? |
| |
|
| ▲ | victorbjorklund 13 hours ago | parent | prev | next [-] |
| Not entirely. There is scriptable which allows you to run custom JS |
|
| ▲ | ramesh31 15 hours ago | parent | prev [-] |
| >"and that has always been disallowed". And it's always been a stupid rule. If I ship an app with a browser view, I can run any custom code I want in it. The rule is just a bandaid on Apple's lack of true sandboxing for apps. |
| |
| ▲ | wvenable 14 hours ago | parent | next [-] | | > The rule is just a bandaid on Apple's lack of true sandboxing for apps. That's not it at all. If an app can run arbitrary code then it can run other apps and that can by-pass the app store. They are specifically trying to prevent something like Wechat on the iPhone. It's not about security, it's about money and control. | | |
| ▲ | mciancia 14 hours ago | parent | next [-] | | Wechat works on iPhone | | |
| ▲ | F7F7F7 12 hours ago | parent [-] | | Wechat is large enough to be able to negotiate requirements with Apple. They are the gateway to an entire continent and close to 2 Billion users. And since they are a 'everything app' the frequency of use and reliance is likely compounded. Apple's not picking up the phone for 50 million users. So we shouldn't expect anything different here. Luckily there are other phones and mobile os's to develop for. |
| |
| ▲ | greyface- 13 hours ago | parent | prev [-] | | If we had to live with this rule during the "classic" Mac era, it would have disallowed HyperCard. |
| |
| ▲ | sheept 14 hours ago | parent | prev | next [-] | | That's because browsers are the most battle tested sandbox out there. It's not worth developing another sandbox if they already have Safari webview. | | |
| ▲ | Jyaif 14 hours ago | parent [-] | | > browsers are the most battle tested sandbox out there The most battle tested sandbox... after operating system. After all, browsers rely on the OS to provide the primitives for their sandboxes. And curiously those primitives are not exposed by iOS. |
| |
| ▲ | wat10000 13 hours ago | parent | prev [-] | | What's lacking in the sandboxing? |
|
