3 ms·

How does that get around the iOS App store restriction on interpreted code?

by chadzawistowski 12y ago

rsynnott 12y ago
I assume they got around that restriction by cunningly releasing it after that restriction was abandoned in 2010...
- chadzawistowski 12y ago
  Ah, my inexperience with Apple's platforms is showing.
AceJohnny2 12y ago
Is that still a thing? I thought they relented?
edvinbesic 12y ago
I belive that restriction was lifted quite a while ago, like in 2010 or something. It didn't last long as game engines required the use of scripting languages for game logic, among other things. Apple simply had to cave in.
- paines 12y ago
  Excuse my ignorance, but what about the new situation that all apps MUST use ARC. Does that interfere with lets say embedded Lisps in Apps etc...
  - coob 12y ago
    You don't have to use ARC. You can reference count manually if you like. What you can't do is use the old garbage collection (which was only ever available on OS X).
    - rsynnott 12y ago
      And in fact you _can_ still use the old garbage collection if you really want to; you just won't be able to submit new apps to the OS X app store.
  - rsynnott 12y ago
    Apple no longer allow use of Objective C garbage collection on the MacOS App Store (it was never supported on iOS). This doesn't effect third-party garbage collection and there's no requirement for third-party languages to use ARC (it wouldn't be practical for most of them, anyway, though there is an AOT-compiled Ruby that uses it).
    - paines 12y ago
      Thank you!
fulafel 12y ago
The restriction was reformulated to something like "you can't allow dynamic code loading over the net" or something. So as long as the app ships with the example snippets it runs and otherwise works only with user input, it should be politically correct. Edit: reference: http://seattleclouds.com/ticketfiles/8665/ios_program_standard_agreement_20120912.pdf http://seattleclouds.com/ticketfiles/8665/ios_program_standa... 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." So in fact the Lisp app is also forbidden (but of course Apple is free to selectively enforce)
- rsynnott 12y ago
  This seems to be done on a "spirit of the agreement" basis; they're okay with the various python REPL languages even though you can do things like eval(urlopen("http://bla.com/some_python.py" http://bla.com/some_python.py").read()), for instance.
  - fulafel 12y ago
    Ah, I didn't even think that far, I stopped at any REPL being a violation since it's running code which was not packaged with the app.

How does that get around the iOS App store restriction on interpreted code?

rsynnott 12y ago

I assume they got around that restriction by cunningly releasing it after that restriction was abandoned in 2010...

chadzawistowski 12y ago
Ah, my inexperience with Apple's platforms is showing.

AceJohnny2 12y ago

Is that still a thing? I thought they relented?

edvinbesic 12y ago

I belive that restriction was lifted quite a while ago, like in 2010 or something. It didn't last long as game engines required the use of scripting languages for game logic, among other things. Apple simply had to cave in.

paines 12y ago
Excuse my ignorance, but what about the new situation that all apps MUST use ARC. Does that interfere with lets say embedded Lisps in Apps etc...
- coob 12y ago
  You don't have to use ARC. You can reference count manually if you like. What you can't do is use the old garbage collection (which was only ever available on OS X).
  - rsynnott 12y ago
    And in fact you _can_ still use the old garbage collection if you really want to; you just won't be able to submit new apps to the OS X app store.
- rsynnott 12y ago
  Apple no longer allow use of Objective C garbage collection on the MacOS App Store (it was never supported on iOS). This doesn't effect third-party garbage collection and there's no requirement for third-party languages to use ARC (it wouldn't be practical for most of them, anyway, though there is an AOT-compiled Ruby that uses it).
  - paines 12y ago
    Thank you!

fulafel 12y ago

The restriction was reformulated to something like "you can't allow dynamic code loading over the net" or something. So as long as the app ships with the example snippets it runs and otherwise works only with user input, it should be politically correct. Edit: reference: http://seattleclouds.com/ticketfiles/8665/ios_program_standard_agreement_20120912.pdf http://seattleclouds.com/ticketfiles/8665/ios_program_standa... 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." So in fact the Lisp app is also forbidden (but of course Apple is free to selectively enforce)

rsynnott 12y ago
This seems to be done on a "spirit of the agreement" basis; they're okay with the various python REPL languages even though you can do things like eval(urlopen("http://bla.com/some_python.py" http://bla.com/some_python.py").read()), for instance.
- fulafel 12y ago
  Ah, I didn't even think that far, I stopped at any REPL being a violation since it's running code which was not packaged with the app.