3 ms·

Doesn't Apple's ToS prohibit writing apps in any language other than Objective-C? Or using other than Apple's tools?

by valevk 13y ago

protomyth 13y ago
No they do not
deleted 13y ago
[deleted]
fidotron 13y ago
No, a lot of games are C# (Unity) or Lua (Corona). The thing they are understandably hissy about is downloading new scripts off the net and executing those, and they want to be sure that when they test something it's 100% representative of what the consumer experiences. (This gets really damn fuzzy when people want to do A-B testing in iOS apps). Not sure of the state of the fine print these days, but it's like many of these things where if you understand why they do it (not necessarily agree with it) it's not too hard to work within that framework. As a consequence if you even look like you might be executing arbitrary code they might reject you.
bjustin 13y ago
The app store agreement did at one point. It hasn't for a while now.
pudquick 13y ago
No. They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable). They also (generally) prohibit interpreters that download code from the network and execute it. If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently). They just want to make sure that the executable code that ships in your iOS app is all they have to worry about, that it can't generate access to system libraries/routines that were not present when submitted to them. This is why things like Pythonista and LuaBox are in the store currently, in addition to many apps written in other languages with other IDEs (Xamarin, etc.)
- jevinskie 13y ago
  Yep. These are the relevant lines from the policy: 2.7 Apps that download code in any way or form will be rejected 2.8 Apps that install or launch other executable code will be rejected And I suppose this covers use of W^X / mprotect: 2.5 Apps that use non-public APIs will be rejected
  - teacup50 13y ago
    mprotect() simply returns EPERM. The kernel enforces W^X; once a page has gone writable, it can never be executable, and vis versa.
teacup50 13y ago
It used to. They changed it, fortunately.

Doesn't Apple's ToS prohibit writing apps in any language other than Objective-C? Or using other than Apple's tools?

by valevk 13y ago

Doesn't Apple's ToS prohibit writing apps in any language other than Objective-C? Or using other than Apple's tools?

protomyth 13y ago

No they do not

deleted 13y ago

[deleted]

fidotron 13y ago

No, a lot of games are C# (Unity) or Lua (Corona). The thing they are understandably hissy about is downloading new scripts off the net and executing those, and they want to be sure that when they test something it's 100% representative of what the consumer experiences. (This gets really damn fuzzy when people want to do A-B testing in iOS apps). Not sure of the state of the fine print these days, but it's like many of these things where if you understand why they do it (not necessarily agree with it) it's not too hard to work within that framework. As a consequence if you even look like you might be executing arbitrary code they might reject you.

bjustin 13y ago

The app store agreement did at one point. It hasn't for a while now.

pudquick 13y ago

No. They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable). They also (generally) prohibit interpreters that download code from the network and execute it. If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently). They just want to make sure that the executable code that ships in your iOS app is all they have to worry about, that it can't generate access to system libraries/routines that were not present when submitted to them. This is why things like Pythonista and LuaBox are in the store currently, in addition to many apps written in other languages with other IDEs (Xamarin, etc.)

jevinskie 13y ago
Yep. These are the relevant lines from the policy: 2.7 Apps that download code in any way or form will be rejected 2.8 Apps that install or launch other executable code will be rejected And I suppose this covers use of W^X / mprotect: 2.5 Apps that use non-public APIs will be rejected
- teacup50 13y ago
  mprotect() simply returns EPERM. The kernel enforces W^X; once a page has gone writable, it can never be executable, and vis versa.

teacup50 13y ago

It used to. They changed it, fortunately.