3 ms·

As I understand it, these apps allowed running custom code from the app, and that has always been disallowed.

ramesh31 7mo ago
>"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.
- sheept 7mo ago
  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 7mo ago
    > 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.
- wvenable 7mo ago
  > 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 7mo ago
    Wechat works on iPhone
    - F7F7F7 7mo ago
      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- 7mo ago
    If we had to live with this rule during the "classic" Mac era, it would have disallowed HyperCard.
- wat10000 7mo ago
  What's lacking in the sandboxing?
TSUTiger 7mo ago
there are terminal type apps in the app store though?
- circuit10 7mo ago
  Not sure why this is downvoted, it's true: https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/a-shell/id1473805438 https://apps.apple.com/us/app/a-shell/id1473805438
  - nozzlegear 7mo ago
    Those are terminal emulators, not actual terminals. You can't fork or exec on iOS/iPadOS, so they're not actually running e.g. a python process, they're just running python interpreter.
    - Asmod4n 7mo ago
      ish runs a full blown x86 alpine linux distro.
      - jasomill 7mo ago
        As I understand it, ish implements x86 instructions and Linux syscalls as functions and translates running programs into arrays of calls to these functions, so all the machine code that will ever run is included in the app bundle, which at least satisfies the rules iOS enforces at runtime. As for the rules as written, I suppose you could make reasonable arguments either way.
    - circuit10 7mo ago
      I don't think it matters if you can fork or exec, they're still running custom code
vmg12 7mo ago
Other than exceptions like Roblox
echoangle 7mo ago
Maybe disallowed but definitely not enforced. There’s an app called Pythonista that has allowed you to run arbitrary python code for years.
- trillic 7mo ago
  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 7mo ago
    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 7mo ago
  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.
victorbjorklund 7mo ago
Not entirely. There is scriptable which allows you to run custom JS
MarceliusK 7mo ago
[dead]

>"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.

sheept 7mo ago
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 7mo ago
  > 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.
wvenable 7mo ago
> 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 7mo ago
  Wechat works on iPhone
  - F7F7F7 7mo ago
    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- 7mo ago
  If we had to live with this rule during the "classic" Mac era, it would have disallowed HyperCard.
wat10000 7mo ago
What's lacking in the sandboxing?

TSUTiger 7mo ago

there are terminal type apps in the app store though?

circuit10 7mo ago
Not sure why this is downvoted, it's true: https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/a-shell/id1473805438 https://apps.apple.com/us/app/a-shell/id1473805438
- nozzlegear 7mo ago
  Those are terminal emulators, not actual terminals. You can't fork or exec on iOS/iPadOS, so they're not actually running e.g. a python process, they're just running python interpreter.
  - Asmod4n 7mo ago
    ish runs a full blown x86 alpine linux distro.
    - jasomill 7mo ago
      As I understand it, ish implements x86 instructions and Linux syscalls as functions and translates running programs into arrays of calls to these functions, so all the machine code that will ever run is included in the app bundle, which at least satisfies the rules iOS enforces at runtime. As for the rules as written, I suppose you could make reasonable arguments either way.
  - circuit10 7mo ago
    I don't think it matters if you can fork or exec, they're still running custom code

vmg12 7mo ago

Other than exceptions like Roblox

echoangle 7mo ago

Maybe disallowed but definitely not enforced. There’s an app called Pythonista that has allowed you to run arbitrary python code for years.

trillic 7mo ago
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 7mo ago
  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 7mo ago
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.

victorbjorklund 7mo ago

Not entirely. There is scriptable which allows you to run custom JS

MarceliusK 7mo ago

[dead]