>> What you get is a .c source regardless of >> the -gc mode, but the problem is that we're >> running a translator from .prg to .c. In that >> sense it should not make a difference. >> > Yes, but this translator is run only once, during program build, from there on > it is a pure machine code executable. > > I think the problem with Apple is that they don't want the VM running on > iPhone/iPad because they cannot be sure the code does not contain malicious > parts/virus/exploits and so on.
Most importantly they want to keep staying in control of their own platform. [ BTW even with -gc3, the VM has to be there and running. ] >> The other thing is that if you want to access >> any Apple API from .prg, it's inevitable >> to go through a set of wrapper functions, which >> is again something Apple seems to not like, >> because this way they are in the hands of wrapper >> developers regarding what feature is accessible >> from .prg code and how fully it is implemented. >> > I don't think so, you simply have some .c code which is a wrapper to something > that, in the end, becomes a .c source which gets compiled/linked to a pure cpu > specific assembler code. Apple want to keep out any extra layers between their API and application code. We can bend things however we want, but at the end, the extra layer will just be there, since you cannot make direct calls from .prg to Apple API. My emphasis from Section 3.3.1: "Applications must be originally written in Objective-C, C, C++, or JavaScript" "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited." >> At least that's Apple's intent. As to how they >> can defend these rules "in court", I have no idea. >> > They don't defend it in court, they simply will not put your program on > iTunes, so you cannot distribute it. Yes, and/or if they find out about such practice they have the right to suspend your account I suppose. Question is how they can find it out, and what methods do they use to find it out, and if any developers want to make a risk here to push Apple and the license rules to the limits. Interesting reads: http://daringfireball.net/2010/04/why_apple_changed_section_331 http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler (with other affected tools listed and linked) Discussion on MonoTouch forum: http://forums.monotouch.net/yaf_postst645.aspx One more important thing to add is that 3.3.1 section only applies to Standard licensing, and it doesn't for Enterprise licensing, which means you can develop an internally distributed (non-iTunes Store) application without being affected by this rule. Another thing to add is there is quite a lot of confusion and uncertainty regarding the matter, so it's worth to see what comes out of it at the end. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
