I was going to try and phrase this politely but I can't think of a
good way – this is total bullshit. I used to admire Apple, but there
is not technical/logical reason for them to insert this language into
the TOS. Hopefully Wax will fly under the radar though!
El 09/04/2010, a las 00:43, corey johnson escribió:
> I was going to try and phrase this politely but I can't think of a
> good way – this is total bullshit. I used to admire Apple, but there
> is not technical/logical reason for them to insert this language into
> the TOS. Hopefully Wax will fly under the radar though!
I hope the final 4.0 sdk is clear on this and also states the kind of clothes we have to be wearing while programming. Probably jeans and turtleneck.
On Fri, Apr 9, 2010 at 02:50, Grzegorz Adam Hankiewicz
<gra...@titanium.sabren.com> wrote:
> El 09/04/2010, a las 00:43, corey johnson escribió:
>> I was going to try and phrase this politely but I can't think of a
>> good way – this is total bullshit. I used to admire Apple, but there
>> is not technical/logical reason for them to insert this language into
>> the TOS.
A huge reason — Adobe Flash 5.
> Hopefully Wax will fly under the radar though!
Not likely. All languages except Objective C, C, C++ and JavaScript
are explicitly banned from the iPhone.
Anyone who uses anything else is risking rejection. I think this could
be worked around by hiding Lua sources in the executable, but that is
not the bullet proof solution.
> I hope the final 4.0 sdk is clear on this and also states the kind of clothes we have to be wearing while programming. Probably jeans and turtleneck.
I think that the changes in agreement are effective *immediately* as
you accept them, not when 4.0 is released.
And if you do not accept the changes before 22th April, you can't use
the provisioning portal.
Jeesh. Apple, why? Figures, I'm almost done with my app (that I
started on Tuesday), it'll take at least a week or two to transpose it
all to Obj-C (especially the wax.http.request stuff).
I for one will still submit with Wax and see what happens.
Ryan
On Apr 8, 4:56 pm, Alexander Gladysh <aglad...@gmail.com> wrote:
> On Fri, Apr 9, 2010 at 02:50, Grzegorz Adam Hankiewicz
> <gra...@titanium.sabren.com> wrote:
> > El 09/04/2010, a las 00:43, corey johnson escribió:
> >> I was going to try and phrase this politely but I can't think of a
> >> good way – this is total bullshit. I used to admire Apple, but there
> >> is not technical/logical reason for them to insert this language into
> >> the TOS.
> A huge reason — Adobe Flash 5.
> > Hopefully Wax will fly under the radar though!
> Not likely. All languages except Objective C, C, C++ and JavaScript
> are explicitly banned from the iPhone.
> Anyone who uses anything else is risking rejection. I think this could
> be worked around by hiding Lua sources in the executable, but that is
> not the bullet proof solution.
> > I hope the final 4.0 sdk is clear on this and also states the kind of clothes we have to be wearing while programming. Probably jeans and turtleneck.
> I think that the changes in agreement are effective *immediately* as
> you accept them, not when 4.0 is released.
> And if you do not accept the changes before 22th April, you can't use
> the provisioning portal.
On Thu, Apr 8, 2010 at 4:07 PM, Ryan <ryanleeschnei...@gmail.com> wrote:
> Jeesh. Apple, why? Figures, I'm almost done with my app (that I
> started on Tuesday), it'll take at least a week or two to transpose it
> all to Obj-C (especially the wax.http.request stuff).
> I for one will still submit with Wax and see what happens.
> Ryan
> On Apr 8, 4:56 pm, Alexander Gladysh <aglad...@gmail.com> wrote:
>> On Fri, Apr 9, 2010 at 02:50, Grzegorz Adam Hankiewicz
>> <gra...@titanium.sabren.com> wrote:
>> > El 09/04/2010, a las 00:43, corey johnson escribió:
>> >> I was going to try and phrase this politely but I can't think of a
>> >> good way – this is total bullshit. I used to admire Apple, but there
>> >> is not technical/logical reason for them to insert this language into
>> >> the TOS.
>> A huge reason — Adobe Flash 5.
>> > Hopefully Wax will fly under the radar though!
>> Not likely. All languages except Objective C, C, C++ and JavaScript
>> are explicitly banned from the iPhone.
>> Anyone who uses anything else is risking rejection. I think this could
>> be worked around by hiding Lua sources in the executable, but that is
>> not the bullet proof solution.
>> > I hope the final 4.0 sdk is clear on this and also states the kind of clothes we have to be wearing while programming. Probably jeans and turtleneck.
>> I think that the changes in agreement are effective *immediately* as
>> you accept them, not when 4.0 is released.
>> And if you do not accept the changes before 22th April, you can't use
>> the provisioning portal.
The app I have on the store now uses snprintf, since it's half written in plain old C. I wonder if I'll be banned from updating it at all with the "new regime".
On Fri, Apr 9, 2010 at 03:39, Grzegorz Adam Hankiewicz
<gra...@titanium.sabren.com> wrote:
> Even if the license was not in place, has anybody read the Appcelerator blog entry http://developer.appcelerator.com/blog/2010/03/the-apple-rejection-ec... It talks about an app being rejected for using sprintf/strncopy.
> The app I have on the store now uses snprintf, since it's half written in plain old C. I wonder if I'll be banned from updating it at all with the "new regime".
Um. My English is not good enough to express my emotions.
On Thu, Apr 8, 2010 at 4:46 PM, Alexander Gladysh <aglad...@gmail.com> wrote: > On Fri, Apr 9, 2010 at 03:39, Grzegorz Adam Hankiewicz > <gra...@titanium.sabren.com> wrote: >> Even if the license was not in place, has anybody read the Appcelerator blog entry http://developer.appcelerator.com/blog/2010/03/the-apple-rejection-ec... It talks about an app being rejected for using sprintf/strncopy.
>> The app I have on the store now uses snprintf, since it's half written in plain old C. I wonder if I'll be banned from updating it at all with the "new regime".
> Um. My English is not good enough to express my emotions.
> <...>Apple proposed updating its Terms of Service for iPhone OS 4.0
The § 3.1.1 in question is in the new "iPhone Developer Program License Agreement" which replaced the old version in "Legal Agreements" section in my "Member Center" as soon as I agreed to it. And there was a warning that if I would not accept to the agreement by April 22th, I'll loose access to the provisioning portal.
I think this agreement change is not related to the 4.0 release which would be released in summer and which I would not be forced to use until all previous versions of iPhone OS would no longer be supported.
>> <...>Apple proposed updating its Terms of Service for iPhone OS 4.0
> The § 3.1.1 in question is in the new "iPhone Developer Program > License Agreement" which replaced the old version in "Legal > Agreements" section in my "Member Center" as soon as I agreed to it. > And there was a warning that if I would not accept to the agreement by > April 22th, I'll loose access to the provisioning portal.
> I think this agreement change is not related to the 4.0 release which > would be released in summer and which I would not be forced to use > until all previous versions of iPhone OS would no longer be supported.
> Alexander.
> -- > To unsubscribe, reply using "remove me" as the subject.
On 9 April 2010 08:54, Federico Brubacher <fbrubac...@gmail.com> wrote:
> Ansca is saying that they are safe because they do all the compilation > in the developer machine and their binaries are pure Obj-c , Wax > wouldn't fall into this category afik, > http://blog.anscamobile.com/2010/04/do-apples-new-rules-affect-you/ > Do you guys agree with Ansca perspective ?
Well, it's easy for them: I believe they're simply collecting the .lua files, running them through luac, pasting the resulting C code into .c or .m files, and linking to liblua statically.
If they went the extra mile of obfuscation, they changed the lua_* prefixes into something else as well. Or, even easier, if liblua is linked statically it becomes just a matter of stripping symbols.
Wax is not a tool to facilitate cross-platform development; it's completely built for iPhone, Obj-C and Cocoa. I think it's technically and spiritually safe. And given the uproar, I'm completely positive that Apple will cave and re-flexibilise that clause.
For the time being, though, using luac, liblua.a and strip should be enough.
The new 3.3.1 doesn't single out cross-platform development; the way it's written, it seems clear that Wax is simply "not allowed." On the other hand, two things:
1. I don't think it's really been "allowed" ever since they changed the interpreted code clause to read "...download or use..." instead of "...download and use..." or whatever it was. But this hasn't prevented Wax apps from being accepted. 2. Even though cross-platform development isn't targeted explicitly, I think it's clear that this is really what Apple cares about.
So it's really just a question of enforcement, and we might be safe if Apple doesn't see Wax specifically as a threat.
All of these SDK TOS clauses read like so many other outlandish limitations in just about every EULA for every software product made in the last 20 years. The difference is that Apple doesn't need their TOS to hold up in a court of law (they already hold all the power with the app store), so they can actually implement these extreme measures without recourse.
Some chin-scratching about the future: my hope at this point is that the iP* platform becomes *so* popular that continuing with draconian and anti-competitive rules like this eventually invites an antitrust suit. IANAL, but a suit like that seems no less plausible to me than the one against Microsoft for bundling IE in Windows. But that would hinge on Apple's platform getting a lot more market share.
-James
On Apr 9, 8:21 am, André Braga <andrebr...@gmail.com> wrote:
> On 9 April 2010 08:54, Federico Brubacher <fbrubac...@gmail.com> wrote:
> > Ansca is saying that they are safe because they do all the compilation > > in the developer machine and their binaries are pure Obj-c , Wax > > wouldn't fall into this category afik, > >http://blog.anscamobile.com/2010/04/do-apples-new-rules-affect-you/ > > Do you guys agree with Ansca perspective ?
> Well, it's easy for them: I believe they're simply collecting the .lua > files, running them through luac, pasting the resulting C code into .c > or .m files, and linking to liblua statically.
> If they went the extra mile of obfuscation, they changed the lua_* > prefixes into something else as well. Or, even easier, if liblua is > linked statically it becomes just a matter of stripping symbols.
> Wax is not a tool to facilitate cross-platform development; it's > completely built for iPhone, Obj-C and Cocoa. I think it's technically > and spiritually safe. And given the uproar, I'm completely positive > that Apple will cave and re-flexibilise that clause.
> For the time being, though, using luac, liblua.a and strip should be enough.
I'm not sure that it's just about cross-platform development. I hear that the majority of support calls for Safari crashing is due to bugs in Flash that Adobe haven't fixed in a long time. I can see how they'd want to restrict the number of languages being used for development to a few that they can reasonably provide support for. While I think it's a stupid approach in a time of user forums, I can follow their reasoning. I just don't like it.
On Fri, Apr 9, 2010 at 4:58 PM, James MacAulay <jmacau...@gmail.com> wrote: > The new 3.3.1 doesn't single out cross-platform development; the way > it's written, it seems clear that Wax is simply "not allowed." On the > other hand, two things:
> 1. I don't think it's really been "allowed" ever since they changed > the interpreted code clause to read "...download or use..." instead of > "...download and use..." or whatever it was. But this hasn't prevented > Wax apps from being accepted. > 2. Even though cross-platform development isn't targeted explicitly, I > think it's clear that this is really what Apple cares about.
> So it's really just a question of enforcement, and we might be safe if > Apple doesn't see Wax specifically as a threat.
> All of these SDK TOS clauses read like so many other outlandish > limitations in just about every EULA for every software product made > in the last 20 years. The difference is that Apple doesn't need their > TOS to hold up in a court of law (they already hold all the power with > the app store), so they can actually implement these extreme measures > without recourse.
> Some chin-scratching about the future: my hope at this point is that > the iP* platform becomes *so* popular that continuing with draconian > and anti-competitive rules like this eventually invites an antitrust > suit. IANAL, but a suit like that seems no less plausible to me than > the one against Microsoft for bundling IE in Windows. But that would > hinge on Apple's platform getting a lot more market share.
> -James
> On Apr 9, 8:21 am, André Braga <andrebr...@gmail.com> wrote: >> On 9 April 2010 08:54, Federico Brubacher <fbrubac...@gmail.com> wrote:
>> > Ansca is saying that they are safe because they do all the compilation >> > in the developer machine and their binaries are pure Obj-c , Wax >> > wouldn't fall into this category afik, >> >http://blog.anscamobile.com/2010/04/do-apples-new-rules-affect-you/ >> > Do you guys agree with Ansca perspective ?
>> Well, it's easy for them: I believe they're simply collecting the .lua >> files, running them through luac, pasting the resulting C code into .c >> or .m files, and linking to liblua statically.
>> If they went the extra mile of obfuscation, they changed the lua_* >> prefixes into something else as well. Or, even easier, if liblua is >> linked statically it becomes just a matter of stripping symbols.
>> Wax is not a tool to facilitate cross-platform development; it's >> completely built for iPhone, Obj-C and Cocoa. I think it's technically >> and spiritually safe. And given the uproar, I'm completely positive >> that Apple will cave and re-flexibilise that clause.
>> For the time being, though, using luac, liblua.a and strip should be enough.
>> Cheers, >> A.
> -- > To unsubscribe, reply using "remove me" as the subject.
> 1. I don't think it's really been "allowed" ever since they changed > the interpreted code clause to read "...download or use..." instead of > "...download and use..." or whatever it was. But this hasn't prevented > Wax apps from being accepted. > 2. Even though cross-platform development isn't targeted explicitly, I > think it's clear that this is really what Apple cares about.
On a purely practical point of view, Lua is safe. It's completely impossible to think about modern (2000 to 2010) game development without some form of scripting. This is going to happen either via some DSL developed in-house, or via a 3rd party scripting language. And among 3rd party languages, Lua happens to be the most popular for game development, closely followed by Python.
The difference is that not even the Lua authors share/encourage the vision that Lua works fine as a stand-alone language, and always present the language on an embedding scenario.
That said, there is *no* classpath/common runtime library/Python kitchen sink/Ruby kitchen sink equivalent in the Lua world, so it's rather easy to argue that Lua is not a stand-alone development tool, but a scripting library on top of C that happens to provide facilities such as regular expressions, simple object orientation, closures, garbage collection and state-of-the-art associative maps.
What's left for argument is whether bridges such as Wax are also safe. I'd argue that they are, as long as they are fully embedded in the C code instead of living as shared libraries and interpretable source files.
Now, given Apple's recent usage of automated tools to audit the binaries, stripping them is a nice idea. Just to play safe.
Seriously Corey, thanks so much for Wax! I'll be really pissed if Apple rejects it, Wax is so nice. I really do think it would've taken me 2-3 weeks to get done what I did in 3 days using Wax.
My app will make all it's revenue from iTunes Store affiliate links (it's an app that scans your library and searches for new albums by artists you have), and I'm still waiting for my affiliate status as well, so talk about being fully at the mercy of Cupertino..
Thanks, Ryan
On Apr 9, 9:15 am, André Braga <andrebr...@gmail.com> wrote:
> > 1. I don't think it's really been "allowed" ever since they changed > > the interpreted code clause to read "...download or use..." instead of > > "...download and use..." or whatever it was. But this hasn't prevented > > Wax apps from being accepted. > > 2. Even though cross-platform development isn't targeted explicitly, I > > think it's clear that this is really what Apple cares about.
> On a purely practical point of view, Lua is safe. It's completely > impossible to think about modern (2000 to 2010) game development without > some form of scripting. This is going to happen either via some DSL > developed in-house, or via a 3rd party scripting language. And among 3rd > party languages, Lua happens to be the most popular for game > development, closely followed by Python.
> The difference is that not even the Lua authors share/encourage the > vision that Lua works fine as a stand-alone language, and always present > the language on an embedding scenario.
> That said, there is *no* classpath/common runtime library/Python kitchen > sink/Ruby kitchen sink equivalent in the Lua world, so it's rather easy > to argue that Lua is not a stand-alone development tool, but a scripting > library on top of C that happens to provide facilities such as regular > expressions, simple object orientation, closures, garbage collection and > state-of-the-art associative maps.
> What's left for argument is whether bridges such as Wax are also safe. > I'd argue that they are, as long as they are fully embedded in the C > code instead of living as shared libraries and interpretable source files.
> Now, given Apple's recent usage of automated tools to audit the > binaries, stripping them is a nice idea. Just to play safe.
> Seriously Corey, thanks so much for Wax! I'll be really pissed if > Apple rejects it, Wax is so nice. I really do think it would've taken > me 2-3 weeks to get done what I did in 3 days using Wax.
> My app will make all it's revenue from iTunes Store affiliate links > (it's an app that scans your library and searches for new albums by > artists you have), and I'm still waiting for my affiliate status as > well, so talk about being fully at the mercy of Cupertino..
> Thanks, > Ryan
> On Apr 9, 9:15 am, André Braga <andrebr...@gmail.com> wrote: >> Em 09/04/2010 11:58, James MacAulay escreveu:
>>> 1. I don't think it's really been "allowed" ever since they changed >>> the interpreted code clause to read "...download or use..." instead of >>> "...download and use..." or whatever it was. But this hasn't prevented >>> Wax apps from being accepted. >>> 2. Even though cross-platform development isn't targeted explicitly, I >>> think it's clear that this is really what Apple cares about.
>> On a purely practical point of view, Lua is safe. It's completely >> impossible to think about modern (2000 to 2010) game development without >> some form of scripting. This is going to happen either via some DSL >> developed in-house, or via a 3rd party scripting language. And among 3rd >> party languages, Lua happens to be the most popular for game >> development, closely followed by Python.
>> The difference is that not even the Lua authors share/encourage the >> vision that Lua works fine as a stand-alone language, and always present >> the language on an embedding scenario.
>> That said, there is *no* classpath/common runtime library/Python kitchen >> sink/Ruby kitchen sink equivalent in the Lua world, so it's rather easy >> to argue that Lua is not a stand-alone development tool, but a scripting >> library on top of C that happens to provide facilities such as regular >> expressions, simple object orientation, closures, garbage collection and >> state-of-the-art associative maps.
>> What's left for argument is whether bridges such as Wax are also safe. >> I'd argue that they are, as long as they are fully embedded in the C >> code instead of living as shared libraries and interpretable source files.
>> Now, given Apple's recent usage of automated tools to audit the >> binaries, stripping them is a nice idea. Just to play safe.
> -- > To unsubscribe, reply using "remove me" as the subject.
On 10 April 2010 01:09, Corey <probablyco...@gmail.com> wrote:
> Keep us updated on the status Ryan!
> Sent from my iPad
Nice :)
Since the iPad just got mentioned on a Section 3.3.1 thread... I've been ruminating quite a bit over the SDK agreement changes and everything points to something I've suspected ever since Apple "adopted" the LLVM project. This is not simply a matter of stalling Adobe via legalese and whoever else gets affected is but collateral damage in Apple's war against Flash; this is about deep stuff going on with OS X that will affect the very future of it, and the computing platforms it's used on, at the lowest level.
Consider the following scenario:
What if Apple's changes to Section 3.3.1 are only marginally related to Flash, MonoTouch and other "let's-circumvent-the-Objective-C-runtime" frameworks/RAD tools. Notice how the blessed languages match exactly what clang can compile, except for Javascript which is handled by Nitro.
I've been saying this for over an year now (and have some emails posted to public lists to prove it): what's happening here is that Apple is setting the stage to phase out GCC, leverage the expertise from the processor design companies they acquired to tune their ASICs to the compiler and their compiler to exclusive features they'll build into the ASICs as well (see: they don't call the A4 an ARM processor, they singled it out -- an otherwise black box component -- as a key piece of what makes the iPad experience so smooth, and they *really* control the whole widget now, down to the CPU and toolchain level!), and push the LLVM bitcode as a platform-neutral binary format. OpenCL was a strategy to get the HPC/GPU industry behind LLVM, and now Apple is going to bake the OpenCL ability of seamlessly targeting a number of processing units inside a computer straight into the (virtual) machine instruction level.
In other words, Apple is preparing their fifth architectural transition (68k -> PPC -> Intel -> ARM -> any); as their desktop/notebook/handheld platforms eventually converge at the hardware level, there will be a need to change things at the ABI level to make it all happen, a bunch of things will be deprecated by OS X 10.7, and their veto regarding 3rd party compilers (Adobe's version of LLVM) and frameworks getting anywhere closer to iPhone OS is Apple's quite emphatic way of avoiding the CodeWarrior/PowerPlant/Carbon64 situation all over again.
I posit that Apple is going the asymmetric multiprocessing route, taking the performance-per-Watt benchmark to a whole new level where every processing unit in the system could be harnessed on demand to provide computing power to any application, and what they're doing here, now, with such draconian clauses in their fastest growing platform's SDKs, is planting the seeds of this revolution at the software level, while keeping the body count relatively low by giving developers plenty of time to catch up.
Disclaimer: I'm in no way affiliated to Apple in any capacity other than using their products for close to 18 years now, nor am I not privy to any insider information. I'm a Computer Scientist and have been following the progress of LLVM since way before Apple hired Chris Lattner, and seeing how all those pieces are falling together this is the only scenario that makes complete sense to me. Feel free to post this message to a personal weblog, in part or in its entirety, and if you do, please be so kind as to mentioning my name and that this was read on a mailing list, since I don't keep a personal weblog myself.
Hey just caught up on the big news, very sad. I sure hope apple will let wax live.
André, you said, "using luac, liblua.a and strip should be enough." could you expand on this? Is there a way to submit your app so all lua is stripped out and it is 100% Objective-C? If someone could post step by step instructions on how to do this (or if it's possible) that'd be great.
On Apr 9, 5:21 am, André Braga <andrebr...@gmail.com> wrote:
> On 9 April 2010 08:54, Federico Brubacher <fbrubac...@gmail.com> wrote:
> > Ansca is saying that they are safe because they do all the compilation > > in the developer machine and their binaries are pure Obj-c , Wax > > wouldn't fall into this category afik, > >http://blog.anscamobile.com/2010/04/do-apples-new-rules-affect-you/ > > Do you guys agree with Ansca perspective ?
> Well, it's easy for them: I believe they're simply collecting the .lua > files, running them through luac, pasting the resulting C code into .c > or .m files, and linking to liblua statically.
> If they went the extra mile of obfuscation, they changed the lua_* > prefixes into something else as well. Or, even easier, if liblua is > linked statically it becomes just a matter of stripping symbols.
> Wax is not a tool to facilitate cross-platform development; it's > completely built for iPhone, Obj-C and Cocoa. I think it's technically > and spiritually safe. And given the uproar, I'm completely positive > that Apple will cave and re-flexibilise that clause.
> For the time being, though, using luac, liblua.a and strip should be enough.
El 10/04/2010, a las 19:43, Andrew Arrow escribió:
> André, you said, "using luac, liblua.a and strip should be enough." > could you expand on this? Is there a way to submit your app so all > lua is stripped out and it is 100% Objective-C? If someone could post > step by step instructions on how to do this (or if it's possible) > that'd be great.
It compiles scripts to bytecode, so I personally don't see how this is any more safe than parsing the scripts at runtime. Apple could implement a scanner for bytecode strings embedded in the binary. Then people would obfuscate or randomize the lua bytecode for each app, then Apple would... this is still ridiculous.
>> André, you said, "using luac, liblua.a and strip should be enough." >> could you expand on this? Is there a way to submit your app so all >> lua is stripped out and it is 100% Objective-C? If someone could post >> step by step instructions on how to do this (or if it's possible) >> that'd be great. > I can't find a doc for 5.x, but here's for 4: http://www.lua.org/manual/4.0/luac.html
In general, too many things changed from Lua 4 to 5.1 to be able to use Lua 4 docs reliably now. It is better to avoid this.
> It compiles scripts to bytecode, so I personally don't see how this is any more safe than parsing the scripts at runtime. Apple could implement a scanner for bytecode strings embedded in the binary. Then people would obfuscate or randomize the lua bytecode for each app, then Apple would... this is still ridiculous.
That's walking a minefield. You can't tie money and time to such project.
> André, you said, "using luac, liblua.a and strip should be enough." > could you expand on this? Is there a way to submit your app so all > lua is stripped out and it is 100% Objective-C? If someone could post > step by step instructions on how to do this (or if it's possible) > that'd be great.
Oops, sorry, not luac, but bin2c (at least I got the "c" part right!)
(bin2c is part of the Lua source code and comes precompiled in the binary distributions of Lua for Windows)
See http://lua-users.org/wiki/BinToCee and the links at the end for how to embed the Lua bytecodes of a source file and its required modules.
> It compiles scripts to bytecode, so I personally don't see how this > is any more safe than parsing the scripts at runtime. Apple could > implement a scanner for bytecode strings embedded in the binary. > Then people would obfuscate or randomize the lua bytecode for each > app, then Apple would... this is still ridiculous.
Then you reach the computationally unfeasible realm of NP-Hard (the halting problem), for which Apple doesn't have a solution to.
(Nor anybody else, for the matter.)
The possibility of finding binary patterns in the resulting object files is real.
However, I believe that if you embed the bytecode straight into C and XOR (or otherwise encrypt/obfuscate) the array to a key of your liking, there's no way Apple could tell that you embedded a script there, short of manually disassembling and analysing what's going on. That takes care of the script part.
Build your own liblua.a and mess with optimisation flags and so on, then link statically against it and strip your binaries in the end, and it becomes rather impractical for them to even try to locate patterns coming from liblua itself.
This sucks and is rather boring to perform, but it works. People have been doing it ever since the shareware was invented, to obfuscate copy protection checks and such. A motivated enough cracker will be able to beat it eventually, but that's not what Apple is doing. Not worth the trouble.
> That's walking a minefield. You can't tie money and time to such > project
Considering that the Corona guys believe they are safe, and there's nothing they could be doing to "protect" themselves that's different from what I described above (short of having built a Lua to C compiler, which, if based upon http://lua-users.org/wiki/LuaToCee would end up being way too slow to be practical for writing a performance-sensitive app on the iPhone), I believe Wax is safe as well.
Honestly, I believe Wax is safe even without those provisions, as I feel Apple's wording targets fully alien programming environments where XCode is bypassed on its entirety, which is not the case for Wax.
But apple will never give us an "all clear" on wax and let us code with 100% certainty that are apps are okay right? We'll always be in this limbo state of waiting for apple to say no. Makes it really hard to keep investing time and money into a wax project. Maybe not? Has anyone asked apple? Could we get an official yes/no answer on wax vs. just hoping?
On Apr 11, 11:14 am, André Braga <andrebr...@gmail.com> wrote:
> Honestly, I believe Wax is safe even without those provisions, as I > feel Apple's wording targets fully alien programming environments > where XCode is bypassed on its entirety, which is not the case for > Wax.
Em 12/04/2010, às 11:07, Andrew Arrow <one...@gmail.com> escreveu:
> But apple will never give us an "all clear" on wax and let us code > with 100% certainty that are apps are okay right? We'll always be in > this limbo state of waiting for apple to say no. Makes it really hard > to keep investing time and money into a wax project. Maybe not? Has > anyone asked apple? Could we get an official yes/no answer on wax vs. > just hoping?
This amounts to endorsement, which is something that Apple WILL NOT DO. "Don't ask, don't tell" is a smarter strategy.
Besides, your statement that investing time and money on a Wax project is a liability is false. If you use Lua strictly for scripting, it's *safe*. You can't go wrong with using Wax as a prototyping tool as well. The gray area is deploying an app where Wax was used as a bridge to Obj-C. Apple might reject that. Hence my suggestions to obfuscate some of the Wax magic in order to stay under the radar.
Seriously guys, stop panicking. Wax does an amazing job as a prototyping tool. This is nothing different from rewriting your code for speed. If I had a dime each time I read "rewrote the engine from scratch" on a changelog...
If Wax saves you from doing that even once (because you have the chance to experiment and adapt quickly to see what works), YOU PROFIT.
So bad news is my app was rejected. But good news is it was rejected because of a crash on startup issue (no idea why..). 3.3.1 wasnt mentioned at all yet. I'll get them a new build tonight.
Hang tight, Ryan
On Apr 12, 10:29 am, André Braga <andrebr...@gmail.com> wrote:
> Em 12/04/2010, às 11:07, Andrew Arrow <one...@gmail.com> escreveu:
> > But apple will never give us an "all clear" on wax and let us code > > with 100% certainty that are apps are okay right? We'll always be in > > this limbo state of waiting for apple to say no. Makes it really hard > > to keep investing time and money into a wax project. Maybe not? Has > > anyone asked apple? Could we get an official yes/no answer on wax vs. > > just hoping?
> This amounts to endorsement, which is something that Apple WILL NOT > DO. "Don't ask, don't tell" is a smarter strategy.
> Besides, your statement that investing time and money on a Wax project > is a liability is false. If you use Lua strictly for scripting, it's > *safe*. You can't go wrong with using Wax as a prototyping tool as > well. The gray area is deploying an app where Wax was used as a bridge > to Obj-C. Apple might reject that. Hence my suggestions to obfuscate > some of the Wax magic in order to stay under the radar.
> Seriously guys, stop panicking. Wax does an amazing job as a > prototyping tool. This is nothing different from rewriting your code > for speed. If I had a dime each time I read "rewrote the engine from > scratch" on a changelog...
> If Wax saves you from doing that even once (because you have the > chance to experiment and adapt quickly to see what works), YOU PROFIT.
